Subject: Re: Open-sourcing business operations code?
From: kmself@ix.netcom.com
Date: Mon, 30 Oct 2000 13:09:22 -0800
Mon, 30 Oct 2000 13:09:22 -0800
on Mon, Oct 30, 2000 at 11:54:37AM -0700, Chris Rasch (crasch@openknowledge.org) wrote:
> Hi,
> 
> > WRT licensing, the issue hasn't been mentioned, but I'd suggest that a
> > staged approach might be a good one.  It's what a number of
> > commercial-to-free projects have more or less done de-facto -- starting
> > with a "source available", but not truly free, license, and moving to
> > more free as time goes on.  While this generates some rancor from the
> > free software community, I believe it actually is helpful in allowing a
> > company to start moving its software assets to open source in a
> > controlled manner.  Doing this deliberately, as opposed to the tracks
> > we've seen traced by Netscape and Sun, might help make clear that this
> > is a progression that is being tried tentatively.  No guarantees, but a
> > roadmap exists and can be pointed to.
> 
> I agree that companies should carefully plan the transition from closed
> source to open source.  I think the most important thing is to manage
> the expectations of your own company and the expectations of the
> community.  What advantages do you expect to gain by making your project
> open source?  How much of a commitment will you make to the community to
> support the software?  It's fine to simply release the software without
> support "Here's our code, enjoy, but we don't offer any support." but
> keep in mind that it will not likely take off.  Even open source
> projects need good project management, evangelism, and documentation
> before they reach a sufficiently large user base that they become
> self-sustaining.  Also be very careful about managing expectations about
> when project milestones will be reached.
> 
> Karsten, what do you think are the advantages of staged licenses?  What
> licenses would you recommend that a company use as an interim license?
> When should a company make the transition from one license to another?

Essentially, staging the transition allows a company to test the waters.
The evaluation should involve customer responsiveness, code viability,
community response, and internal issues (aka politics).  There's the
option to test interest and viability in the process without opening up
IP irrevocably off the bat.  Going whole-hog GPL is seen by many as an
all-or-nothing committment.  Gradualism is often easier to contemplate
and/or champion.

What sort of licenses?  Not being a lawyer, I'll stick to results rather
than mechanism.  Initially, disclosing source to existing customers
and/or academic programs would be useful.  You're getting user
perspective on the codebase, and extending mindshare, while still
protecting copyright, patent, and trademark IP.  It's a baby-step
action, but one which can go a ways in showing viability of opening up
further.  

Following, something modeled roughly on the Netscape (not Mozilla)
license, or SCSL, might be a way of working in a gated community, while
still retaining authorial integrity over product.  The key at this point
is to find compromise language which both opens up the product somewhat
further, but doesn't preclude further opening of the product by
introducing incompatible licensing under the control of third parties.

Finally, licensing, or multiple licensing, under a widely accepted OSI
license, and I'd typically point to BSD (new style), GPL, or MozPL as
preferred choices and/or models, could occur.


Timing is really dependent on conditions.  Probably stated in terms of
milestones to be met at various stages of the process, including
acceptence of code, third-party participation, community feedback, and
resolution of internal issues.

Note again that this really isn't very different from the tracks
actually followed by companies such as Netscape, Sun, IBM, HP, and
others.  The distinction is that there is a statement up front that
this is both an evaluation exercise, and that the final goal is some
specified final licensing term or set or terms.  A lesson hopefully
learned from the experience of these firms is that, when in the
testing-the-waters stage, the company be very clear about the fact that
it is indeed, testing the waters, and not swimming 200 yards offshore
already.  Misrepresentation (both intentional and accidental) has
probably done more to hurt credibility than any actual licensing terms.

> With respect to licenses, my readings of other closed source-->open
> source project histories suggest that licenses other than the BSD/GPL
> have a number of drawbacks:
> 
> a. inability to be integrated with pre-existing code;--you lose most of
> this advantage if you choose a license immiscible with the GPL

Very strong agreement.

> b. reduced developer and user base--a lot of open source programmers
> will only work on GPL compatible code because of (a) thereby reducing
> another advantage of going open source -- a broad developer base.   Why
> should anyone help with a project that might, maybe be released Open
> Source Real Soon Now?   For example, outside developer's were slow to
> help, in part, because Netscape chose a "roll your own" license, the
> NPL/MPL. You also reduce the likelihood that your software will be
> distributed with the popular Linux distibutions (Red Hat, Debian, Suse).

Strong agreement.

> c. cost of educating the community about your license--if your license
> is not GPL/BSD you may find that programmer's mistrust your intentions a
> la Sun Community Source License.  Instead of getting a lot of free
> positive publicity for your good deed, you get a lot of free negative
> publicity from those who perceive you trying to take advantage of open
> source software's cachet, without actually being open source.

Extremely strong agreement.  You also fail to mention cost of drafting
an alternative license.  I'd argue that only the very largest of firms
could even contemplate this expense. 

> d. code forking--had Trolltech licensed the Qt libraries GPL-compatible
> to begin with, the GNOME desktop probably would never have been written.
> Now, instead of a single really good desktop, we have two decent
> desktops that do primarily the same thing.

Unconvinced.  I'm not sure that forking or parallel project development
is a bad thing.  And personally, I don't care for either "decent
desktop" ;-)  I saw other problems with Qt, now largely resolved.

> My recommendation is to choose either the GPL or BSD-style license at
> the start.  Choose BSD if you want to also make a closed source version.
> If you use closed source code from third parties, get their permission
> to open source if you can.  If you can't, then release everything but
> the closed portions as open source with good documentation about why the
> particular functionality was been removed.

I'd argue this slightly differently.

  - GPL is an idiological license.  Its intent is to propogate the
    idiology of free software.  There are a number of (IMO) strongly
    positive benefits arising from this, several of which are
    demonstrated with considerable substantiality.  Similar arguments
    for LGPL.

  - BSD is a technological license.  It and similar licenses (MIT,
    etc.), are intended to make a technological standard widely
    available and used.  In the Karsten Self taxonomy of success factors
    for free software, widely used, established standards are one of
    several prerequisites.  While BSD licensing of Unix may have
    contributed to code forking, it also resulted in a widely used and
    accepted base of the Unix architecture and Posix standard, on which
    GNU/Linux is based.

  - MozPL is a mix of idiology and business model licensing.  While on a
    file-by-file basis, code is persistantly goverened by the terms of
    the MozPL, a business model is supported by allowing proprietary
    code to be added, again, on a file-by-file basis.  It's an
    interesting compromise, and not a bad one, IMO.

  - I classify most of the remaining corporate PLs as Anna Karenina
    licenses -- their positive-effects nature is grossly similar, in
    terms of promoting free software, open standards, or both.  It's the
    liability and damage limitiations which reveal particular ghosts in
    corporate attics.  "Corporate free software licenses all promote free in
    much the same way.  Liability factors are all different", to badly
    misquote Tolstoy.

I see dual licensing as a promising method of pursuing multiple goals,
while retaining licensing compatibility.  The specific combinations of
MozPL and GPL/LGPL [1], and BSD/GPL, in particular, may prove
interesting to contemplate.

-- 
Karsten M. Self <kmself@ix.netcom.com>     http://www.netcom.com/~kmself
 Evangelist, Opensales, Inc.                    http://www.opensales.org
  What part of "Gestalt" don't you understand?      There is no K5 cabal
   http://gestalt-system.sourceforge.net/        http://www.kuro5hin.org

[1]  Sun's SISSL is very similar to MozPL, and I'd consider StarOffice
licensing terms to be largely similar to this model.


["application/pgp-signature" not shown]