Dual software license (one open, one not)

Question

In an answer to a question about the GPL, David wrote,

If your CMS is something that others might want to build on, you can dual-license it. In this case, you want to release under the GPL or similar to prevent somebody else from taking the F/OS code and taking it proprietary. Some companies have done very well doing this.

Questions:

• What are some good examples of such a 'dual license'?
• What is the nature/summary of the other, non-GPL license?
• Why would some customers want the other license? If they're developers, is it so that they can use your library in their own closed-source product? If they're end-users, is it because your GPL-license is for a less-capable version of your application software?
• If others do build / have built on top of what you released via the GPL, is there any way for you to use those additions in your own closed software? Might your license say, "this is GPL and anything you derive from it is also GPL, except that I (the author of the original thing) can also use your additions in my closed-source software"?
• Do you agree that GPL is the best open-source license to use, when you are dual-licensing?

Answer 1

What are some good examples of such a 'dual license'?

MySQL and Qt

See also this article from OSS Watch on dual licencing, and this wikipedia article on Multi-Licensing

What is the nature/summary of the other, non-GPL license?

In the case of MySQL, here's what they say:

Sun offers a commercial license for all of its MySQL software that is embedded in or bundled with another application. The commercial license allows OEMs, ISVs and VARs to distribute commercial binaries of MySQL software with their own commercial software without subjecting that software to the GPL and its requirement to distribute source code.

Here's how Qt answer that question:

The commercial Qt license includes email support, access to upgrades and allows you to develop fully closed source software. The LGPL carries some restrictions regarding the ability for users to relink libraries and other restrictions that may impose architectural requirements that some organizations might not be comfortable with.

Why would some customers want the other license?

Usually, to enable them to do things which would not be allowed under the GPL licence, e.g. linking with incompatible code, not releasing patches or extensions to the base code etc.

If others do build / have built on top of what you released via the GPL, is there any way for you to use those additions in your own closed software?

You would need to obtain such a licence from those contributors.

If you modified the GPL licence as you suggest, it would no longer be the GPL licence, or even GPL compatible.

Do you agree that GPL is the best open-source license to use, when you are dual-licensing?

That's really up to you, but the choice is really between something like the GPL, and something even more liberal like the BSD licence, in which case having a commercial licence might be moot.

Don't forget that you can sell your services in the form of support, rather than a commercial licence. As the main coder, you are likely the best source of support for it.

Other related Stack Overflow questions

• Interfacing with GPL applications from MIT licensed code - is a dual-license unavoidable?
• What happens when open source software has two or more licenses?
• What does it mean to double license?

Answer 2

The entire point of using the GPL in this case is to hinder the "taking" of your code by another commercial entity. If you used a more liberal license (BSD, Apache, etc.), there is nothing to prevent another entity from taking that code in house, embedding it in to their proprietary product, closing the source and then distributing their new product with your OSS code in it.

The GPL deters others from doing this as their own code will also be GPL'd. The primary role of the GPL is to force distributors of software to release source code, and it achieves this primarily through this "viral" aspect of the license.

For those who wish to build upon your software, if they are not comfortable with the GPL, they would be obliged to negotiate with you for a separate license. Their version of the software and the license would be separate from the GPL'd licensed software.

If you release code out under the GPL, and others also release derivative works based upon that code, this new code would be copyrighted by the new authors, however, even with copyright, they are still under the terms of the GPL. Since you do NOT have copyright to this new code, you can not, similarly, "take" their code in to your proprietary code base. However, since they maintain copyright, you can negotiate a new license agreement with these authors outside of the GPL.

In the end, only the copyright holders can change the license of a piece of software. Some projects require contributors to SHARE copyright so that while components of the project are sourced by different authors, all of which hold copyright on their individual code contributions, by sharing the copyright, the project also retains copyright over the entire project as well. This is done a lot with commercial open source projects.

Of course, any code once released, remains licensed as it was. You can't retroactively change the license of a distributed piece of software.

Answer 3

Check out Wikipedia's article on this.

You cannot use GPL additions to your software in non-GPL software, and you cannot amend the GPL to allow this (as this change is incompatible with the GPL). However, you can create your own license. I suspect such a change in the license will scare off most serious FOSS proponents, though.

Customers will usually want the other license because of corporate policy, which is usually rooted in (justified) fear that if they release their proprietary software as FOSS software, many of their customers will just find a free copy on the internet rather than paying for it.

Answer 4

I was thinking primarily of MySQL when discussing dual licensing, but Qt is another excellent example.

There are two ways to go with the non-F/OS license. One is to provide a more capable version for the consumer, and one is to allow other development organizations to incorporate your software into their own product, under a proprietary license. I believe the latter has had the greatest successes. One problem with the demoware approach is that somebody else can take what you've written and add the missing functionality. In either case, the non-F/OS license should be a pretty standard commercial license, forbidding unauthorized copying and allowing the purchaser to do something useful. If you're licensing it for somebody else to incorporate, it should allow such use, perhaps for a lump sum and perhaps for royalties.

If you release as GPL, you're very limited in the additional restrictions you can put on, and demanding special treatment from other people isn't one of them. If you like something somebody else does, and you want it for your proprietary version, negotiate with the other person.

The GPL is an excellent license in such a dual-license system. It prevents anybody else from taking your code and reissuing it as their proprietary version. It's a very popular license, well known in the F/OSS communities, and is compatible with a whole lot of other software. Something like a BSD license would permit somebody else to close up your version, which is generally not what you want. You could write your own license, but that will lead to incompatibilities and might make people reluctant to use the free version. (You want people to use the free version, as it's the advertising for the commercial version.)