A dual license system for code libraries?

Paul Boddie paul at boddie.org.uk
Sat Feb 25 17:49:16 UTC 2017

On Saturday 25. February 2017 15.43.54 you wrote:
> On 25-02-2017 14:44, Paul Boddie wrote:
> > ...this is almost like asking for business advice
> Don't get me wrong. It is not my goal to make money. My goal is to make
> free software libraries.

But it is still like asking for business advice, because many of the issues 
are exactly like structuring the interests in a business. I mentioned the 
matter of assessing shares in a project, and this is the kind of thing that 
platforms like Gratipay explicitly avoid because it is a difficult problem:

"Gratipay does not determine how payments are allocated and is not responsible 
for how Project Owners distribute payments. Any agreement between the 
Project's Owner and other Collaborators regarding the allocation of payments 
is solely between those parties."


Just about any incentive scheme in any kind of organisation causes problems in 
this regard.


> > Where a scheme advocates putting proprietary software in front of users,
> > it is not going to get the support of the FSF, because even the LGPL is
> > effectively a barely palatable concession to the idea that Free Software
> > might be used in proprietary software under certain circumstances. I
> > don't think you should expect the FSFE to take a different position.
> That's the nature of a software library. It can be used in many
> different contexts - free as well as proprietary.
> If a company wants to make a piece of proprietary software for a
> specific purpose then they will do so no matter what. If they can't use
> my GPL library they will find another way. It is not realistic that we
> can coerce them to make their software free if their business is to sell
> software. But we can make them contribute to funding free software if
> this is cheaper for them than making their own library from scratch. My
> project doesn't need any funding, so the money can go to some other free
> software projects (which might ultimately outcompete some proprietary
> software).

But think of the effect that facilitating proprietary software has, too! It 
might be much cheaper for a company to spend small amounts on licensing what 
is otherwise Free Software so that they can sell their own products for 
substantial amounts, undermining the development of Free Software alternatives 
to their products. That's precisely the situation one sees when people 
complain about the lack of equivalent Free Software applications in a market 
where people routinely choose proprietary software applications.

Of course they can develop their own form of your library's functionality. 
There is an argument that they do not do so because they do not have to. If 
you charged such companies a lot more money, maybe they would. I would argue 
that this would be a way of quantifying the damage done to Free Software 
efforts to develop similar applications or functionality: what those companies 
save by licensing software from you at its current pricing levels is perhaps 
the minimum amount of money lost to Free Software projects.

> The dual license system for software libraries that I am proposing will
> serve two purposes:
> 1. It gives open source projects that use the library an advantage over
> proprietary projects using the same library.
> 2. It generates a revenue that may be used for funding other free
> software projects.
> If a library uses GPL only, it will make an incentive for somebody else
> to make a proprietary alternative to the library (which will possibly be
> so similar to the free code that we would have a nasty battle over
> possible copyright violation).

Surely that would only happen for works that are either trivial or cannot be 
expressed in more than one way. But either way, the GPL is a guarantor of end-
user freedom, so you have to decide whether that is important to you or not. 
It is clearly important to the FSF.

> If we use a more permissive license (Apache or BSD) then we will allow
> proprietary code makers to free ride and make money on our open source
> work without contributing anything in return.

Right. Not that this is potentially so different from your situation, though, 
because projects like PostgreSQL are permissively licensed, but they do have 
companies operating in their community that do fund the development of such 
projects. The issue here is whether those companies contribute enough back to 
the project or not. However, PostgreSQL and FreeBSD, amongst others, do at 
least seem to be sustained by contributions of different kinds.

> > I think that more attention should be given to funding mechanisms for
> > Free Software.
> This is indeed what I am proposing. The problem is that we need an
> organization to handle the money.
> I think this is an unresolved issue in the open source movement. How do
> we deal with software libraries and other pieces of code that can be
> reused in proprietary software (and is so valuable that private
> companies will pay for it).

I can't talk about "open source" motivations, but in the Free Software 
movement the issue of reusing code in proprietary software is not unresolved: 
it is just not of any real interest or concern; indeed, it is seen as an 
undesirable thing prevented as much as possible by Free Software licences.

> > For what it's worth, you could look at what existing businesses have done
> > in this area already. There have been several companies that have
> > offered dual- licensing schemes, and some of them may even have offered
> > something resembling what you are trying to achieve.
> But I don't want to make a company - I just want to make code :-)

Sure, but what you are asking for is effectively a licensing model that is 
rather like what such companies have already done. Maybe someone could set up 
an organisation that employs software licences that may or may not be Free 
Software to handle the administrative aspects of this, but I don't see why the 
FSF or FSFE would be suitable hosts for such activities.


More information about the Discussion mailing list