Why Plan-9 licensing?

[Karsten M. Self]

on Tue, Oct 23, 2001 at 05:13:38PM -0500, Jim Choate (ravage at einstein.ssz.com) wrote:
> On Mon, 22 Oct 2001, Karsten M. Self wrote:
> 
> > The trend in free software licensing has been strong reluctance to
> > accepting novel licenses.
> 
> Right, that's why there are so many of them out there...

Noting, as above, the majority having very low adoption.

> > > Interaction for who, the author or the user? 
> > 
> > Interaction between licenses.  It's more overhead for the developer
> > to deal with. 
> 
> Interaction between licenses for who?...
> 
> You're using a flawed model. There are three 'roles'; author,
> distributor, user. Any license must interact with all three roles. The
> fact is that the license doesn't effect the developer nearly as much
> as the distributor and the end user. You're only looking at a single
> layer of interactions.

I'm primarially looking at author/developer interactions.  However, all
actors are considered.

Distributors are concerned with licensing -- this is generally the
exposure point for commercial liability, and high-profile distributors
will have an aversion to novel or obscure licenses.  To this extent,
licensing is somewhat like cryptography:  well established, well
understood licenses which have stood the test of time, are considered
lower risk.  Again, corporate licenses tend to speak to ghosts in the
corporate closet (IBM:  Patents, Sun:  compatibility and standards
control, Corel:  Canadian law).

Another advantage of selecting a widely use license is that it aquires a
strong institutional resistence to sudden change.  In the DJB instance
cited previously, and the IPFilters licensing "revision" which also
effected OpenBSD, licenses which were authored at the sole discretion of
a single user were unilateraly modified, or had their interpretation
unilaterally changed, to terms not acceptable for broader use.  This is
less likely where a broader constuency is represented.  The authorship /
revision issue is one I've put some thought to, there are a few possible
solutions.

> There is another aspect you're completely ignoring, unless one license
> prohibits(!) use with another license the interaction (outside of "Can
> I make money off it?") is nil - both for developers and users.

Free software largely precludes significant revenue streams from
software sales.  Not always -- Red Hat continues to generate significant
revenues from box and corporate sales, though it is moving to a
subscription (Red Carpet) and services model.  Still, in large part,
your benefit is going to come from indirect revenues:  services,
hardware, publications (e.g.: O'Reilly).   Eric Raymond's list from CatB
still largely stands.

In this case, appeal to developers is *quite* significant, as this
distributes your cost structure effectively to unaffiliated partners.
This particular lesson is one that a large number of free software
businesses (including the one I was affiliated with for 18 months) fail
to grasp.  There's little specific benefit in direct control of code.
IBM, incidentally, is a company that Seems To Get It(tm).

Users, similarly, should be concerned with long term viability of code.
A project with a single sponsor, and one with troubling financial
prospects to boot, doesn't gain much credibility despite their "free
software" status.  Licensing compatibility emphasizes the inherent "code
escrow" powers of free software licensing by providing the possibility
that the compelling features of the project might be continued, or at
least incorporated into another project, should the initial sponsor
fail.

> > > All license start out in the minority. It's a competition in a way.
> > 
> > What are you competing for? What characteristic of a license will "win"
> > the competition?
> 
> Utility, which license brings the maximum benefit to all three roles.

Which is served by a mix of factors, significant among them, license
compatibility.

> > This isn't software domination,
> 
> Yes, it is.

No.  Software itself competes on a different level.  It's influenced by
the licensing, but isn't fully dictated by this.  Poor license choice
can severly hamper adoption, development, use, and credibility.

> > it's more a protocol for collaborative development. Once you've got
> > that nailed down, stop dicking with the damned lawyers, and start
> > writing code.
> 
> One shoe doesn't fit all.

There are a good four or five well established "shoes" (GPL, LGPL,
BSD/MIT, Mozilla, IBM PSL) which serve a broad range of needs, with a
pretty good track record for interoperability.

But that's just one idiot to another.

Peace.

-- 
Karsten M. Self <kmself at ix.netcom.com>       http://kmself.home.netcom.com/
 What part of "Gestalt" don't you understand?             Home of the brave
  http://gestalt-system.sourceforge.net/                   Land of the free
   Free Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org
Geek for Hire                     http://kmself.home.netcom.com/resume.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks-legacy/attachments/20011023/410359a0/attachment.sig>