[Bf-committers] extension clause
davidj at gmail.com
Tue Nov 16 02:41:28 CET 2010
On Mon, Nov 15, 2010 at 1:58 PM, Dan Eicher <dan at trollwerks.org> wrote:
> There's actually two issues being discussed here, the ability to use GPL'd
> software *in house* and the ability to distribute non-GPL'd extensions.
> The first needs no license change at all, companies just need to be careful
> not to release their (presumably extremely valuable) software into the
I've stated why my experience strongly disagrees with the above statement.
Rather than state something as true which some here (myself included) feel
to be patently false, perhaps you could provide some examples of companies
that have gone down this path and how they arrived there?
Perhaps this example will help you understand why the constraint to "be
careful not to release" is not acceptable to companies.
If an employee acts improperly and releases copyrighted code to a
competitor, copyright law will prevent that competitor from using the code.
If an employee acts improperly and releases a binary which contains both GPL
and non-GPL code, the GPL says the source code must be released. There are
no provisions for "withdrawing" the distribution. The moment it happens, the
company is infringing the GPL and can face legal action. Further, if source
code were improperly distributed, rather than be able to use their copyright
of their own code to prevent it's use or distribution, the world can use the
fact that it "is not independent and separate" from GPL code to argue that
the entire code must be GPL and thus be free. This is too great a risk for a
company to operate under.
Again, in my experience, companies find it is not legally acceptable to link
GPL code with closed-source code, for any reason. If you believe otherwise,
I'm interested to hear examples of when you were in that decision making
situation, and how you arrived at the decision to link GPL with propritary
code "in secret". Anything else is just speculation.
More information about the Bf-committers