Free stuff with Standard license?

Permalink
Hello developers,

This is mostly targeted towards marketplace developers (themes or add-ons). And this is in the 5.7 discussion because I think this applies to most of the free stuff there currently.

My question is why do people publish free stuff with the Standard license in the marketplace? I know we ourselves also have one free add-on in the 5.6 marketplace with the Standard license because it was probably an oversight when that was first released (and it was never changed) but it's about to change once that add-on gets updated to 5.7.

Just asking this because I see a lot of the free stuff as potential reference implementations and learning material but the Standard marketplace license bashes this opportunity. I personally do not even download an add-on with the Standard license if I need to look for a reference because of the license constraints.

I understand if someone wants to keep the rights to the code and only use the free add-on as a marketing tool but this is not the case with a lot of the add-ons that provide very basic stuff. E.g. this one which is very basic level add-on:
http://www.concrete5.org/marketplace/addons/page-selector-attribute...

We've used that in many projects but recently we bumped into a (5.6) project where we needed to bundle similar attribute to one of our packages. Because of the license, it was impossible to use this one and we decided to write our own based on the file attribute type found in the core.

Now, if we would publish this implementation to the marketplace, it would rather create confusion than add anything to it. There would be two separate (free) add-ons which provide quite exactly the same functionality but different licenses. I understand this competitive point regarding paid add-ons but regarding free add-ons, it does not make any sense at least in my mind. The license also makes it impossible to provide any improvements to the author of the free add-on from our point of view.

The same question also applies for themes, especially as there are only a couple of free themes in the 5.7 marketplace currently. Both of these are with the Standard license but I think they would be great references for theme developers if they were with an open license.

Can I get some reasoning for this from developers so that I could understand this better? Or could we possibly change this and start embracing open licenses for free stuff? Although, it's up to the developer at the end but what I mean by embracing is e.g. pre-selecting the "MIT" license if the price of the add-on is $0.

I think it would benefit the ecosystem more than the current situation. I see two separate competing free add-ons as a collective waste of time for developers of both of those add-ons.

Mainio
 
MichaelG replied on at Permalink Reply
MichaelG
So, I don't speak for everyone, so take it for what it is.

To quickly offer a solution, all packages can require another add-on be installed. So if you have a theme that uses another free or paid block, you can require it as a dependency. Just like ecommerce payment gateways require ecommerce.

I have some thoughts about free addons, or rather addons in general. I've certainly learned a lot by seeing what other people are doing in their MP packages. When working on some more advanced (for me) stuff, I'll often reference RadiantWeb's ProBlog or ProWhatever to get an understanding of how someone smarter than me would do something. I'm all for learning from others.

Using others code and reselling it is different though. I wouldn't want you to take one of my themes or addons (paid or free), rename the classes, add two options and say "ta-da! that'll be $30 please".

That's me personally. There are many OTHER developers here who have free and paid add-ons and if you just shoot them a PM, would give you permission to use/abuse/bundle/resell/rename/giveaway/sleepwith/selltogoogle
MichaelG replied on at Permalink Best Answer Reply
MichaelG
That said, I mean, you are free to get as many licenses as you need and use it in as many projects as you need etc.

It may be interesting to see some free add-ons go into Git. I know mnkras has many of his addons there.

I also had a theme that for years was free. I decided the support was overwhelming and I changed it to $40. The standard license allows me to do that. If it were MIT, and I changed the price, someone who downloaded it under MIT could just throw it in the marketplace for free.
Mainio replied on at Permalink Reply
Mainio
Actually accidentally marked your answer as the best one but it gives some good reasoning this, so there you go. :)

But to answer, I totally understand your view on the themes and that you don't want people making money of your free stuff. That's perfectly fine and after all, as I was looking mainly some reasoning for this from those developers. But if the theme was some very basic level boilerplate theme, then I would not understand this point at all, although I perfectly understand it for finely crafted custom themes, like what you referred to.

I think in terms of support, the latest marketplace changes give you a good option to avoid overwhelming support of free stuff or charge for only support. I don't think that alone is a very good reason to keep the license as Standard, although your other points are very valid ones.

And yes, I know how you can add dependencies between the packages (like we do also in some of our marketplace add-ons) but the page selector became so important and internal part of what we were doing at that point that it was not an option. It needed to become part of that add-on. And this was only one situation, what if I would only need one library from a different add-on? I would have to add dependency for that add-on all together instead of just borrowing the single library I need (or some part from it).

You also mentioned borrowing some lines here and there from paid add-ons. I think that might be bit on the grey area, although e.g. installing an attribute type or a page type or defining a block controller (or any other very basic stuff) would not fall under any external developer's intellectual property. But it's very hard to draw the line in some occasions if you start to do this because of which we avoid that ourselves with any add-on licensed with a closed license.

