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

[Simon Waters]

Chris Croughton wrote:
> On Mon, Feb 02, 2004 at 10:00:45PM +0000, Roger Leigh wrote:
> 
> 
>>James Heald <address@hidden> writes:
.........

> GCC -- GPL, but forked badly....

I was going to make a similar point - lots of GPLed products fork -
arguably all software development is forking, it is the folding back in
that makes the difference.

>>Both licenses allow forking, but I believe that the BSD licence makes
>>it "less costly" to fork due to being a less restrictive licence.

I'm not convinced, there is effectively no cost to forking, it is the
cost to maintain afterwards.

Since all distributed forks of a GPL project are available to all other
branches, any branch lacking a feature can merge it back in.

Where as there may be more benefit to turning proprietary from BSD
licences, you lose the benefits of any new code to the other branches.
So there is less opportunity for cohesive action.

So the GPL binds the branches of a fork together like a careful gardener
tending a damaged tree.

It isn't clear to me that the GPL would result in faster development,
indeed it might impede some dramatic developments in directions that
would make it less compatible with the orignal version.

In a very minor way I hit this with a code clean-up, which made parallel
develoments harder to merge, so eventually the code cleanup got dropped
in favour of the new functionality (doing it again we'd drop the
functionality and keep the cleaner code!).

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

Leadership helps, but the kernel is perpetually forking, with SuSE,
Redhat and Alan Cox variants. But these are public changes and there are
strong economic ties to staying close to the "true" kernel (or even just
close to versions other people contribute to), and none of the
proprietary attractions of "let's just add one secret value added
feature to make our product better". If SuSE add better virtual memory
management, be sure Linus will adopt it if the code is up to scratch, or
can be fixed.

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

I'm not a full time coder... although looks like I will be doing some
customisations to proprietary code (although the licence is disputed,
I'm sure you can't have just one GPL function in the middle of a Perl
script?). It's all niche bespoke stuff, I don't think anyone else will
want it.

Most of the stuff I work is free software, but I think the nearer the
end user you push the less free the licences become, this reflects the
"free software" as mature product argument, but it isn't even.

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

I better go do some stuff then.....

pgpZDrgVawoWP.pgp
Description: PGP signature