|
> This gives the opportunity to use such a library without issues, and the end user never knows about these tools anyway. Why not something like MPLv2 then? It does give the opportunity to use the library without issues, the only constraint (compared to e.g. MIT) being that changes to the library needs to be distributed. If you don't change it, then it's pretty much like MIT. To me, MPLv2 is superior to MIT in the sense that it gives developers leverage against their management. If I tell my manager "I fixed a bug in this MIT library, can I contribute it upstream?", the answer is often "let's discuss that later" or "hmm we'll have to see with legal" or "are you sure that it is not a competitive advantage for us?". In my experience, managers never see value in contributing anything back. Now if the library is MPLv2, I can use it just like MIT, but if I fix a bug I can tell my manager: "it is MPLv2, which means that I must distribute my changes. Are you fine with me contributing them upstream?". Again in my experience, the manager will just say "if you have to, then do it". Even though (AFAIU) MPLv2 does not enforce contributing upstream: you just have to distribute the changes with the software (to your customers). But managers generally don't know anything about licenses, so "contributing upstream" is a good-enough approximation. TL;DR: with MPLv2, the developer has leverage to bring their changes upstream. With MIT, the manager can happily keep the changes proprietary. I am a developer, I want to open source my code. Therefore I want copyleft. |