"I released source code under the MIT license and people are now using it to their financial benefit. Who could have possibly seen this coming?"
Why does this keep happening? Why are so may developers blind to this obvious outcome?
Why does this keep happening? Why are so may developers blind to this obvious outcome?
Especially when your project is new it's also not often clear that this project will become something more serious later where you have to worry about such things as people cloning your project.
A lot of people say that it can prevent these situations but from working for large enterprises, a lot of the offerings that are created literally don’t even change the code. Thus they have nothing to contribute and have no obligation to release any source code.
GPL also does not prevent the corporation from building software in front of whatever GPL service it is. Kind of like the Linux kernel, why bother changing the kernel when you can build software in front of it and not change anything and thus have nothing to release.
Of course, the author cannot retroactively change the license of any previously distributed work. Anyone is free to fork off Bear from its last MIT code and do whatever they want with it.
So no, the MIT license does not "explicitly allow to relicense a project at any point" (emphasis mine). The MIT license allows licensees to license their derived work however they see fit, it has no effect on the relicensing by the licensor (the copyright holder).
> Any previous licenses used (MIT here) bear no effect whatsoever. There is no license in the world (and cannot be) that would prohibit the copyright owner from changing it.
I don’t think it’s that simple. The Bear project appears to have accepted external contributions under the original license, so the project is subject to that license as long as those contributions remain.
It may not be a big practical issue in this case, due to the MIT license being quite permissive, but if the project was e.g. GPL-licensed, the maintainer wouldn’t trivially be able to change the license in “whatever direction they want”. (And by “trivial” I mean without e.g. rewriting or discarding the external contributions.)
But you're right, relicensing requires the approval of all copyright holders, and in general there can be many. Of course many projects require the prospecting contributor sign a CLA where they relinquish their rights to the project in order to be able to contribute. Personally while I have signed some CLAs, such as the Go one where I retained my rights, I'd never sign one which required me to give away my copyright rights, precisely so they wouldn't be able to do a rugpull on me.
I believe that copyright law is the biggest weapon one has against open source rugpulls and one should not give it away.
[1] https://github.com/HermanMartinus/bearblog/blob/master/CONTR...
[2] https://github.com/HermanMartinus/bearblog/graphs/contributo...
I think MPL 2.0 is the ideal kind of copyleft, because of its scope being very clear.
> When is a program and its plug-ins considered a single combined program?
> It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program.
JSON data sent over the wire, particularly data with nested arrays and maps, and especially a bidirectional communication protocol, can reasonably count as "intimate communication" with "complex data structures" shipped "back and forth".
This is nonbinding guidance, but it is from the FSF, and it is legally untested afaik (not a lawyer). There's sufficient legal risk here that I'd be wary of using rich communication protocols with GPL programs, particularly if there isn't an explicit exception for that protocol.
No, shared memory is addressed later within the same answer.
> Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.
The first part of the answer clearly includes programs sending each other "complex data structures", including nested JSON data, over pipes.
> If the main program uses fork and exec to invoke plug-ins
Which limits a lot the relationship between the original program and the "plug-in" concept. I mean, we literally have binary proprietary blobs used as kernel drivers...
The GPL attaches to programs that are legally derivative works. So does any other license that doesn't explicitly grant the right to prepare and distribute derivative works, such as the overwhelming majority of commercial/proprietary licenses. The issue is with the overall copyright/legal system, not with the GPL specifically, and given that most entities are comfortable using at least some non-BSD programs it doesn't seem to worry people in practice.
There isn't a similar degree of legal risk with MPL 2.0, nor with non-copyleft licenses (which is the subject of this subthread, not proprietary licenses) -- whether or not a plugin counts as a combined work, there are no requirements on you.
There is a similar degree of legal risk with the overwhelming majority of licenses in use. Yes, using exclusively permissively-licensed software would let you avoid this particular risk - but given that essentially no-one (BSD advocates are, if anything, less scrupulous about avoiding proprietary software than GPL advocates - you rarely hear of BSD-land pushing firmware into a separate nonfree repository or the like) does that, it's clearly not a risk many people care much about.
In general, businesses acquire commercial licenses for proprietary software, which is a kind of derisking.
The FSF says a program that exchanges complex data structures with the covered program "can" be something that requires a license; they don't claim that it always or usually is. My position is that they're correct that it's possible (at least in some jurisdictions) but the risk is low in cases where you're not trying to do a technological end run around something you obviously need a license for.
> In general, businesses acquire commercial licenses for proprietary software, which is a kind of derisking.
Only if the license grants permission to do the thing you're doing! Otherwise you're no better off than if you had no license (and you're worse off than under the GPL, which at least permits you to prepare derivative works freely, only putting conditions on distributing them). Almost every commercial/proprietary license I've seen has a blanket prohibition on preparing or distributing derivative works.