Please read the current version of this article at GNU.org.

Companies that develop free software and release it under the GNU GPL sometimes distribute some copies of the code in other ways. If they distribute the exact same code under a different license to certain users that pay for this, typically permitting including the code in proprietary programs, we call it "selling exceptions".

Companies normally sell exceptions using code they themselves have developed. Since they hold the copyright on that code, they can legally distribute it in any manner, even in multiple manners in parallel. But what happens when you publish a modified version of that free program, and the company wants to include your changes in its version?

Since you got the program under the GPL, when you distribute a modified version you have to license it under the GPL. If the company receives a copy, it will be able to use those changes under the GPL; it won't be allowed to include your changes in that program and sell exceptions for it. It also won't be able to release purely proprietary versions containing your code. If this is the outcome you want, you get it by default. However, if the company intends to sell exceptions, it will probably decide not to use your changes.

Suppose, though, that you're not opposed to selling exceptions and you're willing to let the company do so while including your changes in the program. You can agree to this, but you need to be careful about what you sign, or you may be surprised by the results.

The company will probably invite you to assign or license your copyright to the company. That in itself is not inherently bad; for instance, many GNU software developers have assigned copyrights to the FSF. However, the FSF never sells exceptions, and its assignment contracts include a commitment to distribute the contributor's code only with source and only permitting redistribution.

The company's proposed contract may not include such a commitment. It might instead let the company use your changes any way it likes. If you sign that, the company could do various things with your code. It could keep selling exceptions for a program including your code. It could release purely proprietary modified or extended versions including your code. It could even include your code only in proprietary versions. Your contribution of code could turn out to be, in effect, a donation to proprietary software.

It is up to you which of these activities to permit, but here are the FSF's recommendations. If you plan to make major contributions to the project, insist that the contribution agreement require that software versions including your contributions be available to the public under a free software license. This will allow the developer to sell exceptions, but prevent it from using your contributions in software that is only available under a proprietary license.

If your contributions are smaller, you could accept a weaker condition that the company make your contributions available in a free software release as well as possibly in nonfree programs. This would allow the company to use your contributions in modified software that's only available under a proprietary license. Releasing proprietary software is never a good thing, but if your changes are smaller, it might be more important to improve the free version than resist the nonfree versions.

You can control these outcomes by insisting on the proper conditions in the contract. To allow selling exceptions for the program that contains your code, but refuse to let the company release purely proprietary versions containing your code, you can insist on a condition more or less like this:

Any program based on (as defined in GNU General Public License version 3) Hacker's code that FOO distributes shall be made available by FOO under a) the “GNU General Public License (GPL), version 2 or later”, or b) the licensing in (a), above, but with “2” replaced by any higher existing GPL version number. Provided FOO makes the program available as source code gratis to the public in this way, it may also distribute the identical program to some of its users under terms permitting them to link the program's code with nonfree code and release the combination in binary form under a license of their own choosing.

Or, if what you object to is that some variant of your code might be released solely in a proprietary version, you can insist on a condition more or less like this:

Any program based on (as defined in GNU General Public License version 3) Hacker's code that FOO distributes shall be made available by FOO under a) the “GNU General Public License (GPL), version 2 or later”, or b) the licensing in (a), above, but with “2” replaced by any higher existing GPL version number. Provided FOO makes the program available as source code gratis to the public in this way, it may also distribute the same version of Hacker's code in other programs released under other licenses of its own choosing.

If the program is released under the GNU Affero GPL, then add “Affero” before “General”, change “GPL” to “AGPL”, change “2 or” to “3 or”, and it could make sense to replace “that FOO distributes” with “that FOO distributes, or deploys on a server accessible to users other than FOO”.

The FSF has had these texts reviewed by a lawyer, but you should get your own legal advice before using them.

When a company says which of these conditions it will accept, that will show you how far it plans to depart from the principles of free software. Then you can respond to ensure your work will contribute to the free software community and not be diverted into proprietary software.

This article was updated on March 27, 2018.