A dual license system for code libraries?

Mirko Boehm (FSFE) mirko at fsfe.org
Mon Feb 27 10:06:09 UTC 2017


> On 25 Feb 2017, at 09:54, Agner Fog <agner at agner.org> wrote:
> Hi, I have a problem with several open source projects. Neither GPL nor LGPL license seems to be appropriate.
> One such project is my C++ vector class library (http://agner.org/optimize/#vectorclass <http://agner.org/optimize/#vectorclass> )
> Right now, I am using a dual license system. The library is published under GPL, following the advice at
> https://www.gnu.org/licenses/why-not-lgpl.html <https://www.gnu.org/licenses/why-not-lgpl.html>
> However, there is a significant demand for using this library in commercial closed-source code. Therefore, I am selling commercial licenses to anybody who want to use the library in commercial code.
> Now, there is a problem with unifying the copyright. I want to put this code on github and make it a collective project. But then I can no longer be the only copyright owner. It is not fair that others should contribute to the project for free while I make profit on selling licenses. We would have to set up an organization to own the copyright and sell licenses. But the administration cost of running such an organization would probably eat up all the income. And open source programmers prefer to spend their time on programming, not on administration of an organization.
> An LGPL license is not possible because the program code that uses a class library will be a "derived work", not a "combined work", and it is impossible to meet the relinking requirement of LGPL. The application code and class library code are mixed together and compiled together so that the two cannot be separated.
> An Apache or BSD license might be possible, but I don't think commercial users like the requirement that the end product should include various required notices. Also, I think these licenses are too permissive. I like the protection against tivoization, DRM, and patent retaliation in GPL.
> More importantly, people would have little motivation to contribute to an open source library when their work only goes to somebody else's profit. The motivation would be higher if the effort could somehow contribute to the general goal of supporting free software. That's why I prefer the dual license solution. The only problem is who should own the copyright and sell commercial licenses?
> I have asked the FSF, but they are not willing to sell licenses, and frankly they are quite difficult to communicate with. That's why I am now taking the discussion to FSFE. Is there any other suitable non-profit organization who could be the copyright owner and sell licenses?
> I have also thought about a scheme that requires no administration. You would get a commercial license automatically by donating a certain amount of money to some non-profit organization and posting proof of payment to some repository. Would that work?
> Or do we need a completely new license concept for open software libraries and other code that is likely to be used in proprietary derived works? Any suggestions?

The situation you are describing cannot easily be solved with a license alone. Your intention is to release copyleft free software that can also be used in proprietary environments. You already went with dual-licensing. This is a proven approach that models your intention better than using an academic/permissive software license. 

Opening up the project to other contributors means to introduce a conflict of interest, as you describe correctly. If the plan is to stay with copyleft licensing (which I would recommend, but that is a personal opinion), you will have to solve two problems:
You will need permission/license from the other contributors to sell proprietary licenses.
You need a scheme that fairly distributes the licensing revenue so that it motivates people to contribute. You could pay out shares of the revenue to them, or you could make it a public service effort by donating a share or all of the proceeds to a organisation with aims that benefit the general public, for example FSFE.
A Contributor License Agreement (CLA) can be used to set up such a model. Usually, FSFE would not recommend using CLAs that enable proprietary licensing. However in your situation this is already the case, so in my understanding it would make your software more free (because others can contribute to it). Please be aware that this is not an official FSFE position.

Hope this helps, 

Mirko Boehm | mirko at kde.org | KDE e.V.
FSFE Fellow, FSFE Team Germany
Qt Certified Specialist
Request a meeting: https://doodle.com/mirkoboehm

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fsfe.org/pipermail/discussion/attachments/20170227/b3c6359d/attachment.html>

More information about the Discussion mailing list