It allows the public to continue to use your work to collaborate and create better things, which is the point of open source, while allowing businesses (which should be able to afford to license a software product) to still pitch in and generate a profit. Both of these will attract talent and interest and allow collaborators to prosper.
> Many years ago, a friend of mine was asked to rerelease a copylefted program under noncopyleft terms, and he responded more or less like this: > > > "Sometimes I work on free software, and sometimes I work on proprietary software---but when I work on proprietary software, I expect to get paid." > > He was willing to share his work with a community that shares software, but saw no reason to give a handout to a business making products that would be off-limits to our community. His goal was different from mine, but he decided that the GNU GPL was useful for his goal too.
The approach is far more common in other kinds of licensed, creative work. Creative Commons' choice to standardized noncommercial license terms helped make commercial-noncommercial licensing familiar in photography, illustration, music, and so on.
The model has gone by a few names. Those researching should search on "selling exceptions" and "dual licensing", too.
I'm doing what I can to popularize through License Zero (https://licensezero.com).
I understand RMS was at times the beneficiary of people who were sympathetic to his mission. For example, students said at one point he was living in a university office that someone arranged to be allocated to him.
Personal sacrifices like this, towards his principles, were to RMS's credit, but the suggestion that one could just pick up consulting work on the side seemed misleading. RMS was one of the better programmers, and famous, and even he didn't seem to pull off that sustainability reliably.
I did buy a bunch of them on regular basis.
People may use whatever license they wish, but it's important to be clear about what is (and is not) FOSS.
The term "free software" was effectively coined by RMS & The Free Software Foundation. It is used explicitly when referring to copyleft licenses, which restrict certain uses of the licensed software in order to protect user freedoms. You can argue that other people use the term in other ways, but the most commonly accepted definition is the one used by the FSF.
The term "open source" is somewhat vague. Software that is merely "open source" is not necessarily licensed in a way that allows redistribution/modification. The only thing guaranteed about "open source" software is that you can read the source.
'Open Source' was/is a rebranding of the term 'Free Software' to make it easier to sell to suits. Eric Raymond has said as much about his invention of the phrase. The idea that it's just about "being able to read the source" is wrong. It's not vague at all, you just didn't do your research.
Otherwise, I concur.
https://writing.kemitchell.com/2018/11/05/OSD-Copyleft-Regul...
https://blog.licensezero.com/2018/09/14/free-to-take-freedom...
There are heaps of disputes about whether licenses qualify. Check OSI's license-review list, or Twitter, or, frankly, HN.
OSI and FSF would disagree.
> We could rewrite any copyleft license as a limit on use.
What is the purpose of your argument? What are you trying to achieve? Do you want a Lobjan specification of FOSS? There may be difficult cases around the edges of the definition of FOSS, but restrictions on commercial use are not one of them.
As for FSF, their process for considering licenses is a black box. We have "What is Free Software?", published largely in response to the creation of the Open Source Initiative. But it's no more a technical specification than OSD is.
I never claimed that restrictions on commercial use are "open" or "free", or that any particular license that does so is "open" or "free". I have and do claim that neither OSI nor FSF provides any clear, complete guidance on what "open" or "free" copyleft can and cannot do. Consensus within the relatively small groups of folks actively engaged with those institutions is founded in good-sounding generalities, not any rigorous definition.
There was enough ambiguity in your statement on public-private licensing that I felt the need to make the clarification. My intention was a much a "public service announcement" as anything.
> I have and do claim that neither OSI nor FSF provides any clear, complete guidance on what "open" or "free" copyleft can and cannot do. Consensus within the relatively small groups of folks actively engaged with those institutions is founded in good-sounding generalities, not any rigorous definition.
A fair contention, though I might disagree. However, that does not change the fact that non-commercial licenses are not FLOSS. Both the OSI and FSF have made that patently clear.
Your initial advice was fine, I just want to make sure that people who follow your advice don't confuse non-commercial source-available licenses with FLOSS.
You need commercial users who want to use your stuff enough, and the GPL/LGPL/whatever license won't work for them, such that it will get pushed up to someone who'll follow through and negotiate a license.
(You also need it to not quietly be used by parties ignoring the license, like has happened many times with Linux and certain GNU-ish libraries that would be expensive to reimplement.)
The tell is a known, small, approachable target market. Especially when the developer already has positive relationships with important would-be customers.
If this was a commercial project, his income would be magnitudes higher.
Yes, $20k a month is comfortable. But is it appropriate given the popularity of Vue and considering how many organizations profit from it?
Now, if you scale this down to a framework that has half or a quarter of that popularity. When do you reach the point where it isn't comfortable at all anymore? And does that still seem appropriate?
If it was a commercial project I imagine there would likely need to be other staff involved, and adoption would be lesser. Whether that ends up being more or less money for him in specific in the end (or whether the project/company would survive) is not without question, in my mind.
It will be hard to find evidence for both sides I guess. So it boils down to being kind of a gamble: adoption or fair compensation — you can't have both.
This looks like a race to the bottom to me, which is what the data presented in the article seems to support.
Not necessarily. I would expect part of the reason it's one of the most used is because it's non-commercial.
I do agree it's not fair compensation, though.
I might suggest for a company to use VueJS since it is open source and donate but I’m never going to suggest that a company bases its product on Telerik components.
on edit: I should have probably asked one the child comments, but this is ok here as well.
That is also part of his compensation.
I'm a developer who's presented at conferences. I don't consider that "another" job, but rather, part of this job. And I don't have any monthly donation income coming in at all.
But really, I just wanted to help people.
Here is my great question, can I help more, if I charge money?
At some point there is a trade off to any number of choices. I choose to keep active employment, and open what I can, when I can. Mostly utilities that I wrote for work that aren't core functionality that it makes sense to separate out anyway. Heaven help me if something got too popular and people wanted a support model.
It depends on which dimension of "help more" you want to affect.
I looked at your website "efficiencyiseverything.com" and here's how I would break it down: "more people" vs "more features"...
- if you want to help more people, it's better to keep it free because no subscription/paywall payments means the biggest audience (including those without discretionary income) can be helped by your information
- if you want to help less people but add more features, you should charge money. The paying audience will always be less than a non-paying one but the ones who do monetarily support you can be assisted with new website features that requires revenue to develop
(One can sort of try to get the best of both of the above scenarios by keeping it free with voluntary donations but to me, that just simplifies down to "free" since the percentage of donators will be very small.)
I would add one more thing. It would help less people in short-term, but in long-term, it might actually end up helping more people, as those features have the potential to attract way more people than you would have gotten without those features but for free.
I have a day job that Pays great.
I need to find a way to incorporate premium features.
The open-core model is a good alternative if you wish to be around open-source software. Or make your project de-facto standard and charge for consulting. Or, you can make an entirely commercial project that uses and contributes to open-source projects. That way, you are surrounded by open-source and can help them financially to add features you need.