On 8/21/07, John Locke <..hidden..> wrote:
Decibel! wrote:
> On Sat, Aug 18, 2007 at 11:26:34AM -0700, John Locke wrote:
>
>> As a commercial company, I prefer releasing code under the GPL instead
>> of the LGPL (or the Apache or the BSD licenses, etc), simply because it
>> prevents competitors from taking my code, extending it, and
>> commercializing it without distributing their enhancements. The GPL
>> keeps the playing field level, prevents my code from being unfairly used
>> against me. As far as which version, I don't know enough about v3 to
>> make an informed decision, so we're sticking to v2 for the time being.
>>
>
> I view that argument as a variation on security through obscurity. If
> another company can take code that you've written and do a better job of
> selling it than you can then the problem isn't with them, or the
> license... it's with your company.
>
>
Well, the GPL doesn't prevent exactly that from happening. In fact, the
GPL makes the playing field level so that those who can provide the best
service can compete the best.
In general, I have liked the GPL v2 because I think it helps smaller projects stay viable and protects companies from subsidizing their competition when development is slow. I have also felt that it was a good balance of freedom and restriction to this end.
I do not think the GPL v3 is so balanced and so I don't like it :-)
I would argue that it keeps all the
vendors honest--if your competitor can take your code, close it up, and
sell it on the marketplace as "new and improved," enhanced with an NSA
spy plugin nobody else knows about....
Are nVidia's closed source driver components for Linux a GPL violation? If so, why has nobody tried to enforce this over the substantial time that this has been going on? Thus does the GPL actually guarantee the user any rights that the LGPL does not?
(BTW, I am not proposing a change to the LGPL because by my reading, and IANAL, it does not solve any licensing problems I can foresee in the future. I am just raising issues that I think are worth considering.)
The "unfairly" word in my quote
is crucial here. If you compete with me on a GPL-leveled playing field
and win, more power to you. (Just like LSMB). If the fork then starts
putting secret stuff and preventing other forks, now that's no longer
fair to the original authors or the community as a whole.
The BSDL has a different way of addressing this but it only applies when the pace of development is strong. When pace of development is slow, contributions to BSD projects may have the effect of subsidizing competitors' R&D. However, if you can build a larger community, the economics change.
Consider PostgreSQL. Imagine if Green Plum and EnterpriseDB both make similar changes to the software for performance reasons, but these changes are of course not quite identical and certainly not code-compatible. Suppose Green Plum contributes the changes back and EnterpriseDB does not. And assume this contribution is accepted. Who wins and who loses? THe developers at EnterpriseDB are now going to be stuck porting their add-ons to use the code that Green Plum contributed or just forking the whole thing and going their own way (thus taking on themselves the *entire* maintenance cost of the codebase). Furthermore, if EnterpriseDB's changes were *really* better, then they have to make the choice of sticking with the common base or maintaining an increasingly complex patch with the knowledge that they will lose some of what they put into it if they don't.
In short, while not strictly required, contribution is economically rewarded in viable BSDL projects and witholding contribution-worthy material is punished. This is done with economic rather than legal tools.
Our pace of development is sufficiently high that if we were BSDL, I would not be concerned about it.
Now, I would not generally suggest moving the whole project to BSDL though we arguably could move all code there by
2.0 (leaving translations and the work as a whole still GPL). However, I could imagine circumstances where additional permissions/license exceptions might not be a bad thing. For example, if we had a useful module which was not a part of our differentiation strategy, and there was desire to cooperate with open source projects which were under incompatible licenses, I would be for granting required permissions to allow the combined rights of both licenses. This is simply because I think this is beneficial to the community. But obviously I woul expect everyone in the community to have a right to comment before making the decision with relevant copyright holders to endorse this as a project.
Best Wisehs,
Chris Travers