[svlug] a course on managing open source...

Karsten M. Self kmself at ix.netcom.com
Thu Jul 14 22:13:47 PDT 2005

on Thu, Jul 14, 2005 at 08:55:17PM -0700, Jan Van Bruaene (jan.vanbruaene at gmail.com) wrote:
> On Jul 13, 2005, at 11:38 PM, Richard Sharpe wrote:
> > On Wed, 13 Jul 2005, Sameer Verma wrote:
> > 
> > > Dear SVLUG members, I will be teaching a course titled "Managing
> > > Open Source" at San Francisco State University. This course is
> > > being offered as a graduate/undergraduate cross-listed course by
> > > the Information Systems department in the College of Business. As
> > > the title suggests, the focus of the course will be
> > > business-oriented for most part. A proposed course outline is
> > > listed at the end of this e-mail.

> Sameer -
> Your outline, and others on the alias, already discus licenses.
> La-li-la - the license is often the headline grabbing piece, and
> highly politically charged. But what next?  

Licenses are important considerations for a number of reasons.  More
clearly understood if one thinks "free software" rather than "open

From the "we're starting a new project" perspective:

  - Without licensing, there is no "free" in free software.  Regardless
    of your license, under current copyright laws, there are no default
    rights to copy, distribute, and use software.

  - Licenses address specific goals, and those goals _are_ often
    technical in significant nature.  
    - If you're trying to promote a specific new techology, the BSD/MIT
      model works very well.  
    - If you are addressing a relatively established standard (e.g.:
      POSIX OS, graphics software, office suite), you want to ensure a
      codebase remains available as free software, and/or are addressing
      a market in which proprietary vendor lock-in has become prevalent
      (and see a business opportunity not reliant on software licensing
      revenues), and/or are attempting to undercut an existing,
      software-based dominant market player, the GNU GPL is
      exceptionally powerful (why do you think Microsoft fears it so

    - If you want to preserve the ability to market propprietary-in-part
      products based on a free software base, and still want some of the
      protections / benefits of a copyleft / GPL license, then a
      Mozilla-style license is where you likely want to go.

There are a few other twists.  Dual licensing allows some compromising
of benefits.  Larry Rosen will tell you that his Jabber Free, Academic
Free, and Open Software licenses address some issues of contract
consideration, though this is pretty strongly disputed.

Pretty much to a one, corporation-specific licenses are boring, not
widely applicable, and reveal far more about what a company fears than
anything particularly insightful about licensing.  There's been
considerable progress toward discarding such licenses.  Even (I'm just
learning this writing this) Mozilla is shedding its own MozPL (one of
the *very* few IMO well-written, organization-based licenses) in favor
of the GPL.

This largely boils down to the point that there are about five licenses
which should receive _any_ consideration from you, as a developer, in a
project, four of these being relatively similar:

  - The GNU GPL, or its cousin, the GNU LGPL.  These two compatible
    licenses cover ~85% of all Free Software projects.

  - The MIT or BSD licenses, or one differentiated from either only by
    the named affiliated organization.

  - The Mozilla Public License, and very probably dual-licensed with the

A possible sixth alternative is releasing to public domain, though this
may expose the developer to liability risks due to the lack of a
warranty / liability disclaimer in a non-license.

From an adopter of Free Software, there are a few additional
considerations, largely dependent on whether or not you plan to do any
development yourself:

  - Simple usage of a license doesn't open you up to obligations based
    on your own code.

  - Distribution of products based on, or containing, Free Software may
    obligate you to making sources available.  Failure to take this step
    is the most frequent issue of "GPL violation", and is very nearly
    always addressed readily and speedily.  I've actually helped
    Microsoft get squared in once case involving its Unix Services for
    NT product.  Hardware products based on GNU/Linux or other Free
    Software tools (e.g.:  Samba, nmap, nessus) are other common cases.

  - Incorporation of Free Software code into your own software requires
    establishing licensing obligation compliance.  This is no different
    from incorporating code from any other third party, except that Free
    Software licenses tend to be markedly more standardized, well
    understood, and less tangled in independently licensed
    multi-organizational interests than proprietary software.  "GPL" (or
    other) license violation cannot compell you to license your own work
    under the GPL (though this may be one compliance option).
    Enforcement actions are largely those spelled out in copyright law,
    and comprise civil and criminal penalties.  Some licenses may spell
    out additional conditions. 

    Generally, compliance options include:

      - Making a restitution payment to the original author(s).

      - Redacting the included work from the product.

      - Releasing the combined work under the, or a, compatible Free
        Software license.

      - Negotiating mutually agreable alternative licensing terms with
        the original author(s) and/or copyright holder(s).

> One still has to create a development community, commit hierarchy, a
> test and release group, etc. Just pushing source with a GPL heading
> won't cut it. 

I don't believe anyone's suggesting it does.  However this doesn't imply
licensing is meaningless, that studying it is pointless, or that it
can't significantly impact product success.

> So, take both a successful open source community (my favorite
> methodology: Apache) and a non-successful project.
There are very highly successful projects under most of the major Free
Software licenses.  Arguably, licensing may have played a role in the
initial success of a project (or not).  Apache (which did much to
establish the standard of HTTP and the Web as an information and
applications platform) has been very well served by the use of an
MIT/BSD style license.

There are very *few* successful Free Software projects under minor or
one-off licenses (other than very minor tweaks of BSD/MIT as regards
organizational identity).  In particular, several existing successful
projects have effectively been killed by gratuitous or spiteful
licensing changes, most notably OpenBSD's transition from ipfilter to
'pf' following modifycation of the latter's license to specifically
exclude GPL linking, and the OpenSSH project's emergence after Ylonen's
SSH was taken proprietary.  OpenSSH now has over 88% marketshare. 


There is the odd well-used project with an odd (but liberal) license, of
which vim is the most prominant example I can think of (quick:  what
*is* vim's license?).  But complex, organization-specific licenses tend
not to result in popular projects.

Sun's Java is an interesting case, in that it is under a highly
idiosyncratic, organization-specific license.  The technology itself is
useful enough that it's been widely adapted....but not without
considerable grumbling.  The licensing does mean, however, that getting
a functional Java runtime on many GNU/Linux distros is a considerable
exercise in frustration, to thet point that my browsers don't presently
have Java support, nor are likely to in the forseable future.


Karsten M. Self <kmself at ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    "Miss West, are you trying to show contempt for this court?"
    "On the contrary, your Honor, I was doin' my best to conceal it."
    - Mae West, and a contemptible judge.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.svlug.org/archives/svlug/attachments/20050714/a60322c6/attachment.bin

More information about the svlug mailing list