Interesting timeline, seems the MIT License came out a few years before the GPL. I wonder if/what discussions RMS had with the authors of the MIT License at that time when he was crafting the GPL.
From my understanding GPL originated because Stallman was upset about a version of Emacs he was working on at school (MIT Licensed). The person he was working on it with took the source code and started a commercial company, but had no interest in working with Stallman professionally. So Stallman started his free software crusade with his own version of Emacs and replicating every tool needed to build it with his own "FREE" license. This has always bothered me as GPL is far more strict of a license than either BSD or MIT.
> This has always bothered me as GPL is far more strict of a license than either BSD or MIT.
In a similar manner, democracy is far more strict than anarchy because you can't kill and loot whatever you want.
Yes, I'm comparing murder and theft with taking away users' freedom. Yes, murder and theft are probably considered worse than proprietary software in the eyes of many. My point is that just because something is more restrictive, doesn't in itself make it worse.
I avoid GPL projects because I am a software developer and the idea of the project dictating how I can release my own source is a big FU to me. If I can find software that is licensed with a non restrictive license I will always support it over anything that is GPL. I have had a few projects I was very interested in and considered helping out on, but the GPL license is a non starter for me.
If you have to redefine the word "FREE" to mean freedom and your license is several pages of lawyer speak, then that is a problem.
I will take anarchy over crazy ideology any day of the week.
I generally favor permissive licenses myself for various reasons.
However, the relevant perspective on the GPL is that it's not really about freedom for developers. It's about freedom for users. If I as a developer/company want to ship modified FOSS to end-users. I can't hold the modifications back as secret sauce.
> I avoid GPL projects because I am a software developer and the idea of the project dictating how I can release my own source is a big FU to me.
GPL doesn't restrict how you can release your own source code - even if you release your project as GPL, you can still release it under MIT, or a commercial license - it's your code, and you're the copyright holder. The restrictions only apply to code derived from other GPL projects, but that isn't really "your code".
Your reason for avoiding GPL seems to be that you cannot take GPL code and release it under a non-free license. That's exactly the behavior that GPL is designed to prevent - the bottom line is users' freedom, not developers' convenience.
I agree it is far more strict, but I am glad it exists. I do throw the MIT license on most of my projects, so its rare that I license things with GPL. But at the end of the day, having the BSD and MIT license and the GPL licenses gives us all the options we want. Want to produce something and don't care how it gets used? MIT or BSD license. Want to create something, offer it for free, and know that nobody will modify your code and start selling it? GPL.
> Want to create something, offer it for free, and know that nobody will modify your code and start selling it? GPL.
You can modify somebody's GPLed code and start selling it. The only restriction is that you must offer to share your source code with your customers and give them all of the same rights you have under GPL.
There is also a loophole that lets you sell modified GPLed code without sharing the source or giving them your GPL rights: run it on a server. AGPL closes this loophole which is why it is unpopular with large tech companies.
Any license that prohibits selling modified versions of somebody else's code would, if it became popular or was adopted by a popular project, be denounced by both FSF and OSI for violating the principles of the FOSS movement because the right to sell other people's FOSS software is considered an important user freedom. Writing such a license involves making fairly trivial changes to MIT or BSD but does make it impossible to combine any code licensed under it with GPLed code.
Yes, and the specific strictness is the point! The point is that there isn't really such a things as "no laws". Dynamics between people don't stop to function just because there are no laws applied. The most basic thing is that if you don't restrict the use of force effectively, then the use of force will most certainly determine the order of things - you end up with tyrants, or warlords, essentially.
Translating this to the world of software licenses, similar things happen. With MIT, and BSD, an entity can take the project and just run with it. Neither the original owner, nor the ecosystem benefits. This is cool with some people, in theory, but from time to time, significant regret is demonstrated, of which my favorite is Tanenbaum learning from the media that Intel uses his system in all of the CPUs.
I also recommend contemplating the "Paradox of tolerance" - a similar situation. It posits that in order to have a sustainable tolerant society, one must not tolerate intolerance - for if we do, it will take over, ending the tolerant society.
The article provides some early on documentation that I wasn't able to find when I wrote the piece referenced in footnote 1. [0] It doesn't really get into--I suspect because no one is really sure what/when the changes happened--how the various changes in wording it mentions towards the end eventually morphed into the current (OSI-approved) MIT license.
The current license actually matches a related but different license than the X11 license and at least one open source IP lawyer I know suspects there may have been a minor mixup when the "MIT license" was approved by OSI.
Neat to know MIT License did actually originate at the eponymous institution.
When I first got access to the internet, MIT seemed awfully productive in producing code. Before I found out that MIT License doesn't imply the work was done by a person at MIT!
FTA: "As it turned out, the licensing strategy had the desired effect: the goal of influence was realized. ...
"Furthermore, the good will that was gained from free distribution of these software packages led to the flow back of both funding and software applications that support research and education at MIT. The cash flow has dwarfed the forgone revenue stream that likely would have come from licensing for a fee, and even that sum has been dwarfed by the value of the applications that became available.
"A lesson is that it can be important to look past the prospect of licensing for a fee, which may bring in a few dollars, and instead see the opportunity that opens if you give the software away. The potential reward can be orders of magnitude larger."
I took a class from Saltzer in 2002 or 2003 and it was spectacular. A sort of survey-level runthrough of software architecture and system design. He seemed to really enjoy teaching it too.
I asked rms and Hal Abelson about this a few years ago.
Stallman said:
> The term "MIT license" is a confusion. It is used to describe two different licenses; see https://gnu.org/licenses/license-list.html. We call them the X11 license and the Expat license. To distinguish them, we do not use the term "MIT license". The X11 license was, as far as I know, first used by X11. I don't know how it was written -- the question is not interesting to me.
Thanks Richard.
Hal recalled that it was drafted by Karen Hershey at the request of the Technology Transfer Office. Regretfully I don't have a copy of his original response.
Right. The modern MIT license approved by the OSI is the same as the license used for the Expat XML parser library beginning in about 1998. It's similar, but not identical, to the X11 license. No one seems to be sure how the Expat license ended up as the MIT license.
That said, it's more than a bit pedantic not to use the term "MIT license" given that all the licenses in that stream are quite similar and certainly in the same permissive spirit.
19 comments
[ 2.7 ms ] story [ 51.0 ms ] threadIn a similar manner, democracy is far more strict than anarchy because you can't kill and loot whatever you want.
Yes, I'm comparing murder and theft with taking away users' freedom. Yes, murder and theft are probably considered worse than proprietary software in the eyes of many. My point is that just because something is more restrictive, doesn't in itself make it worse.
If you have to redefine the word "FREE" to mean freedom and your license is several pages of lawyer speak, then that is a problem.
I will take anarchy over crazy ideology any day of the week.
However, the relevant perspective on the GPL is that it's not really about freedom for developers. It's about freedom for users. If I as a developer/company want to ship modified FOSS to end-users. I can't hold the modifications back as secret sauce.
GPL doesn't restrict how you can release your own source code - even if you release your project as GPL, you can still release it under MIT, or a commercial license - it's your code, and you're the copyright holder. The restrictions only apply to code derived from other GPL projects, but that isn't really "your code".
Your reason for avoiding GPL seems to be that you cannot take GPL code and release it under a non-free license. That's exactly the behavior that GPL is designed to prevent - the bottom line is users' freedom, not developers' convenience.
Someone can absolutely do that. They just need to share the modified source code.
You can modify somebody's GPLed code and start selling it. The only restriction is that you must offer to share your source code with your customers and give them all of the same rights you have under GPL.
There is also a loophole that lets you sell modified GPLed code without sharing the source or giving them your GPL rights: run it on a server. AGPL closes this loophole which is why it is unpopular with large tech companies.
Any license that prohibits selling modified versions of somebody else's code would, if it became popular or was adopted by a popular project, be denounced by both FSF and OSI for violating the principles of the FOSS movement because the right to sell other people's FOSS software is considered an important user freedom. Writing such a license involves making fairly trivial changes to MIT or BSD but does make it impossible to combine any code licensed under it with GPLed code.
Translating this to the world of software licenses, similar things happen. With MIT, and BSD, an entity can take the project and just run with it. Neither the original owner, nor the ecosystem benefits. This is cool with some people, in theory, but from time to time, significant regret is demonstrated, of which my favorite is Tanenbaum learning from the media that Intel uses his system in all of the CPUs.
https://www.tomshardware.com/news/minix-creator-letter-intel...
I also recommend contemplating the "Paradox of tolerance" - a similar situation. It posits that in order to have a sustainable tolerant society, one must not tolerate intolerance - for if we do, it will take over, ending the tolerant society.
The current license actually matches a related but different license than the X11 license and at least one open source IP lawyer I know suspects there may have been a minor mixup when the "MIT license" was approved by OSI.
[0] https://opensource.com/article/19/4/history-mit-license
When I first got access to the internet, MIT seemed awfully productive in producing code. Before I found out that MIT License doesn't imply the work was done by a person at MIT!
"Furthermore, the good will that was gained from free distribution of these software packages led to the flow back of both funding and software applications that support research and education at MIT. The cash flow has dwarfed the forgone revenue stream that likely would have come from licensing for a fee, and even that sum has been dwarfed by the value of the applications that became available.
"A lesson is that it can be important to look past the prospect of licensing for a fee, which may bring in a few dollars, and instead see the opportunity that opens if you give the software away. The potential reward can be orders of magnitude larger."
(Extra paragraphing added.)
Stallman said:
> The term "MIT license" is a confusion. It is used to describe two different licenses; see https://gnu.org/licenses/license-list.html. We call them the X11 license and the Expat license. To distinguish them, we do not use the term "MIT license". The X11 license was, as far as I know, first used by X11. I don't know how it was written -- the question is not interesting to me.
Thanks Richard.
Hal recalled that it was drafted by Karen Hershey at the request of the Technology Transfer Office. Regretfully I don't have a copy of his original response.
That said, it's more than a bit pedantic not to use the term "MIT license" given that all the licenses in that stream are quite similar and certainly in the same permissive spirit.
From Stallman? Who would have guessed.