The thing is with GPL you have to contribute back, see how much Linux has grown in functionalities and how backwards are other kernels with MIT
---
You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange;
You can't just give out binaries without source, but you can choose not to release anything. The thing is, as usage models shift to include a lot of what the FSF very reasonably relabels SaaSS (Service as a Software Substitute), you can release nothing but provide the functionality over the network and reasonably expect people to use it that way. Since you haven't distributed the software itself to anyone, the GPL doesn't put you out of compliance for not showing them your code or letting them distribute it further.
This is the situation the Affero GPL (AGPL) was intended to address—it requires (or tries to require) that source code also be accessible to anyone who is given access to the software over a network. (Imprecisely speaking, that is; do check the license text if you want the specifics.)
They both contain both elements, but the point is to sharply alter the emphasis. “Software as a Service” is a reasonable description in the salience model of the mainstream software industry, because it is something that you choose and integrate and use like software, except it just so happens to be a service, coming with various costs like subscription fees and very direct vulnerability to upstream changes, and various benefits like installation and maintenance functions being centralized far away where you don't have to directly manage them.
“Service as a Software Substitute” pushes the ‘service’ part to be the most salient. It depicts something which is fundamentally a service, where ‘substitute’ once more emphasizes that you do not, in fact, have the software itself, even though it is taking the role of software. The FSF considers this very important, because they wish users to be able to copy and modify the software they use, and pseudo-distribution purely as a service does not naturally allow for this. If that is not something you care about, then the emphasis will seem strange, yes.
The most recent exploitation of opensource code comes from Amazon & friends making their own paid, hosted versions of redis, elastic search, mongodb, and so on. And not making any sort of proportionate contribution to the developers - whose free work their profits entirely rely on.
And in this case I’m not sure how gpl helps. With gpl2 you only need to distribute source code if you distribute binaries - so they have no legal obligations there. And Amazon isn’t really making meaningful changes to elasticsearch and friends anyway, so having the license require them to opensource their changes is a bit moot.
That’s a shortcoming of the GPL: it doesn’t consider interactions over the network “distribution”. It’s the reason the AGPL exists. IMHO, GPL software that could be expected to run in SaaS form should be AGPL.
It's also worth noting that GPL become more accepted in the corporate world because SaaSS defanged it. AGPL is toxic to companies now, but when everyone was releasing desktop software, GPL was treated the same way.
AGPL-like clauses classifying usage through network as distribution would help there and many platform capitalism[1] companies are against AGPL[2] for that reason.
Not really, or at least the license would be very unappealing.
You'd need a method of determining revenue and then apportioning revenue amongst the many parts of a system. Then there's transfer pricing issues. Not to mention audit requirements. See also Hollywood accounting.
One of the ways open source gets adoption is because using open source with an acceptable license is often much less hassle than paying for commercial software and complying with commercial software license requirements.
Yeah it's frustrating, i would never work on a open source project as i don't really get why companies can make money using something from the unpaid labour of someone else, and for our society that's acceptable
I've done a few open source things, mostly bugfixes or minor enhancements. Most of those I was being paid by my employer for, and it was either something I wanted available more widely and it was worth going through the process or it was a pain to manage patches so it saved me time to get it accepted upstream.
Either way, I don't get paid a royalty for work for hire from my past employers, so I don't expect a royalty from anyone else. And I've not worked on a project basis either; so I'm getting paid for having my butt in the seat and anything that happens afterwards is a happy accident.
I've open sourced some personal stuff too, although I don't know that anyone has looked at it. That stuff is usually more like nobody should need to write this again. Not much commercial market for a PPPoE client that can handoff to a standby machine anyway, but maybe it will be useful for someone, some day.
I've got another project in the works, but it's mostly a bit of glue around other people's open source code. If I wasn't retired, I'd try to get an employer to pay me to write it (and it would get done faster!), but I can't see why anyone would pay for just the software. Consulting on the software, sure; but then again, if you were to rely on it, you'd probably want to cultivate in-house expertise to reduce dependency on outside help.
You would probably be more fond of Anti-Capitalist Software License, CoopyLeft Software License, Proseperity Software License or other Copyfair or Copyfarleft licenses.
> The thing is with GPL you have to contribute back
Not contribute, but share the sources if they distribute a binary which uses code derived from GPL-ed one. Wireless router vendors used to share modified sources as an archive on some obscure ftp without comments and documentation (so you'll have a hard time building a binary from these sources). It's better than nothing, but this is not a contribution.
MPLv2 is a fine weak copyleft license, but I'm not really sure it prevents people from not contributing back if that's what they want: just put your proprietary code in a different file, add minimal API's to the MPL code so you can use it.
So in that sense it's only very marginally 'better' than a fully permissive license.
Right, and GPL is making all of us open source devs rich. I can't fathom getting into open source and then getting mad when people use your tools to great success.
