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

[Roger Leigh]

Chris Croughton <address@hidden> writes:

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

That's a good example.  However, it's notable because most of the
active GCC contributors switched to working on EGCS, and subsequently
the fork was mended when EGCS became GCC.  I can't see the BSD or
Emacs forks mending in the same manner, but I don't think the licence
is the major factor in either case.

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

This reminded me of a stupid case of re-engineering I'm currently
undertaking.  In 1996, an Epson driver was written for GNU groff, but
the author refused to assign copyright to the FSF, so it couldn't be
included in the official groff distribution.  In 2003, I realised I
needed a groff Epson driver, and started to write my own.  I'm
currently doing a complete reimplementation of his (GPL) driver to
create a new (GPL) driver.  The only difference being I will be the
sole copyright owner so I can legally assign copyright to the FSF!

>> * 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?

Yes.  I was unclear here.

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

We may differ here then ;-)  I'd happily work for a pittance provided I
could write free software only, preferably retaining copyright.  I
have no real desire to write proprietary code--just getting money by
way of recompense is not what I desire.

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

I thought this was odd when I thought it up!  It's also a logical
impossibility for you both to freeload, since neither are releasing
code publicly.  In general though, I don't approve of freeloading,
which is why I favour the GPL.

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

By freeloading, I don't mean using code without giving back.  This is
very common, and we are all guilty of it.  I've never had any desire
to hack on Emacs, for example, despite using it every day, and to
reply to your mail.  What I mean is taking code and incorporating it
into another project/product, basically pinching others' work and
passing it off as your own--I would object to having my code used in
this way, since I gain nothing from its use.  If a competitor were to
be doing the copying, this would be rather suicidal!

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

I guess it all depends on what is a "cost" to you.  I'd count use of
my code by competitors as a big cost, since I've paid the cost for
development, and they are profiting from it at my expense (lost
sales).  But the scale is fairly arbitrary.

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

Although one can't prevent others breaking the licence, the difference
is that if I GPL license my code, and someone incorporates the code
into their proprietary product, they *broke the law*.  They are in the
wrong, and I have a legal case against their unauthorised use.  Most
people are honest and will make every reasonable effort to comply with
a licence.

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

Try running strings and grep on a few common Windows binaries.  You
might be surprised!  You see UCB copyrights in quite a few (Win98).

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

That's dishonest and illegal.  I couldn't in good concience work for a
company like that.

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

That's perfectly fine--providing you accept that your code may be
reused in this way.  I don't personally, which is why I favour the
GPL, but I see we are of differing opinions in this respect ;-).

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

Nope, and both positions are entirely valid.  It depends entirely what
you want out of the licence, which is I guess where our difference
lies.

As an example of why I have my preference: last year, the Gimp-Print
project was approached by a major high-end preprocess printing
software company, who wanted to use Gimp-Print directly in their
software for generating print output.  Because the project is GPL this
was not a possibility (either practically or ethically), so the
outcome was that they released a GPL program to interface their
program with Gimp-Print.  That is, it encouraged the release of more
free software.  Both parties have benefited from this.

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

Very true.


Regards,
Roger

-- 
Roger Leigh

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