On 8/20/07, Joshua D. Drake <..hidden..> 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