Contacting the developer always adds an unnecessary extra step to relicense the code under some open license. And if they relicense it when I contact them personally, why not relicense it altogether?

Just stating some of my points. I think there are valid points in terms of both sides but I'm still not convinced the Standard license is perfect for the kind of stuff I originally referred to.
MichaelG replied on at Permalink Reply
MichaelG
Support or not, if for ANY reason I wanted to go from free->paid, MIT ruins it.

By the way, when I say I look at other examples, I don't mean borrowing original code. More like... I look at something and say "Oooo that's what you use models for!" or "oooh that's how you install block sets" and craft something with that new knowledge.

I'm all for MIT being used more frequently. I know there's a lot of stuff in the MP that are there pretty much exclusively there for developers to reuse.

For that kind of stuff you're talking about, I'd probably rather see a curated repository or list of repositories in GIT. That would allow people to help/contribute and steal all day long Why? Because the marketplace is ... wait for it... a /marketplace/

:)

I would dig seeing curated repos for stuff like:
custom block boilerplates
custom object boilerplates
dashboard pages
custom attributes
blah blah, blah blah
Mainio replied on at Permalink Reply
Mainio
Yeah, I'd be happy to see such list of github repos if they are released with an open license.

But I still think there is a place for this kind of stuff in the marketplace. E.g. one of our most popular add-ons is the "automatic email obfuscator". It wouldn't have nearly as much exposure if it was not released to the marketplace because that's what the "general folks" use to get their stuff from. Appstore/Google Play are also marketplaces (or "Stores"), although there is a lot of free stuff. And no, I don't want to start an argument why nothing is open source in those places, just stating that the name is not solely for the commercial aspect.

The same thing with the page attribute, although it's mostly for developers, it might come useful for someone else how has at least the basic knowledge of fetching and using the attributes. Especially as the page redirect add-on requires it.

Not claiming here that everything should be MIT, there was another thread about that way back and I'm strongly opposed that idea. Just repeating what I've said. I don't understand it in terms of some packages.

One place where we've also looked at the coding style / standards of a paid marketplace add-on is the eCommerce add-on because when we created the first payment gateway for it, there was basically no other way of doing it. I'm still not sure whether there is any documentation of that, haven't checked since. And I think the example gateway in the package was there for this exact purpose.

So I think it's OK in some clear places but we still avoid it to the extent that is possible. If the add-on is with a closed license, we simply don't use it as a reference for anything other than the example I gave above.

I understand that giving the code under an open license takes you away the possibility to change the license later but I also don't think that should happen very often. At least when we publish a free add-on, the decision is final. There won't be a change of opinion on that. Or I don't see why we would publish it as free in the first place if we wanted to change that later.
Mainio replied on at Permalink Reply
Mainio
Anyone else, bother to share your perspectives?
JohntheFish replied on at Permalink Reply
JohntheFish
From my point of view, MichaelG sums it up pretty well. Just because I give something away for free doesn't mean I want to give away all rights to the code within it. If someone wants to use code from one of my free addons, they can always ask me.
Mainio replied on at Permalink Reply
Mainio
Yeah, perfectly understand this.

But I think my point might not be so well emphasized here, so let's try through another question:

Are you encouraging me to upload our own "page" attribute to the marketplace which provides 100% the same functionality from the end user perspective than the one there already is (page selector attribute)? Only difference that you can clearly see straight off the top is the license.
JohntheFish replied on at Permalink Reply
JohntheFish
If any of my addons require functionality from another addon, I just make that addon an installation requirement and code a check + warning into the package controller.

Where I have addons with base classes or examples designed for copying or extending, I make the freedom to copy and any limitations explicit in the marketplace and docs pages.
Mainio replied on at Permalink Reply
Mainio
Yeah, but as explained above, it needed to become part of what we were building. Requiring it as an installation requirement wouldn't have made any sense in that situation.

Seems that I'm not able to get my point through.

Well, maybe with 5.7 we will eventually convert to a more composer centric architecture, as have been discussed, so the marketplace wouldn't be anymore the primary source for this kind of stuff... Would get passed this issue.
MichaelG replied on at Permalink Reply
MichaelG
I guess we don't quite understand the situation enough to understand why you couldn't require it as a dependency.

And for the record, I don't think anyone is arguing against you. This is an interesting discussion, and I'm with you that some for-developers-by-developers addons would make more sense as MIT. OR placed somewhere else, like in the "how-tos" etc. But you're kind of right that it also doesn't get the exposure it may deserve.
Mainio replied on at Permalink Reply
Mainio
And I still stand behind my point that it's a collective waste of time if we encourage everyone to license every "hello world" add-ons with the closed license. And also very unique to an open source project.