I would like to start a thread about reviewing the licensing model for LVGL, concretely the core library.
I think that LVGL has all the features of what I like to call “trascendental software”, like the Linux kernel, Apache web server and others. Imagine what would have been of the Linux kernel if Linus Torvalds would have chosen the MIT license.
I think a good option for the next major version of LVGL is MPL (Mozilla Public License), which could be seen as an LGPL but at a file level: MPL 2.0 FAQ — Mozilla
This way contributors can guarantee that their code remain open-source, business users can still use LVGL free of charge, but if they need to modify LVGL core to improve it, they will require to share the changes upstream, so the open-source community can benefit as much as they benefit from LVGL.
Another big concern is patents, which MIT license does not address directly, and that can lead to patent trolling.
It’s very simple, widely used and well understood by everyone.
It encourages everyone to use the library (since there are no limitations). With other licenses, users might be intimidated by a license they are not familiar with or not fully understand. So simple/well known license encourages larger user base.
Regarding MPL:
In my opinion, this is too restrictive.
Suppose I’m changing something in LVGL which I cannot open source for whatever reason (patents, my company doesn’t allow it, etc.). With MPL this would mean I can’t use LVGL any more!
Today I can contribute to the community even if I can’t open source all my changes to LVGL. I can still contribute some of my changes, participate in discussions, report bugs, etc.
But with this restriction, I would simply need to select another (possibly commercial) library instead of LVGL.
In other words, every user is a contributor, even if he can’t share every change he makes in the code. The total size of the user base matters, and I don’t think we should do something that might reduce it.
Does this problem really exist in the real world?
I mean, could you point to a case where someone took an existing MIT licensed code, patented it, and sued the original source owner for patent infringement?
It very easy to show that the patent was registered after the original source was created, so how could this be a problem?
In my opinion, this is too restrictive.
Suppose I’m changing something in LVGL which I cannot open source for whatever reason (patents, my company doesn’t allow it, etc.). With MPL this would mean I can’t use LVGL any more!
Today I can contribute to the community even if I can’t open source all my changes to LVGL. I can still contribute some of my changes, participate in discussions, report bugs, etc.
But with this restriction, I would simply need to select another (possibly commercial) library instead of LVGL.
What about a dual licensing model? Would you as a contributor agree for a commercial license that allowed that use? Say, the commercial license has a competitive price with, for instance, Qt.
This would be a much more open model than some other libraries, Qt itself being dual licensed under the (L)GPL/Commercial, while others like MiniGUI only offer GPL/Commercial.
About patents, is a problem that is starting, since laws differ between countries. Many times patent trolls start a lawsuit knowing they would not win, but generally the litigation costs for the other party forces them to come down to a settlement (so they are basically muggers).
Related patent lawsuits involving open-source somehow:
Patent trolls may rely on many kind of artifices like submarine patents to ambush their prey.
A license like MPL protects you against patent related issues, as it has a fail-safe mechanism that states:
5.2. If You initiate litigation against any entity by asserting a patent infringement claim (excluding declaratory judgment actions, counter-claims, and cross-claims) alleging that a Contributor Version directly or indirectly infringes any patent, then the rights granted to You by any and all Contributors for the Covered Software under Section 2.1 of this License shall terminate.
There is a vast number of large MIT licensed projects on Github, so it’s a bit hard to imagine that the license is as fatally flawed as stated in the blog post.
If the concern is just patent trolling and providing this is really a potential issue, then Apache v2 would probably suffice. It also seems to be more in line with the current MIT License and widely used.
Just one thought came to mind about keeping modification open (although @amirgon already comment about it):
Working on lot of GUI projects as a contractor sometimes I needed to tweak LVGL for specific use cases. The customers usually profit oriented companies and I believe it’d be very difficult to to tell them “I made some cool modification on LVGL just for you… You paid for it… But now I need to open source it and make it available for everyone”.
Yes, I agree. It is a very valid point about “partial” contribution from proprietary source back to LVGL.
I only hope that no one abuses the sublicense clause of MIT, back to my example of the fruit tree, that someone makes a (kind of) proprietary jelly out of the fruit (LVGL) and overtakes or obscures LVGL (or make gardeners work mainly for jelly-makers for free, while they receive all the benefits, because other than morals nothing else forces you to give back).
That’s why I mentioned Linux, I think that if it would have a extremely permissive license, there would have been many attempts at proprietary commercial Linux, coming with driver compatibility issues and all sort of problems… and at the end the original project would have been lost in history.
LVGL wouldn’t be cloned every 2 minutes if it had a more restrictive license.
In the long term, I believe that every seroius fork of LVGL (either commercial or not) would be inclined to contribute changes back to LVGL for a few simple reasons:
It’s much easier to contribute changes once, than merge the same changes over and over again when merging every new version of upstream LVGL into the fork.
It’s always beneficial to receive additional reviews and feedback on changes, especially reviews from LVGL core developers.
My change might be useful for others in the community and as a result others might spend their time improving it, finding bugs in it etc. instead of me doing that.
For a fork which is highly active for enough time, these reasons usually overpower other tendencies to keep changes “private” or “internal”.
Even those who never contribute back would still open bug reports when they face problems, ask questions and participate in discussions etc. and those are also “contributions” to the project.
So I don’t think that some other more restrictive license would have any positive effect on the amount of contributions to LVGL.
On the other hand, a more restrictive license could reduce the total number of users and lower the adoption rate of LVGL vs. other alternatives.
I see LVGL’s permissive license as a feature - an important feature no less than any other technical one, that has a significant impact on the success of LVGL.