Apache vs. BSD licenses

[kmself at ix.netcom.com]

on Tue, Mar 20, 2001 at 11:13:22PM +0000, David Johnson (david at usermode.org) wrote:
> On Wednesday March 21 2001 06:41 am, kmself at ix.netcom.com wrote:
> 
> > > There's a difference between aligning and coinciding. If my goals
> > > coincided exactly with the FSF, you would be completely right. But if
> > > they differ even a tiny fraction, then the possibility exists that
> > > another license is more suited to my purposes. That's why multiple
> > > political parties exist in free nations, and why multiple free licenses
> > > should exist for Free Software.
> >
> > What differences, specifically?

> Coincide means to occupy equivalent positions, while align means to be on the 
> same line. The first is a location and the latter a direction.

I had in mind a discussion of degrees of freedom in software licensing
which are of interest to you.

I've had my own internal debates over the GNU GPL, whether it's "the one
true way", or merely good enough.  I have yet to provide myself an
answer I'm satisfied with.

I'll reiterate:  what Copyleft objectives do you have which are not met
or satisfied with the current GPL v.2?

There are others (lurking on this list, and you know who you are) who've
expressed a concern with the fact that the current state of free
software licensing makes it difficult to introduce new ideas into play.
I share this concern.  I do believe, strongly, that a very conservative
approach to licensing is healthy, and that a proliferation of licenses,
compatible or otherwise, is bad -- though incompatible licenses are
naturally worse.  This leads to increasing complexity on the legal
landscape, a landscape which a current near-exclusive focus on three
fundamental licenses --  GNU GPL, MIT/BSD, and MozPL -- has kept
relatively streamlined.  Though some have complained about the OSI
license approval pipeline and process, I remain half-convinced that a
slow process is a feature, not a bug.  Though I've suggested previously
steps which might help streamline it, as have others.

I've suggested previously and will reiterate a proposal for using a
reference in a system which might allow for evolution.  The original
suggestion was aimed at the MozPL and its kin (SCSSL, Jabber), though it
could be adapted.  

Under this scheme, core, immutable, licensing language is defined.
Items of variance, which I envision as largely pertaining to identity,
authoring/versioning authority, and jurisdiction or venue, would be
identified.  Parties wishing to adapt and adopt the license could do so.
Variants meeting guidelines would be considered equivalent.  Parties
would be free to propose changes to licensing terms -- having
authorship/versioning authority over their variant, they'd be free to do
so.  However, the standard revised licensing terms would have to be
agreed upon by some plurality [1] of parties.  Any of these pluralities
might decide to go their separate way.  There is a benefit, of course,
in maintaining compatibility between valuable code bases.  And there is
always the possibility that after one or more generations of divergence,
terms might later come to coincide (analogous to temporary forking of a
software development branch).  Independently of versioning authority,
maintainers of works which had already incorporated code under terms of
other licenses would (if required by these licenses) be constrained to
remain in coordination with any changes to terms of these licenses.

Easy?  No.  Unwieldy?  Maybe.  But this is about the only proposal I've
seen which remotely addresses to issues of integrity (not ceding
versioning authority to another organization or some trusted party as
the FSF), *and* of keeping legal language in concert.

--------------------
Notes:

1.  I've been reading too many patent claims

-- 
Karsten M. Self <kmself at ix.netcom.com>    http://kmself.home.netcom.com/
 What part of "Gestalt" don't you understand?       There is no K5 cabal
  http://gestalt-system.sourceforge.net/         http://www.kuro5hin.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20010321/bd48a2de/attachment.sig>