Does dual licensing threaten free software?

After the dotcom doldrums of the past five years, there is a new wind blowing through the world of commercial software. It's open source, but not as we know it. The first-generation start-ups like LinuxCare, TurboLinux and even Red Hat, were essentially service companies. Today, an increasingly-favored approach is to employ dual licensing to create two revenue streams: one based on providing services for free software and the other through traditional commercial licenses to products that are generally based on the free software version.

A whole new generation of open source companies like MySQL, SugarCRM and JasperSoft have shown that such an approach can be highly successful, and this is encouraging others to adopt the same model – Scalix is the latest to join the club. Before this becomes established as the de facto standard for open source business in the dotcom 2.0 world, now might be a good time to examine whether it is really is such a good thing for free software, or whether it might even represent a threat to its fundamental principles.

The impetus behind dual licensing comes from a desire to find ways of making money from free software other than simply by providing services. This is explicitly stated in what was probably the first such dual license, the Aladdin Free Public License, created in 1994 by L. Peter Deutsch's company Aladdin Enterprises for the Ghostscript program:

While Aladdin Enterprises respects and supports the philosophy of the Open Source Definition, and shares the desire of the GNU project to keep licensed software freely redistributable in both source and object form, we feel that Open Source licenses unfairly prevent developers of useful software from being compensated proportionately when others profit financially from their work. This License attempts to ensure that those who receive, redistribute, and contribute to the licensed Program according to the Open Source and Free Software philosophies have the right to do so, while retaining for the developer(s) of the Program the power to make those who use the Program to enhance the value of commercial products pay for the privilege of doing so.

This sounds eminently reasonable, but there was a sting the tail: although Ghostscript was also distributed under the GNU GPL, it was not the most up-to-date version, which was only available under the more restrictive Aladdin Free Public License. So, in this case, there was a definite loss for the free software world when the dual-licensing policy was adopted. (This has now been remedied: the latest Ghostscript is available under the GNU GPL.)

Some consider dual licensing in general to be a problem for free software. For example, in an extensive essay on the subject, Lajos Moczar has raised concerns that dual licensing introduces an asymmetry into the licensing of code that unduly favors the owner of the copyright, and weakens one of the crucial checks within the open source world, the possibility of a fork.

One of the key characteristics of free software is that the threat of forking keeps teams close to their community. If they diverge too far from the desires of the majority, other developers can simply fork the code and move things in a direction more aligned with users. Similarly, the possibility of forking helps keep companies that base their businesses on free software honest: if they cease to serve the community whose work they build on, a fork allows the latter to re-assert control.

It is this fact that makes “buying

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

It is to hear that the

Aladdin Jewelry's picture

It is to hear that the up-to-date version, available under the more restrictive Aladdin Free Public License.In fact, Aladdin is being used as a name in different products like jewelry etc.

Advantages of Dual-source

Mr. Shiny & New's picture

The author writes that dual licensed code is no better than closed-source code if the users employ the commercial license. Isn't this the whole point of dual-licensed code? It's GPL so that it's Free for users who want freedom. And for users who want to sell non-free software to their users, they also have to trade in their own freedoms. What's wrong with that? Those users are perfectly free to go ahead and use the GPL version if they can abide by those terms. If they can't, they at least have the option of buying a commercial license. Right away there are advantages that are obvious; the so-called disadvantages are in reality the simple cost of playing the game. It's as if you're saying "People should be allowed to use GPL code in non-GPL products", since that's the only way to allow "open source" code in "closed source" products, and then what you end up with is the BSD license.

As for where the power lies, the GPL license ensures that the ability to fork is always there. Consider the Mozilla Suite. It was to be shut down and abandonned. Some developers decided to pick it up. If Mozilla hadn't sanctioned the project they would have forked it. They wouldn't have to triple-license their code if they don't want to. Also, the author seems to be under the impression that non-copyright holders are somehow losing out because they can't fork and take the code private. They are not losing anything, because no GPL product allows that. The copyright holder always holds all the cards. The FSF could conceivably release close-source versions of the GNU tools if they wanted to; nobody would be able to stop them. Maybe the argument should be "copyright assignment gives power away to someone else", which is true irrespective of any pre-existing dual-licenses.

