This blog is no longer active, you can find my new stuff at: george3d6.com, epistem.ink, ontologi.cc, and phenomenologi.cc
Dual licensing GPL for fame and profit
Dual licensing with GPL is the idea that if I own a certain piece of GPL code, I can also relicense it as a proprietary library. This is how Oracle licenses Java and how QT licenses QT.
I - All rights for me but not for thee
But my general feeling is that there is some stigma associated with this practice, to quote gnu.org:
To release a nonfree program is always ethically tainted, but legally there is no obstacle to your doing this. If you are the copyright holder for the code, you can release it under various different non-exclusive licenses at various times.
The "ethically tainted" doesn't resonate with me, I think this licensing model should be encouraged.
I will admit I am kind of biased on this because I work on a for-profit GPL-license project. But it strikes me as silly that this business model is shunned by the open-source community in favor of licensing under MIT/BSD.
Dual licensing is a way in which the "owner" of the code ends up in an advantageous position compared to other users.
That is to say, a user must abide by the strict rules of the GPL license:
- Release all modifications.
- Potentially (depending on the specifics of the GPL license) have to release other projects that are used "in relation" to the library.
- Not ship the code under a different license.
The "owner" of the code abides by none of these and can thus benefit in ways that the users can't.
In the open-source utopia, where resources are aplenty for everyone, everything is open source and nothing is for sale, so dual-licensing doesn't fit that particular utopia. But we live in the real world, where money makes things a bit more complicated, and in the long term, dual-licensing might be better than equal-rights open licenses.
Well, developers have to eat.
Even worst, good software is made by good developers, developers which can get six-figure salaries designing skinner boxes. On the contingency that those developers aren't ideal altruists, they have to get way-above-subsistence salaries to work on useful open source projects instead of skinner boxes.
So if dual-licensing provides a middle ground for that which is better than the current situation where a lot of good software is proprietary, what's the harm?
Some would say it's a middle ground that will hamper the development of truly free software. But who release said truly free software anyway?
II - Who release fully-free projects
When it comes to license like MIT and BSD, that impose no restrictions upon usage, where the "owner" doesn't exist, it's interesting to look at who release projects under those licenses:
a) Students or hobbyists, people creating software for fun, notoriety, and experience.
b) Very large companies (Facebook, Google, Amazon, Uber) or government & donation founded organizations (Universities, Public Research centers, software foundations such as GNU, Apache, and LSF)
The first group is one I don't wish to dismiss, I think a lot of important programs stem from here. But their end goal is not to work for free for their whole life. Usually, they moonlight for their open-source projects and work a paid gig to earn money. A small minority can be funded by donations, but it's a small minority.
The project I use for allowing comments on this website (remark42), has 2.3k stars on GitHub and earns 9$/month from donations. The project I work on has 2.9k stars on Github and an operating budget of a few million dollars.
You can certainly get to a point where you are funded by donations, but the reality is that it's not a good enough incentive. Doubly so since the developers working on these projects are usually the "creme de la creme", releasing and maintaining truly useful software usually requires expertise only a small fraction of engineers have.
The second group, the corporation and government-funded teams can only exist because of the scale.
Why can Facebook develop PyTorch?
- Because Facebook hires so many ML engineers that in the cost-benefit analysis it's cheaper to have your internal framework be popular enough such that you can get already-trained people from day 1. The < 100 people working full time on PyTorch save months of training for every single one of the thousands of ML people facebook hires, since it can hire people that already know PyTorch.
- Because Facebook doesn't dominate by having better ML models, it dominates by having thousands of times more data than anyone else. It's in facebook's interest to keep research open since it's objective is not to get ahead, but just to stay even, or at least not fall significantly behind.
Why can Nvidia assign engineers to dozens of open source ML and game-engine projects?
- Because Nvidia makes hundreds of billions each year selling GPUs. The little work they put into those libraries to make sure it works ideally with their GPUs is insignificant to the revenue they get from those markets.
Why can Google develop TensorFlow?
- For about the same reasons as Facebook.
- Because they can make a lot more money from selling/renting TensorFlow optimized hardware.
And that's on the happier side of the spectrum. On the "shadier" end of the scale, one could argue projects like Flutter and Angular might be worth their investment because they make spyware-free browsers like Firefox send-class citizens in the war for the web, not to mention easier integration into internet-monopolizing schemas like AMP.
You've also got, I will admit, projects that seem to be open source purely for flexing. To my knowledge, Yandex might have well never released Clickhouse and the column-store database landscape would have been set back 10+ years for it. Why did they do it? Maybe just because few dozens of people working on it wanted to showcase how good they are.
But at the end of the day, this is not a reliable model
III - Profit motives
So would it not be nice for open source if one can bring profit motives into the whole thing?
Even better, profit from the people that don't support or contribute to open source, but not from those that do.
It seems to me like double-licensing with GPL achieves just that. One can release a project and charge large companies for using it, at the risk of breaking the license if they don't pay. Even if a lot of them will use the software illegally, as is the case now, the threat of lawsuits will end up deterring some or most heavy-users from doing so.
On the other hand, people using the project in an open-source project of their own have nothing to worry about.
The only problem that remains here is the fact that you can't chain GPL projects. That is to say, one can't use GPL code in their own double-licensed GPL code, but there are workarounds for that (e.g. isolating the GPL dependency and open-sourcing the changes to that alone). Still, this seems like the kind of problem that could be fixed by an off-shoot of the GPL meant for just this use-case.
This model keeps all the advantages of GPL, in that it incentives your users to open-source their product. It doesn't force them to do so, like a purely-GPL licensed software might, but it's not like GPL is working as intended, outside of a few cases where enough money was at stake to sue (e.g. TiVo), violations of the GPL go unpunished.
Currently, a company that wants to include GPL into their project has two options:
- Use the code in such a way that GPL won't force you to open source the rest of your code.
- Use the code and break the license.
Since the wording of GPL is not that clear, it could often be argued that companies go for alternative nr 2. After all, who will ever know?
But what if the "pay the maintainer a small sum" option was available. Wouldn't the liability afraid giants look towards this much more favorably than either of the other 2 options? Wouldn't this, in the long run, give an edge to open source projects which don't have to worry about these fees ?
Thus I think I come in squarely on the side of open-source companies dual-licensing GPL on their product[s]. A model that already exists and often enough has great success (see MariaDB and Aerospike).
It's a nice compromise for moving towards a more open world, without having to live in Stallman's utopia. It's an amazingly pragmatic solution and anyone who reads this blog knows I'm a fan of those.
Published on: 2020-10-04
