Re: [Fsfe-uk] Are GPL projects more likely to evolve faster ?

[Chris Croughton]

On Mon, Feb 02, 2004 at 10:00:45PM +0000, Roger Leigh wrote:

> James Heald <address@hidden> writes:
> 
> > Is there any research, or plausible advocacy, that GPL projects are
> > less likely to fragment, and are more likely to concentrate more
> > check-ins from more coders than BSD projects... and so, everything
> > else being equal, would it make more sense for a commissioning buyer
> > to go for a GPL licence, because the product would subsequently be
> > more likely to evolve more quickly in productive and useful ways?
> > (And would also be more likely to achieve 3rd party add-ons and
> > support?)
> 
> The two most popular examples for this question are
> * Linux kernel, GPL.  Not fragmented, though multiple [development]
>   trees exist.
> * NetBSD (386BSD) spawned FreeBSD and OpenBSD.  Berkely licensed,
>   allowed very high profile long-term forks that are likely not to be
>   resolved.

GCC -- GPL, but forked badly with EGCS taking the lead.  The original
project died and the ECGS team became the new GCC, but for a couple of
years there was a definite split with the 'official' GCC being stable
but limited and EGCS being innovative but not distributed as well.

> Both licenses allow forking, but I believe that the BSD licence makes
> it "less costly" to fork due to being a less restrictive licence.
> However, I believe that Linux has not fragmented due to its leader
> (Linus) whereas 386BSD didn't have a leader to form its developers
> into a cohesive group.

Exactly, I think it's more to do with the leaders and how tightly they
keep control of distribution.  Some of the non-GPL OS licences are very
restrictive against forking (and are often not compatible with the GPL
because of that), including things like patches only being releasable
through the author, forcing renaming of any changed modules etc.

> I'm currently working for a proprietary software company, developing
> under Linux (I know--it's not ideal, but I need the work).  I'm also
> allowed to work on Free software, where appropriate.  This is my take
> on the GPL from a proprietary software developer's point-of-view:

I'm in the same position.

> * BSD software is good, because I can use it with very few
>   restrictions, even so far as to incorporate it into my own code.

As a programmer, I can take BSD software (including stuff I have written
for myself) and use it at work without worrying that my employer will
get upset about their IP rights.  I've done this many times, and my
productivity goes way up because I don't have to "re-invent the wheel"
(and since I wrote the software originally, I can't do a "clean-room"
re-implementation).

> * However, if I was to release my own software under the BSD licence,

I take it that this is software which you have developed for your
employer, rather than that done in your free time for yourself?

>   any other proprietary software company could take my software and
>   basically pinch my hard work for no reward on my part.

I don't expect reward for my own software, except in the form of
remuneration from my employer.

> * If I license under the GPL, the other company would be forced to
>   release changes, which will be beneficial, and they won't be gaining
>   a competitive advantage at my expense, and we have more control over
>   development.

They will also be forced to make their own code public, if they
incorporate part of your code in theirs.  Of course, you'll have to do
the same...

> I'd look at this as though it were a "Prisoner's dilemma" type of
> problem.  Free copying (BSD) is beneficial when I copy, but has a high
> cost when others copy my work (3/1).  Copying with restrictions (GPL)
> is more costly, forcing cooperation, but overall has a lower cost to
> me since the playing field is level (2/2).
> 
>                             Them
>                   | Cooperate | Freeload
>         ----------+-----------+---------      where the number
>   Me    Cooperate |   (2/2)   |  (3/1)        is the cost to
>         Freeload  |   (1/3)   |  (3/3)        (me/them)

Maybe I don't understand your table, but why does it cost both of you 3
if you both freeload?

The problem with PD type analyses is always in assigning values to the
outcomes, and thus is it normally not as balanced in real life as the
table makes out.  This is particularly true when there is an "outside"
which has influence, as in the vast quantity of FLOSS already available.
Almost everyone "freeloads" on GCC, for example, very few are in a
position to make significant contributions back (I know I'm not: the one
time I found a bug -- in gdb -- by the time I had investigated it there
was a new version out which fixed the bug; I normally run several
versions behind the leading edge for stability as do most companies).
The same with Linux and most of the GNU utilities.

>         Please note this has no basis in reality--it's simply a
>         product of my fevered imagination!  The scale:
> 
>           1 - copying others' code has a small cost--you need to spend
>               time incorporating it, and you are then tied to the API.
>           2 - cooperating is more expensive than just copying, since
>               you are allowing others to use your work.
>           3 - others copying your code without any restriction is very
>               expensive (to you).

Why?  Surely the cost to you is the same, it's just that the cost to
them is zero (or minimal, there's usually some effort needed to work out
how to integrate 'foreign' software which may not conform to your own
interfaces).

>         The GPL prevents (1) and (3), allowing only (2).  The BSD
>         licence allows all three.  So, both may be used to achieve
>         cooperation (2), but the BSD licence may be misused or abused
>         in ways the authors of the code did not intend to allow (or
>         perhaps specifically intended--it all depends on the specific
>         case).

In my case, specifically intended.  My software (that I develop
privately) is open to anyone to use.  If they want to use it in a
closed-source product without my knowledge there's nothing I can do
about it whatever the license I put on it (how would I ever prove that
someone like MS was using my code, or even find out?).  SCO's suit can
only work (if it has any validity at all) because the destination is
open source, if the source were hidden they would have no way of knowing
or proving that their code had been used.

> I believe that the GPL will become more popular in companies as free
> software becomes established, since it prevents others from casually
> ripping off your hard work, while still giving others the freedom to
> use it as they like.  Overall, it is less costly.  [Stupid analogy:
> Microsoft are known to favour the BSD licence, but can anyone recall
> when they released any BSD licensed code themselves...?]

How much GPL code do they use, and is there any way of spotting it?  I
know at least one company which routinely stripped the copyright and
licences from any code they used, reformatted it and renamed variables
etc. according to their own coding conventions, and just incorporated it
in their own product.  Since the source stayed in-house, no one outside
even had a suspicion that this happened, and everyone in the company
accepted it as the done thing.

(Personally, I do prefer BSD type licences and my software is released
under a modified (more lenient) BSD style licence...)

> For some of the Free software I've done relating to work (mostly at
> home, but my employer signed the FSF employers' copyright disclaimer
> to allow me to do it at work too), I've released under a BSD-style
> licence.  This was because I used the same licence as the project it
> related to (libpqxx-object, based on PostgreSQL/libpqxx).

