[erlang-questions] [OT] Re: GPL vs. whatever [was: Erlang UUID]

Michael Truog <>
Sun Mar 18 02:08:00 CET 2012


On 03/17/2012 04:33 PM, Loïc Hoguin wrote:
> On 03/17/2012 07:59 PM, Kostis Sagonas wrote:
>> On 03/17/2012 07:24 PM, Jon Watte wrote:
>>> The problem with GPL, even for a business that releases the source, is
>>> that it becomes a lot harder to accept contributions from the rest of
>>> the world. With GPL 3, the IP provisions make that pretty much a
>>> non-starter for a business operating in the US business climate. Thus, a
>>> GPL release (or AGPL release) from a commercial entity into the world
>>> pretty much guarantees that it will be a one-way street, where fixes
>>> won't work their way back up-stream.
>>
>> I really do not understand what sort of situation and/or business
>> climate you are describing.
>>
>> Suppose I use a software X from company/organization/some developers
>> which was released under GPL and I find a bug in it and correct it. What
>> exactly is it that prevents me from sending the fixes back to the
>> company/organization/developers of X for possible inclusion in the next
>> release? Similarly if I enhance X with some additional functionality.
>> What does business climate have to do with sending bug reports, bug
>> fixes or enhancements? Why is this a one-way street as you claim?
>
> Suppose you and your competitors were using the same open source project as a basis for their platform. Fixing bugs, or improving the software performance, and not contributing upstream gives you an advantage over your competition. You have the fixes, they don't.
>
> If it's (A)GPL, you need to publish these fixes, and lose your advantage. If it's BSD, you can use it and keep your fixes to yourself and gain an advantage over your competition.
>
> Either way the changes wouldn't be pushed back to upstream directly, because GPL only forces you to publish the changes, not feed them back to upstream. So chances are upstream wouldn't get the improvements anyway. Your competitors would, though, because they know you and they'll go get your sources directly.
>
> Your choice then becomes: do I want businesses to think twice before using my software?
>
I agree that fixes could be seen as a competitive advantage.  However, in practice, I think that becomes rare when you compare BSD projects to GPL.  The BSD projects are generally known for their quality, whereas the GPL projects are generally known as feature-driven.  So, the difference can be seen between projects like OpenBSD and Ubuntu Linux.  OpenBSD is very concerned about code quality and eliminating any possible security concerns, so they are unlikely to have new features that open the potential for security problems (especially remote ones, but local ones also).  Ubuntu Linux is best understood when broken apart.  Ubuntu is about usability and a slow graphical interface to improve Linux usability.  Linux is the kernel and supporting code that is known for security problems, though never as bad as Windows.  When you consider the middle-of-the-road, you have FreeBSD which offers more features and decent usability, so closer to Linux, but with more concerns about
security and code quality.  NetBSD is another, but more of a focus on supporting many architectures.  FreeBSD is the one that Apple saw fit to include within OSX.

So, thinking about these different projects, the commercial users of the BSD software are unlikely to have the knowledge to fix errors easily unless they are paying one of the people involved in the project.  If they are paying a person involved within the project, then the change will go back into the public source code.  This is generally how it must work to provide the high quality software they have been during the past years.

Your suggestion provides a conspiracy theory that is meant to justify GPL usage by assuming a greedy company that wanted to keep bugfixes as a competitive advantage would somehow care about the legality of the license.  However, in reality, I believe the situation is very different.





More information about the erlang-questions mailing list