There is a lot of rhetoric about what the GPL does or doesn't do. I am
going to try to help cut through some of this based on my experiences in
both GPL and BSD-type communities.
On 8/20/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
>
>
> > Ok, sorry, the 'kool aid' remark does go beyond simply stating your
> point of
> > view, as you are branding the people who like the GPL (myself for one)
> as
> > cultists and delusional. I may be delusional, but I don't belong to any
> cult.
>
> Actually no. I have no problem with people that believe the GPL or the
> GPL thought process. I have software that I have released under the GPL
> including LedgerSMB code ;).
I am going to stay out of this as much as possible. I did not read Josh's
comment as an ad hominem but rather a vauge reference to the fact that there
*is* a set of followers of St. IGNUcious of the Church of Emacs out there
who may not think for themselves. I personally don't think that there are
any members of our community which fit this description however.
Part of my reasoning for saying that they are not in the community is that
we have not heard express that sort of devotion to RMS. If course the fact
that most of us on the core team use vim might help drive them away ;-)
This part of this thread will go no where positive in a hurry, I would
> be happy to discuss it directly with you. I will say though that I do
> not believe that you are part of any cult or that you are delusional.
Agreed. Lets all assume it was not an ad hominem and leave it at that.
>
> > (tm) and be able to run away with the milk, the cows and the farm to
> boot.
> > The GPL is what protects everyone from this - it puts all the companies
> at
> > the same level, and it turns the software (the OS anyway) into a
> commodity
> > rather than something they can hold everyone for ransom with.
>
> The GPL had nothing to do with this beyond it being a license that fit
> the model at the time. The OSL provides the same provisions without the
> rhetoric. If you read the OSL, you will see that it is very GPL like.
The OSL looks very GPL-like but use of the software is not outside the scope
of the license. Would we really want a license that would require that
everyone who sets up a public demo of our software also provide the source
for whatever version that demo was running? Wouldn't this reduce the impact
of issuing security fixes (we can't compel the demos to upgrade, can we)?
Thus appearances aside, the OSL is far more like the Affero GPL (and is in
fact more extreme even than that license) than the GNU GPL. That aside, I
do like the jurisdiction provisions of the OSL as they solve a major problem
with the GPL IMO (IANAL, of course).
I would agree with everything but the OSL comment, however. Assuming I am
right about the inability of the *bsd projects to recruit newbie kernel
developers being a primary failing of that group, the question becomes how
different would Linux look today? Would it be correct to say that large
vendors would not contribute code back?
My suspicion, looking at projects like Apache and PostgreSQL is that there
would likely be two competing forces within the community. The first would
be the "software freedom" folks who would be working on expanding the
commons, and the second would be the vendor who would proprietize the code,
sell licensing fees, etc. Both would be contributing back code but for
different reasons, and eventually the open source version would gain
near-total market share.
Unlike what BSD-advocates tend to say, the code is not entirely freely
given. The system of development under BSD licenses rewards contribution
and penalizes witholding changes through the economics of software
maintenance. Basically, a hypothetical BSD linux would force vendors to
think about what they *really* need to keep for themselves and contribute
back everything else. As the commons expand, it becomes harder to justify
keeping things for themselves. Hence you would probably see the Free
version being the only mainstream version eventually, with proprietary
bundles being viable only in niche markets outside the accepted best
practices of the community. This is exactly what has happened with
PostgreSQL and to a much smaller extent with Apache (smaller because
Websphere may not be exactly a niche product, but I would expect its
deployment to be far lower than similar Apache/Tomcat/etc. deployments).
For example, in the PostgreSQL community, EnterpriseDB contributes
non-Oracle-compat changes back to the main distro because if they fail to do
so, maintaining these changes becomes a resource drain. Furthermore if
another proprietary vendor witholds changes to the same parts of the
software, the fact that EnterpriseDB contributes their changes back drives
*up* the cost of maintenance of their competitors. If people don't
contribute their changes back, other contributions don't necessarily
subsidize their R&D. After a certain point, they may actually start sapping
it. Note that the Oracle compat portions are not generally desired by the
PostgreSQL community anyway.
Similar examples can be found relative to Command Prompt (who licenses a
proprietary replication solution for PostgreSQL but has expressed a
willingness to contribute it *if* it can be included in the core PostgreSQL
distribution), Green Plum (which offers Business Intelligence solutions
based on PostgreSQL-- their proprietary components involve cross-node
parallel execution of query components), etc. The Apache community enjoys a
similar relationship with Covalent, etc. In every case that I can think of
wrt these communities, all desired contributions are given because there is
no reason not to (you don't, then someone else will and you will be screwed
when you want to upgrade your source to the newer version because the code
probably won't be compatible).
In the end, I think that the question of licensing is secondary to the
question of community building. There are cases where the GPL v2 is better
than the BSDL and vice versa for specific projects. THe role of the vendor
in the community is probably the largest consideration here. But I don't
generally agree that one is necessary to ensure Software Freedom.
Of course, this has nothing to do with what license policy we choose. Just
offering a different perspective. I actually think we need to be
conservative about license changes, and I would support going to fairly
large lengths to avoiding upgrading to the GPL v3 (including possibly
forking dependencies as they upgrade their licenses). I have strong
concerns about the GPL v3 in general, and I also think it is *bad* for the
community for us to substantially change the terms of the license part-way
through without a very compelling reason. Although I have no problem with
the BSDL, I would probably resist changing the license of new code to that
license as a matter of policy for the community reason.
>
> > Now, having said that, I don't see any particular reason at the moment
> to
> > move to GPL v3. It's new, and it rarely pays to be an early adopter
> unless
> > you're doing cutting edge stuff - and frankly there's nothing cutting
> edge
> > about accounting or simple web apps. So, I think we're best to stay the
> > course and let the GPL v3 take hold (or not), discuss the option as
> something
> > to consider (or not) for the future and leave it at that.
>
> Agreed.
Agreed simply because I have no solution to the question of "how do we
handle likely problems as we go forward." While these problems are harder
to handle as we go forward, I don't see any solutions which would suit the
community.
Best Wishes,
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
