3 ms·
It is the difference between amending documentation (MIT) and producing infrastructure (MPL/LGPL) to ensure that whatever is currently in-tree and covered by th
by JSQuagmire 10y ago
It is the difference between amending documentation (MIT) and producing infrastructure (MPL/LGPL) to ensure that whatever is currently in-tree and covered by the license is exactly what is available for download in the event anyone ever patches it... else you are out of compliance. It isn't just changes, either, it's the files in their entirety.[1]
In a perfect world, no company would balk at having a GitHub account and having a public fork available, but many companies out there right now are still rather conservative about these things. Some barely use source control. MIT is simply one of the easiest licenses for these places to comply with. In my personal experience working at unglamorous places like these, they're fine returning patches as long as they never have to think about the legal implications or feel like there's a burden for using the code in the first place.
The MPL is a poor choice for this sort of code because it makes the assumption that distribution is a given and will happen automatically, but if you're doing application development rather than web development that simply is not true that the code will always be a 'View Source' away. There are certainly applications where this license would be more appropriate, but I do not think an isomorphic vDOM library would be one of them, since this is rather foundational glue.
It would be rather nice if trueadm would reconsider, if possible.
[1]: https://www.mozilla.org/en-US/MPL/2.0/ https://www.mozilla.org/en-US/MPL/2.0/
[1a]: https://tldrlegal.com/license/mozilla-public-license-2.0-%28mpl-2%29 https://tldrlegal.com/license/mozilla-public-license-2.0-%28...
- trueadm 10y agoThanks for filling me in on the details of MIT vs MPL. I'll switch over to MIT now that I know this.
- JSQuagmire 10y agoFantastic, thank you so much for the hard work!