Using the same license as the existing projects makes sense.

> I think the best way to look at the question is to take a
> representative sample of free software projects, ranging in size from
> large to small, both popular and not so.  For each, examine the
> licensing and history of the project.  You won't be able to draw
> hugely general conclusions, but you will understand how licensing
> issues and history have affected the evolution of individual projects.

I agree.  My suspicion is that there is no inherent 'best' licence which
fits everyone or prevents (inhibits) forking, but I'd like to see such a
study from an independent reviewer.

> Many high-profile projects, such as Apache, PostgreSQL are not GPL,
> yet have not forked.  Others such as all the GNU stuff, Perl, GTK, are
> GPL, and have also not forked.

Not all of the GNU stuff, see GCC above.

> Personally, I think a better question
> would be to find a number of projects that have forked, and then ask
> "what were the causes of this project forking".  You may find
> licensing was a factor, but I suspect that clashing personalities,
> differing views, and other factors also had their part.  I'd look at
> the Emacs/XEmacs split for an example of this.

I suspect that personalities and differing goals are a major part, and
that licences (except where they are very restrictive) are relatively
minor.

> [My own personal opinion on licensing: if a project isn't using a GPL
> licence, I do tend to think twice or more before contributing any
> patches or doing any work.  If it's GPL, I feel much better about
> devoting my time to it.]

Hmm, I feel that about BSD <g>.  So, we differ, that's not a crime...

Actually, I'm more likely to submit patches etc. where I feel that the
maintainer (the one who runs the 'official' distribution site) is likely
to take notice and not just sit on them.  For instance, I have had good
feedback from Dimitri van Heesch of the Doxygen project, and so have
been more interested in submitting patches and bug reports to him than
to others who seem to be not interested (Doxygen is a GPL project).  To
me an active maintainer (or team) is the key.

Chris C