Finally, copyright owners that have dual-licensed products do not necessarily rely on the community to develop features. They may get features from the community but they may not. And they ultimately control whether or not the community's work is even accepted. Again, the community is free to fork. GNU used to maintain a fork of Ghostscript separately from GPL Alladin ghostscript. Joomla will be maintained separately from Mambo. PostNuke was forked from PHPNuke. It happens, and sometimes one fork dies and sometimes they both survive.

Points of view

Glyn Moody's picture

The points you are make are all good ones, but they look at things from a community point of view. What I was trying to explore was the new generation of open source businesses that are using dual licenses from a commercial point of view.

You can fork the GNU GPL code, certainly; but you can't "fork" the commercial model. That is, you can't really set up another company to do what the copyright holders are doing. So, in a sense, you have lost the power to offer users a choice, generally one of the key features of the free software world, of which these businesses are now a part.

Now, it may be that you think this is a privilege that goes with owning the code. All I am saying is that people should be aware of the particular dynamics of dual licensing, and then decide whether or not they are happy with them.

GPL remains GPL

Anonymous's picture

Mr. Shiny

I agree with you that GPL remains GPL code and it does not make a difference if it is released under a dual license or not. I do not know why the author is trying to bash dual licensing with such a moot point.

I also doubt if MySQL make the majority of their income from services and am sure that it is from licensing fees.

Yes, but...

Glyn Moody's picture

The GPL remains GPL, so the community side may be the same, but the commercial side of things is different - see my comment above. And I'm not trying to bash dual licensing, merely point out that it can change the free software landscape, and that people need to be aware of this.

As for MySQL, here's what Marten Mickos said to me a few weeks ago:

GM: You still have a commercial licence alongside the GNU GPL: for what reasons do people choose the commercial licence?

MM: Well, the interesting thing is that we are known for the dual licensing models, and as pioneers of it, but today our main business is not on dual licensing, because we are now becoming a major player in the enterprise market and with Web sites, and they don't buy commercial licenses from us, they buy subscriptions.

GM: You mean they use the GNU GPL licence and pay for support?

MM: Yes. So the dual licensing thing was a good starting model for us and it works well in the OEM space, where somebody OEMs the code from us, and puts it into their own products that they ship to customers. And that's where it works very well. But if you look at our most famous customers, like Google and Yahoo, Travelocity and Craig's List they do not use our commercial licence.

You are slightly wrong - possible to provide commercial service

hanishkvc's picture

Hi,

You seem to have slightly got the things wrong.
If one forks a dual license code using the GPL part then the new code cannot be put back into a commercial license again ( well unless the people who forked it own the copyright to the code). But this is also true if the code was originally released under pure GPL and not dual license.

Independent of whether a code is under GPL or GPL+SomeOther (i.e dual license) or GPL+someother=>Forked in either of these 3 cases a new company may come up and start providing commercial service support for either of these codes so there is no change there again.

Why companies may release something under dual license is because, there could be some other people or companies which want to use your code in their own product but not give back their changes to your code back to you or at the very least the community. In such cases if you release the code under GPL then it cann't be achieved. However if the copyright holder licenses the code under dual licensing then such arrangements can be done.

With the above thing in mind, if you look at your statements once again you would realise that even if the original company had release anything under GPL or Duallicense (GPL+somethingelse) only the original copyright holder would have allowed a 3rd party to use the code without GPL restrictions and not the community unless the community is the copyright holder. If community was the copyright holder then a company wouldn't have been able to license this code under any other license (like commercial or otherwise) in the first place.

There are drawbacks

Anonymous's picture

Usually dual-licensed stuff is released as GPL instead of a more sane and lighter approach, meaning you can use the code (link to it) only in GPL application. Other license types like LGPL, BSD have issues with this.

Other problem is that such projects are reluctant to use open source libraries (even if in LGPL) because it often doesn't fit in their commercial picture. Example is Trolltech developing Arthur instead of using Cairo for rendering of vector graphics (though they stated that reason is purely the immaturity of Cairo).

new-style open source companies

Glyn Moody's picture

What I wanted to examine was the kind of new-style open source companies like JBoss with their "professional open source". At the heart of this is the idea that the company employs all the main coders, and so owns the copyright to all the code. This means they can offer that code under a dual license - and no one else can.

So although third parties can fork the GPL'd code, and offer support for it (and hence the commercial license code, I suppose - although this presumably depends on the details of that license and whether any proprietary code is added, as sometimes happens), the one thing they cannot do is offer the GPL'd code under a commercial license: only the company can do that, because they own the copyright.

