Community vs. Corporate Linux, The Coming Divide

tobyj writes "MadPenguin.org discusses the great divide that will separate corporate Linux (companies that are working with Microsoft) and community Linux (companies that haven't yet partnered with Microsoft) and their impact on Linux as a whole. Matt Hartley writes, "For Linux enthusiasts, the rules are simple and clear to interpret. But for Microsoft and its Linux partners, we will see plenty of them pointing to self-created loopholes, which will result in fierce debate, and perhaps even worse, blatant defiance. As a collective community, we'd like to think that this whole issue will just blow over, but with the massive migration of so many Windows users and companies that wish to capitalize on this migration, defiance of the GPL will happen and more so than ever before."

Comments

Can't happen

[Tony]

...could it take the same patent lawsuit against Linux that SCO attempted, while using it's rightful ownership?

The SCO lawsuit was not about patents, it was about contract violation and copyright infringement. Patents were never mentioned by SCO.

Novell now has legal standing with respect to Unix copyrights. However, they distribute an entire GNU/Linux distribution, much of which (including the Linux kernel) is under the GPL. Therefore, they can't even attack Linux for copyright infringement. So Novell has no "trump card" when it comes to Linux.

Re:Think Freedom.

[einhverfr]

I can't recall if I've seen this around but: if nobody "owns" software, is it subject to tragedy of the commons?

Nobody owns the software as a whole. Lots of pieces are owned by lots of people with agreements between them. Think of owning a city lot where a portion of the lot is owned by you but is public right-of-way (i.e. the city is legally allowed to come and build a road or sidewalk on part of it if they want without further compensation to you).

There are probably arguments either way, but because software isn't a scarce commodity I don't know how that old idea applies.

No, but developer effort is a scarce commodity. Business models, whether open or closed source which develop software for the public use generally have to have a way to make back the costs of the use of that scarce commodity. Software license fees are one way. Charging customers for development they need is another.

Effective competition against software license models can only happen with the understanding of the real economic bottleneck-- software developers and engineers.

I would suspect that as long as there are enough people willing and able to create new software and / or modify what's out there the issues would be minimized. The big problem I see with no "owners" of software is that ensuring you had "the real deal" would be difficult, because there's nobody to go after for "shoddy" software. Essentially, without an owner there is no responsibility. This could be detrimental, because it would mean that every organization that wants to use software would then have to hire competent software folks to evaluate and analyze the software, or make it all proprietary in the first place.

Don't confuse code with trademark. Linus owns the Linux trademark. It is only Linux if Linus says so. He does not own all the code in the project, however.

PostgreSQL has taken a similar approach. As has LedgerSMB, but in both these cases, there is a core committee who retains ownership of the trademarks for QA purposes.

Sure the local crowd here on /. is capable of evaluating most small projects, but in an environment that really relies on software as a tool, you can't "guess" that it will do what you want, and having the luxury (yes it's a luxury) of a software "owner" on which to place responsibility is probably a good thing.

What exactly needs to be owned? The project as a whole needs to be managed by a small group of people at most. The trademark needs to be owned and managed. But this does *not* correspond with a need for ownership of the source code.

"The software" is a pretty vague term in the open source world. As is "ownership."

Having software so "open" that responsibility cannot be assigned is actually a bad thing.

Now, the balance between those two concepts - responsibility and freedom - is a tricky one to be sure. At the very least, I agree that software should be "open" in the sense that you should be able to change what you have locally to do whatever you want; responsibility only comes in when you distribute those changes to others (or the use of modified bits can affect others).

Not really. Most community-driven (rather than company-driven, such as MySQL) projects end up eventually with three levels of community:

1) Core team (sometimes called a Steering Committee or Project Management Team), most of which have commit rights, and all are involved in managing the project.

2) Committers who have earned the right to commit based on past performance. Their rights are granted and managed by the core team.

3) Other community members including both users and developers. Any contributions from them have to go through committers.

The key to making this work is the commitment to community and transparency of process. Sure, just anyone can't go commit to svn-- only those who have proven themselves.