Subject: Re: problems with open source
From: bruce@perens.com
Date: 22 Mar 1999 18:38:44 -0000

From: Nassib Nassar <nassar@etymon.com>
> 1) Good publicity and widespread acceptance of the product.  Easy to
> leverage for consulting.

Yes, this is a very strong benefit.

> 2) Good for the community.  In an ideal world, we shouldn't be slaves
> to corporations selling binary executables.  Most importantly, we can
> maintain our own computer system, the way people used to be able to
> fix their own car or radio before everything turned to "black boxes"
> and integrated circuit boards.

But there is some question regarding how good for the community your product
really is once you put on a much more restrictive license.

> 3) It's hard for anybody to undercut a free product.

Including you.

> 1) It's harder than it sounds to make a commercial version different
> enough that people will pay for it.  Of course this depends on the
> type of software.  It can be a significant problem.

It sounds as if you are just trying to make an "improved" version of the
same product. That's probably not enough. Digital Creations' tack is to
keep the infrastructure free and to do proprietary work in vertical markets. 
Sendmail Inc's is to write separate software, such as configuration programs,
as well as an improved version of the base product (though I still question
the wisdom of choosing sendmail as a base product).

> 3) Users contribute changes, but unless they willingly sign over
> copyrights, I can't incorporate those changes and still be able to
> re-license commercial versions to customers (using different terms),
> because I'll no longer own the entire source code.  NPL and MozPL
> address this problem, but they also are much less restrictive about
> re-distribution.

You can add a license term that requires that distributors of modifications
automaticaly grant you a license to those modifications. I suggest that you
start with an existing license and change it as little as possible, as we are
running into problems because of the multiplicity of incompatible licenses. 

> 4) Users contribute changes, putting pressure on us to add not only
> features people request, but also features that they have contributed
> code for, even if I don't have the rights to use that code (i.e. we
> have to redo it from scratch, see #3).

That you can solve with a license change.

I think you should consider that not all software needs to be Open Source.
Make some proprietary software to provide your livelyhood. Open up what you
can. I am afraid that the more restrictive licenses may actually do more
damage to our community than straight proprietary software, because half-free
software acts to discourage people from making an entirely free solution, and
leads the free software community down the slippery slope of accepting
progressively more restrictive licenses.

Free-it-over-time strategies, which are used by Alladin Ghostcscript
and others, seem to discourage collaboration. A recently suggested variation
attempts to foster collaboration by paying for modifications, but its details
seem very cumbersome.

	Thanks

	Bruce Perens