fsfe-uk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Roger Leigh
Subject: Re: [Fsfe-uk] Are GPL projects more likely to evolve faster ?
Date: Mon, 02 Feb 2004 22:00:45 +0000
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux)

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.

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.


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:

* BSD software is good, because I can use it with very few
  restrictions, even so far as to incorporate it into my own code.
* However, if I was to release my own software under the BSD licence,
  any other proprietary software company could take my software and
  basically pinch my hard work for no reward on my part.
* 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.

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)

        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).

        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).

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...?]


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).

For other work, I've used the GPL/LGPL as appropriate, e.g. libraries
based on Gtkmm are LGPL.  My "default" licence would be the GPL unless
there is a good reason not to do so, typically when working on an
existing or companion project.

> Are there other good texts to argue that choosing GPL actually is a good
> choice to help a project evolve better, or any academic research or
> modelling on this aspect ?

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.

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.  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.

[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.]


Regards,
Roger

-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]