Subject: Re: Open-sourcing business operations code?
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
Date: Tue, 31 Oct 2000 11:01:40 +0900 (JST)

>>>>> "Chris" == Chris Rasch <crasch@openknowledge.org> writes:

    Chris> My recommendation is to choose either the GPL or BSD-style
    Chris> license at the start.  Choose BSD if you want to also make
    Chris> a closed source version.

I don't understand this recommendation (even after following further
discussion in the thread).

GPL (LGPL) does not preclude doing a closed source version unless you
also assign the copyright to the FSF (or equivalent), when it very
possibly does.[1]

Of course using GPL and also releasing a closed source version opens
you up to Sun Community/NPL-style revulsion in the community, since
the GPL does attract the most ideologically motivated developers.
This may be outweighed by the purely business-strategic advantages of
providing strong incentives for competitors to be "core-compatible"
(with a core you presumably know better than anyone else) in the
proprietary market.  A BSD license, by contrast, would allow them to
embrace and extend your core in closed source, denying you access to
their improvements.

For example, I could see a pretty good business argument for a GPL
core with real and solid (but relatively easily duplicable)
functionality with a proprietary source-provided-under-NDA set of
frills, especially in the ASP market.  This would especially be
attractive to customers who see the frills as a course of competitive
advantage to themselves, but would welcome the open core and
source-provided value-added components as antidotes to lock-in.

This also might make sense in a consumer product with a large
database.  I could see releasing in open source a basic OCR product
with "inverse fonts" for the Basic Latin and Extended Latin
characters, and charging for the Japanese "inverse font" module (and
even more for Arabic!)

Or the Ghostscript model, with a more or less approximately open
source license for the current version and a real open source license
with a lag.

Of course, these only make sense if you project that you will end up
doing most of the development yourself, anyway.  The argument that
this is a self-fulfilling prophecy is pretty strong.  But if you don't
accept that argument, then GPL is as strong a candidate as BSD for the
open branch of a dual-license strategy.  BSD only makes sense to me if
you need to level the playing field to attract developers with the
same (or higher) level of commitment as yourself _and_ you also want
to release a proprietary version.  Releasing a proprietary version at
all will presumably chase away the ideologically motived crowd; BSD
certainly won't help bring them on board AFAICS.


Footnotes: 
[1]  It is not clear to me, nor to the Real Lawyer I consulted, that
the "you may use your code any way you like" clause in the standard
FSF assignment legally covers distributing products based on it,
almost surely not if that includes licensing the code to third party
developers.  Licensing is clearly reserved to the FSF as the copyright
holder.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."