I've attached Eric S. Raymond's reply to my post last night.
Eric was mentioned in the open source lecture during the colloquium.
You can learn more about him and read some of his writings at his home
page: http://www.tuxedo.org/~esr/
Enjoy!
-- Jon Winters http://www.obscurasite.com/"Everybody loves the GIMP!" http://www.gimp.org/
---------- Forwarded message ---------- Date: Mon, 24 Apr 2000 02:09:08 -0400 From: Eric S. Raymond <esr@thyrsus.com> To: Jon Winters <winters@obscurasite.com> Cc: unrev-II@egroups.com, rms@gnu.org Subject: Re: [unrev-II] License Model: Preliminary Suggestion
Jon Winters <winters@obscurasite.com>: > Successful open source projects do this nicely. > > > There's only so much you can make from support contracts. > > If we're going to enable GM to make or save an extra 10 billion one > > year, as a side effect of getting the software we need to save our > > collective skins, it's hard to see how it would be wrong to get a > > slice of that, so we can do a better and faster job of (hopefully) > > saving our skins. On the other hand, for some reason the open source > > standard seems to have completely ruled out that option, even though > > it appears to me, on the surface at least, to be completely reasonable. > > Do you have any insight into how that decision was reached? Do you > > know of any good sources that give a rationale for it? > > ESR and RMS, help me out here... you're more qualified than I am to > answer this.
I think the question you're asking is why community practice (and the OSD) excludes "semi-open" licenses that have restrictions or fees attached to commercial use, but not to noncommercial use or development.
There are at least three reasons:
1. "Commercial use" is not a category for which there is a legally accepted bright-line test. Thus, "semi-open" licenses with conditions on commercial use entail legal exposure risks that many potential users and codevelopers have great difficulty evaluating. These risks and the concomitant uncertainty exert fatal chilling effects on many kinds of behavior the open-source community would like to encourage. As a concrete example, consider a CD-ROM packager making decisions about what to include on a CD-ROM anthology. If he includes software with a "commercial-use" restriction and makes a profit on the sales, is he violating the restriction?
2. Semi-open licenses create privileges by which some parties to the development may profit from the software in ways forbidden to other parties. This sort of power asymmetry is flatly unacceptable to most open-source developers -- it feels like exploitation to them. This is a gut issue that generates a lot of anger in the community.
3. Non-fee restructions in semi-open licenses (for example, clauses assigning a privileged design role to a named organization, or forbidding forking) are felt to interfere unacceptably with the croitical peer-review process.
The OSD reflects a strong community consensus, based on experience, that the putative benefits of semi-open licenses are simply not worth these costs.
> > > If Sun had delivered Java with an open source VM code base on day one, > > > there would never have been this hord of over 100 slightly > > > incompatible reimplimented JVMs all over the place -- making reliable > > > Java code delivery to an arbitrary end user the nightmare it is today. > > > That is why Java is considered by many to be dead on the browser for > > > end users, and is now being used mainly in servlets. I use this as a > > > cautionary tale -- pick the wrong license and much effort and good > > > intentions may go for nothing and the wheel gets reinvented (badly) > > > anyway. > > > > > One wonders what the result would have been had the results been freely > > available to the "evil empire", without the financial resources to carry > > on a legal battle -- or to fund the small army of developers who have > > developed the GUI libraries, multimedia libraries, and other stuff for > > the platform. It would have been nice if it had been truly open source > > -- or would it. Would the result have been as useful for servlets, or > > any more standard for browsers?
We actually know the answer to these questions from parallel cases such as Perl and Python where the code is open. In these cases, the languages (a) have not fragmented, (b) have in fact developed huge support communities and well-developed libraries, and (c) have spawned substantial money-making businesses who do, in fact, fund continuing development.
Sun's Java strategy has therefore been a quite unambiguous failure. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>
Let us hope our weapons are never needed --but do not forget what the common people knew when they demanded the Bill of Rights: An armed citizenry is the first defense, the best defense, and the final defense against tyranny. If guns are outlawed, only the government will have guns. Only the police, the secret police, the military, the hired servants of our rulers. Only the government -- and a few outlaws. I intend to be among the outlaws. -- Edward Abbey, "Abbey's Road", 1979
------------------------------------------------------------------------ IT Professionals: Match your unique skills with the best IT projects at http://click.egroups.com/1/3381/3/_/444287/_/956583569/ ------------------------------------------------------------------------
Community email addresses: Post message: unrev-II@onelist.com Subscribe: unrev-II-subscribe@onelist.com Unsubscribe: unrev-II-unsubscribe@onelist.com List owner: unrev-II-owner@onelist.com
Shortcut URL to this page: http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2b29 : Mon Apr 24 2000 - 06:47:02 PDT