Some customers might require this option: for example, if they are worried about using GPL'd code (as well as for the reason you give). So there is still this asymmetry in that only one entity can offer commercial licenses of this kind that may be required by some customers. The level playing-field that you find elsewhere in free software has a tilt to it.

Now, it may be, as I wrote, that this is only a transitional phase; or it may be that this isn't a big problem in the real world. But nonetheless, the case of these new-style open source companies does seem to cut across the traditional "right to fork" - not so much because you can't fork, but because there is something else that you can't do. I was merely suggesting that we should be aware of this.

Well put

Anonymous's picture

Coming at it another way, licenses exist to model motives for writing software, and ensure those motives perpetuate.
I like the GPL, but wouldn't privilege it as the sole ethical motive for writing software, and thereby denigrate all others.
To make that ethical argument stick, you'd need either
a) a whole lot of philosophical development, or
b) a revelation from God.

ethics behind GPL.

Anonymous's picture

If your curious the founder of GNU project and FSF is a guy named 'Richard Stallman'. People refer to him as RMS after his handle.

People refer to him as a nut, but he is just has strong focus and repeats himself and lots of people don't like it when people hold strong convictions. I don't expect you to agree with him, of course. I dont' agree with everything either.

The following is just a general explaination of the ethical foundantion of the GPL license based on how I understand it. It
s not my personal opinion, just my personal understanding.

Keep in mind that from his viewpoint the source code IS the program. A 'binary' is just a executable form of the program and not having the source code cripples it's usefullness for end users.

GPL is ment to protect the fundamental freedoms of end users. Software isn't hardware, it isn't a book, it isn't a car, it isn't a peice of art or a movie or song and software is something else and like all those there are different rules based on their fundamental nature. For instance if you build a engine part a person can copy it if they feel like it. It's not protected by copyright, only patents. A book is a story and modifying it fundatmentally changes what it is as a artistic peice. It's protected by copyrights and not patents. Nobody can copy it without your permission. So software is like neither, changing it improves it's functionality and doesn't destroy it's purpose like a book or documentation, but it's infinately replicatable and malable and protected by copyrights so it's not like a car motor or peice of a car motor.

So software is fundmentally different and new in the human experiance. That's not to say that a programmer shouldn't be paid or that you shouldn't pay to obtain software. (all of that is expressly allowed under the GPL) It's just that once you obtain it you should have certain rights as a individual.

These rights are described by the 'four freedoms' that the GPL is designed specificly to protect.. Or if you don't like 'protect', the license is designed to 'ensure' that end users (not just programmers wanting to create their own programs) will ALWAYS have these freedoms protected.

And since in computer programming lingo zero is the first number then it's numbered 0 through 4 (a bit tongue-in-cheek thing)

* The freedom to run the program, for any purpose (freedom 0).
* The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
* The freedom to redistribute copies so you can help your neighbor (freedom 2).
* The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.

So those are the ethical doo-dads that the GPL is setup to protect and ensure that all software provided by programmers for end users will retain those freedoms and that all software that ends up using that GPL'd code should respect those freedoms also.

Of course this is a direct threat for traditional software companies that use a combination of licensing restrictions, coding restrictions, and hiding source code, from end users to create a artificial (if software is freely copiable you have a infinate supply of that paticular program) scarcity of some program to drive up demand to create a market were they can sell the software.

As far as programmers making a living.. The idea is that the vast majority (90%+) of programmers make a living customizing software or creating customized software for a paticular audiance. There is no restriction in the GPL that says you have to give your code away without charging for the program.. It just requires that you provide code for customers/end users (that you specificly supplied with the binary version of the program) that request it. Very few programmers make a living producing propriatory software for a large audiance.

Essentially if all software was free and open source it would turn programmers into a sort of modern equivelent of highly skilled tradesmen.

"Of course this is a direct

arcnewuss's picture

"Of course this is a direct threat for traditional software companies that use a combination of licensing restrictions, coding restrictions, and hiding source code, from end users to create a artificial scarcity of some program to drive up demand to create a market were they can sell the software."

Scarcity does not drive up demand. If the product is costless to replicate then supply is infinite and price is zero, if you create scarcity demand is not affected but the price increase since people who need it the most will be willing to pay.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix