Hi John and others,
My major reason for suggesting that a change to the BSDL would not be good
is because I think that consistant licensing is good for the community and
therefore we should try to keep the license as much as possible under the
same spirit as possible under the GPL v2 or later circumstnaces that existed
prior to the release of the GPL v3.
I am not opposed to releasing some components if we decided to do so as a
community under more permissive licenses, however. This could be done in
order to avoid legal ambiguity relating to distribution of interop
components, for example (IANAL).
I think that the actual effect of the licenses is not as different as people
suggest. Because I am open to adding additional permissions to some
components, I feel like it is worth sharing my reasons why I dont see such
as an inherent danger. Hence I have included responses to additional points
below.
On 8/21/07, John Locke <[EMAIL PROTECTED]> 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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
