What's so objectionable about that. Honestly one of the more annoying to find problems with GitHub (and npm) is MIT licensed software with GPL dependencies, and even if you want to have closed source software on GitHub, having a "this software is closed source" UI element is still better license hygiene without forcing everything open source.
I think honestly this is something other providers (Google code when it was around, gitlab now) are much better at.
Once you statically like that MIT licensed code to GPL licensed code, you have a GPL licences executable. If the source is provided, I think you're in compliance with the GPL. IANAL and that is a very interesting situation.
That type of thing is why I think people need to choose one of: GPL, LGPL, MIT, BSD (isn't that essentially MIT?). I dont see the point in other "open source" licenses, they primarily create compatibility issues.
According to Stallman, MIT is compatible with GPL but the reverse isn't true. You can freely use MIT code (including linking) in a GPL project so long as the source is available.
In Rust most code is dual licensed as MIT or Apache 2. You can pick which one to use although IIRC Apache 2 is considered the "primary license" because it provides protections from patent trolls and an explicit contribution licensing clause. However Apache 2 isn't compatible with GPL.
> According to Stallman, MIT is compatible with GPL but the reverse isn't true
What are you talking about? Let say we have code A licensed as MIT and code B licensed GPL.
You can combine A with B and distribute it. You can combine B with A and distribute it. AB or BA is both a legal combination that a distributor can do. In both cases the distributor need to follow the condition of both MIT and GPL. You can not distribute AB and only follow GPL, or combine BA and only follow MIT.
There is two ways to look at copyright licenses. The slightly incorrect but slightly easier way is to see them as a contract. In order to distribute you need to follow the conditions. If you have two contracts then you have two sets of conditions. Three contracts and three sets of conditions.
The second way, which lawyers prefer as the more "true" perspective, is to see a copyright license as a list of permissions. Copyright law dictate that as a distributor you have no rights, so the license is the specific conditions in order to gain permission. It is like a airplane ticket where in order to travel you got to follow the rules and conditions or the airline. Countries can also have conditions and rules like visas, passports and enter/exiting laws. Thus in order to have permission to travel between countries you need to follow both sets of rules and conditions.
Incompatibility occur when the rules and conditions of two or more licenses demand something impossible, like the case where one condition require an action and the other forbid said action. Both conditions can not be met at the same time and thus the licenses are incompatible.
Okay, so we have A licensed as MIT and B licensed as GPL, your example. Let's specify that B is licensed under GPL3 so it's clear:
Under MIT, Microsoft can take code from A and put it into the source code of Visual Studio, provided that they keep the copyright and license with the code they've copied. Visual Studio can then be licensed however they want.
Let's say that project A takes code from project B. Now because they have GPLed code, A has to be distributed with terms at least as open as the GPL3's terms, due to copyleft.[1]
This might not matter to the maintainers of project A, but it certainly matters to Microsoft, because now if they use code from project A, they also have to distribute it with terms at least as open as the GPL3's terms. So if they use code from project A in Visual Studio, they've effectively licensed Visual Studio under the GPL3.
The GPL3 is "infectious" in this way--once you use GPL3 code in your project, your project is effectively licensed under the GPL3.
> Under MIT, Microsoft can take code from A and put it into the source code of Visual Studio
In that case we have three licenses. We have the MIT licenses, the GPL license, and the license of Visual Studio owned by microsoft.
If the MIT licensed project have a relation with Microsoft which they value higher than the code from the GPL project then the GPL code will be incompatible with the goals of the MIT project.
The incompatibility depend on the relationship and can only be answered based on defining said relationship.
It's been a while since I read the GPL3, so I just read it again.
I'm no lawyer, but if I'm understanding correctly, yes, it does have to be licensed under the GPL3, but it doesn't have to be licensed only under the GPL3. With a license like MIT, the could apply a second license which would, for example, amend the MIT license to require you to pay for the software.
However, the "No Further Restrictions" paragraph in the GPL I think puts a much stronger set of requirements:
> You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.
This is why I think Stallman often uses the language "licensed with terms at least as open as the GPL" instead of saying "licensed under the GPL"--yes, it has to be licensed under the GPL3 but that doesn't quite capture the whole story. Someone can apply another license (i.e. Apache 2, to explicitly grant patents) so their licensing might not be just the GPL3, but further licenses can only expand freedoms, not restrict them.
I would encourage anyone who is interested in this sort of thing to read the license for themselves. Don't get intimidated and assume it's all in legalese: while I'm hesitant to think I understand it since the law is not my area of expertise, the GPL is written in what seems like fairly straightforward English.
I mean you can very easily add MIT code in a GPL licensed project because MIT is more permissive. However adding GPL code to an MIT licensed project means you now have to comply with GPL's more restrictive "list of permissions" when you weren't before.
If we imagine a project with only MIT code that want to add GPL licensed code, the only significant additional legal action needed to be compatible is that you now need to give a patent grant that covers the combined work, and in the case of GPLv3 not distribute the combined work in hardware devices that use access control to prevent the installation of modified versions by the owner.
If neither aspects is an issue then the additional work needed to add GPL code to an MIT licensed project is practically zero.
There are however naturally implication for downstream which in combination of additionally third licenses (such as proprietary licenses) can cause real issues, and the relationship between such downstream and the MIT project could as a result lead to reasons why the MIT project feel like they can not include GPL into their code. There might even be contractional reasons involved which mean not only do you now have three different copyright licenses to follow but you also have contract law involved in order to follow the law and have a legal right to distribute the combined work. I can see how the permissive licenses in those kind of situation feel simpler since they do not interact much with the other legal stake holders.
If a project with only MIT code adds GPL licensed code, then they can't distribute the "merged" new set of code under the MIT license.
Previously, someone could use your MIT code in a closed source product and distribute the resulting executables to their customers without including the source. In the future, that someone would have to start following the GPL rules or stop using your not-MIT-anymore project.
Sure, but that doesn't mean the two are incompatible! It just means that you also now have to comply with the terms of the GPL if you use GPL-licensed code in that project: something that the MIT license is flexible enough to allow.
I guess my post wasn't clear that I was referring to two issues - I assumed the original poster took RMS's comment as "ban closed source from GitHub", and was pointing out that being clear on licensing is not the same thing as being open source only, and that an actual issue this causes for open source software is not-actually-MIT software.
GPL code is essentially "don't-touch-with-a-39-and-a-half-foot-pole source" to most people who want any control over their project or are developing in a professional setting.
I think it's mostly unfounded, but companies do avoid this for reasons other than wanting to directly control their users. I worked for a company where everything was Apache 2, BSD 3-clause, MIT, or similarly licensed. Since we distributed source regardless, this means less control over the users, even though it means they have the freedom to not pass it on to their own users. Our lawyers absolutely lost their shit at the suggestion that we include the GPL. Because a bunch of our customers absolutely lost their shit at the slightest hint of GPL, because they don't want to be sued for unintended virality.
Hear that, folks? In a world that's increasingly focused on sustainability and funding for software development, programmers with business aspirations should take note:
If you're working on something that you hope to (eventually?) make money from, but you also want to benefit from the collegial atmosphere of open source, then choose the GPL. This simple decision instantly eliminates a whole subset of would-be competitors, who you now don't have to worry about undermining your business or otherwise threatening your source of income while they rely on being able to use your own work against you, since the GPL automatically places your work in their do-not-touch category.
The GPL grants significantly more freedom to users. Users of MIT-licensed software don't necessarily even have the freedom to see the source code! All they're guaranteed is the ability to see a credit.
Developers are also users of a piece of software. GPL 3 restricts developers in insane ways where they are forced to contribute back any changes and even worse then that it basically infects all code that it touches. It's almost impossible for a commercial product to use GPL 3 licensed software at all. This is basically tyranny.
> Developers are also users of a piece of software.
This is true, and yet your conversation partner still has the winning answer. The point is that, notwithstanding these restrictions on developers—some of whom have the desire to be able to take without reciprocation—the freedom guaranteed by the GPL to users more than makes up for it. We're essentially talking about local versus global maxima here.
> It's almost impossible for a commercial product to use GPL 3 licensed software at all.
On the contrary—GPL is very beneficial, for the reasons I just laid out in another comment[1]. GPL-licensed code is not ipso facto any harder to commercialize than if you were to make the end result available under MIT. It's arguably even easier, since your competitors will have a more difficult time competing with you than if you'd chosen MIT. As Eben Moglen once put it, if you're trying to decide on a license, then by all means you should go with a permissive one—if you're what you're looking for is "a really good license for your competitor to use"[2].
You need only look to history then compare and contrast it with the industry's current preoccupation with funding the development of free and open source software. Red Hat/Cygnus were largely built on top of GPL code. Meanwhile, today's developers entrenched in the GitHub culture, with its permissive-first obsession with licenses like the MIT, have been bamboozled into working against their own interests by giving away their strongest bargaining chip when they decide to go with the flow instead of choosing the GPL.
Software, in general, has a lot more people using it than writing it. Successful software, anyway.
And super permissive licenses like MIT hurt developers too, because it means I oftentimes can't see the source code that someone else has modified, even though it would help me a lot to be able to do so. With GPL-licensed software, I am always guaranteed this freedom.
Those modifications would probably never have been made if the license was GPL because they would have just rewritten their own entire thing from scratch or licensed something else.
Forcing your users to have to GPL any of their code based on your code is controlling them more than releasing under a more sane permissive license. It's ironic that GPL is the true restriction of freedom for all the virtues it touts.
I think honestly this is something other providers (Google code when it was around, gitlab now) are much better at.