4

Some projects are available under restrictive FOSS licenses (GPL or AGPL, for example) which preclude them from being used in proprietary projects. The developers can then sell separate commercial licenses which allow the code to be used in proprietary projects.

How common is this?

Examples I'm aware of:

MySQL

x264

Cygwin

Improve this question
1
  • I've come across it a few times, also in ExtJS: sencha.com/products/license.php I guess I wouldn't say it's common, but most things it is found in are supporting libraries or dependencies that might ultimately get linked in and could cause problems if they didn't allow commercial-compliant license terms.
    – opello
    Dec 28, 2010 at 6:30

2 Answers 2

Reset to default
8

Those licenses do not do what you think they do. Sadly, the GPL and similar licenses are widely misunderstood (even by the people that write them — by which I mean that the law often has a different idea of what given terms mean than the license writer).

The GPL does not preclude you from using it in proprietary projects. Many proprietary projects have dependancies on FOSS licensed applications or libraries. All it does is preclude you from trying to ship a binary without source, or to apply extra restrictions on those projects.

What's more, if you wrote the code in the first place, even if you publish it under the GPL, you can do anything you like, and make any exception you like. You can even stop producing code in that license and produce only proprietary licensed versions.

However, to answer your question. It's become quite "en vogue" for companies to publish a "community" version of a product and an "enterprise" version. Examples include Vayatta, Alfresco, Flowplayer, and a whole bunch more.

The idea is that anyone that needs support will buy it anyways, and those that don't wouldn't buy your program anyways. So it fosters a sort of "good will" even though it's really just a scheme.

Improve this answer
4
  • 1
    It also (in my opinion) provides a nice way to support the original development effort without potentially suffering lawsuits which could cause a company to have to release its IP if they do something outside the spirit of the GPL.
    – opello
    Dec 28, 2010 at 6:35
  • 1
    GPLed code cannot be used in products that are proprietary in the usual sense. It can be used in commercial products.
    – David Thornley
    Dec 28, 2010 at 15:16
  • @David Thornley - That depends entirely on many things. Can you directly copy code and place it within a proprietary application? No. However, there is much debate in the legal community over whether using it as as a shared library is the same thing (FSF says you can't do it, many lawyers say otherwise.. this is what I was getting at when I said that even the writers of the licenses don't always understand the legal interpretation of their licenses). Many aspects of the GPL have yet to be tested in court to know for sure which way a judge would rule.
    – Erik Funkenbusch
    Dec 28, 2010 at 16:04
  • 2
    To be safe, assume that linking creates a derived work. Some lawyers who've studied the issue say that's likely the case. What I meant by commercial use is things like the software I'm working on now, on my other monitor. It's proprietary, it's vital to our business, and it's not distributed. We could use all sorts of GPLed code in there (as a matter of fact, we do have code under licenses that forbid us from selling it), perfectly legally and with Richard Stallman's blessing.
    – David Thornley
    Dec 28, 2010 at 16:21
2

The GPL license has a couple of clauses/definitions that are not clear outside the original scope (C programming) that give corporations heartburn.

  1. If you extend a GPL project you are responsible to (a) advertise the fact, providing the GPL license to your users and (b) provide a copy of the source code to anyone who requests it. NOTE: a request can be required to be done in writing, as opposed to making it available for download.
  2. If you link to an GPL library you are not extending it, so the prior clause doesn't apply. Problem is that link means different things depending on who you are talking to--for example what does it mean in an interpreted language like Ruby?

It's for the reason of potentially giving away corporate secrets that most corporations shy away from GPL based projects. Additionally, there may be other legal/proprietary knowledge type risks that I'm not aware of.

Dual licensing is not uncommon. It's a way of ensuring that the base product is always available, while providing value to people willing to pay for it. It's also not uncommon to simply choose a FOSS license that doesn't contain the scary clauses such as the ASL, MIT license, or some variation. It gives corporations much less heartburn to provide attribution than the source code. In short it's better to say the product uses Apache Xerxes than to have to release the source code because it embedded a GPL'd XML parser.

Additional background on American copyright Back in the 90's I attended a 2 week seminar that covered copyright law, as pertains to the entertainment industry. That seminar was taught by one of the most pre-eminant lawyers focusing on the subject at that time: Al Schlessinger. What follows is a brief summary of information from that seminar (I myself am not a lawyer, I'm just repeating information):

  1. Copyright is real property, as in real-estate. It can be bought, sold, bequeathed, and donated just as land can.
  2. Use of copyrighted material is dictated by licenses, which in turn get their enforcement from contract law. A license is a contract.
  3. If the terms of the contract you are working under require you to turn over your copyright, you are in a "work for hire" situation. This is how record companies can screw over newbie bands unless they know what to look for. It is also RCA records screwed over Prince.
  4. GPL does not convert the copyright to the original GPL'd project owners, but specifies terms for the original copyrighted work's use. Essentially, that you would agree to expose your source code to those who asked for it. You still retain the copyright to the derived work--but not the original work that it was derived from.

It is for this reason that when faced with the prospect of incorporating GPL or LGPL code/libraries into your commercial application that you vet everything with a lawyer who specializes in this type of work. They exist, and my previous company used one to discover legal risks. The lawyers did point out the potential problem points, which we had to relay to our client.

The tricky point for dual licensing is that the entity who is licensing the work must be able to prove that they have the only copyright for the work. That is why when you become a committer on some of the larger umbrella organizations (GNU, Apache, etc.) you are required to sign an agreement that you turn over the copyright of that code to that organization. When that condition is met, the organization can dual license, change the license model, or whatever they need to do at will.

It's because there is enough Fear, Uncertainty, and Doubt (FUD) surrounding the GPL on both sides of the equation that recently there's been more of a push to use corporate friendly licensing models.

Can the project you derived your work from cry foul and claim that you are in violation of the terms of the license? Yes. Will they? Probably not. That doesn't mean you should flagrantly violate its terms however.

Improve this answer
11
  • 1
    Actually, the GPL does restrict linking to a library... which is the major difference between the GPL and LGPL.
    – Powerlord
    Dec 28, 2010 at 15:19
  • There is no distinction between extending and not extending in the GPL. Linking can constitute creating a derivative work. Moreover, the GPL cannot force anybody to release source code. That's not a legal remedy for copyright infringement.
    – David Thornley
    Dec 28, 2010 at 15:20
  • Good distinction. I've been through this process with a large client in the recent past. If I recall correctly, linking to a plain GPL library would cause your application to automatically be required to be GPL'd. Linking to the LGPL library would cause my second clause to come into play. At least this would be the intent according to Richard Stallman's doctrine.
    – Berin Loritsch
    Dec 28, 2010 at 15:23
  • @David Thornley, the intent and purpose of the Copyleft doctrine is to do exactly that. By agreeing to the terms of the GPL you are agreeing that you will be bound to releasing your derivative work source code.
    – Berin Loritsch
    Dec 28, 2010 at 15:29
  • continued... Because the definitions of derivative work are muddy enough to cause heartburn for most corporate lawyers, they will always advise to stay away from such libraries/code. Of course, if you are simply using the project and not creating any derivative work based on the code you are probably free and clear legally.
    – Berin Loritsch
    Dec 28, 2010 at 15:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.