Subject: Re: Open-sourcing business operations code?
From: <>
Date: Tue, 31 Oct 2000 11:51:44 -0500 (EST)

On Mon, 30 Oct 2000, Chris Rasch wrote:
> "Stephen J. Turnbull" wrote:
> You may be right.  As I understand the issue, if someone contributes GPL'd
> code, you can incorporate it with GPL-compatible code without getting
> copyright ownership, but if you want to make it closed source, you have to
> get copyright ownership/permission from the contributor.  On the other hand,
> if someone contributes BSD licensed code, you can incorporate it into a
> proprietary product without getting copyright ownership.
> My suggestion to use the BSD license instead of the GPL, if you plan to also
> release a proprietary version, is based on the hassles I surmise in getting
> outside developer's to assign copyright to you, so that you can incorporate
> their changes into your proprietary product, and in keeping separate assigned
> and non-assigned contributions.  In practice, this may not be that big of an
> issue.
    If someone is inclined to release their developments under GPL, having
the original source under a BSD style license isn't going to stop them, or
even necessarily encourage them.  (When I say inclined, I mean inclined to
not allow these inclusions to proprietary products, regardless of whether
the official distribution will incorporate their modifications).
   The main reason for thinking a BSD style license will be better (in
this regard) is that maintaining a separate distribution is a major pain.
While that applies to both BSD and GPL licenses with assigned copyrights,
the scales would probably tilt to BSD as a preference (among potential
contributors) as then at least everyone has an equal shot of releasing
proprietary versions.  Which is presumably what the originating company
doesn't want.
    As for whether this company should go ahead and release their source,
or wait until they've cleaned it up, I'd say go ahead and release it.
From the sound of it, they're not putting as part of a business model with
support at the center (in which case, they might want to clean it up
first).   In other words, they don't have any particular incentive to be
seen as, or be, the primary developers of it.  Plus, others have a real,
utilitarian incentive to develop it for their own use.  The main thing
being that it works to solve a particular problem (i.e. ESR's "scratch an
itch" scenario).  I know if I need something for my job, and there's
something out there that works now, even if not perfectly, and my boss is
screaming for something yesterday, I'm pretty likely to take something
that works at least partially and adapt it as needed.  That applies even
if the source is ugly.  And that usage and adaptation has a snowball
effect in terms of intellectual investment - I become more and more
familiar with the source, and more and more willing to make major changes
and adaptations to it.  That's developer mindshare. 
    This is in considerable contrast to something like a web browser,
where the business interest in adopting and adapting it is at a much more
abstract reach, I think (unless your business is web browsers, of course).
There, I think your developer base will be much more skewed to individual
users, or other web browser firms, in which case clean code becomes much
more of a necessity.  I mean, very few individuals are going to learn
hundreds of thousands of lines of spaghetti logic to make their web
browser slightly better - it's just not as imperative, and there's
probably not much of a coolness factor to it.