One big question is: "if a non-GPL software S dynamically links to a GPL library L, is S a derivative work is L"? There is no clear, legal answer to that question at this point [1]. There are just opinions. Your opinion is that, "no, S shouldn't be considered a derivative work of L". I agree, but since this argument hasn't been settled, a court could disagree with us. a) Obviously, if a court were to disagree with us, it would just be illegal for a vendor to distribute S. And most lawyers will stop their thinking here: since the matter hasn't been settled, and there is a good chance for this to be illegal, they will just advice their client not to use any GPL code in their software. b) But even if a court were to agree with us, the vendor of S would still have to ask its users to download and install L separately. Imagine that S uses a number of libraries (L1, L2, L3...). It will quickly becomes unpractical to ask users to download and install all those libraries before they can use S. Choose your poison: illegal or highly unpractical. Most will say that the best option is to avoid the poison altogether, i.e.: don't use GPL software. With this in mind, some companies figured that they could distribute their software as GPL and brand it as open source, knowing that most of the people interested in that software won't be able to use it under the GPL, and will have to acquire a commercial license. This is very much like the dealers who advertise a car that normally sells for $20,000 as a "$5,000 special for this coming weekend only", writing in the fine print that this offer is limited to 2 cars. In both cases the vendor isn't technically a liar, but just knows that most of his client just won't be able to get the car for $5,000 (they will have to pay $20,000) or won't be able to use the software under the GPL license (they will have to acquire a commercial license). Yes, apparently that trick works for some dealers, and some software vendors. But it is not a trick I feel comfortable with. Especially since there are other ways to sell licenses; as the publisher of an "open source for all" software (licensed under the LGPL, Apache license, BSD...) you have at least two ways to drive licensing revenue: * Selling versions that contain additional features for which the code isn't open source. Not need to elaborate on this one, since this is already something you are doing today. * Selling "certified builds". Those are builds 100% based on the open source code but that are only provided to your clients who acquired a license. You would then provide updates (bug fixes) for those builds. This is what RedHat does with their RedHat Enterprise Linux, and I find this particularly interesting because it has been working quite well for them, and is something that provides real value to companies without precluding the use an "open source for all" license such as LGPL. [1] http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works