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

[Chris Croughton]

On Tue, Feb 03, 2004 at 09:31:48PM +0000, Simon Waters wrote:

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

There's a lot of forking software around, certainly.

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

Yes, maintenance is the problem, but I think that was included in the
"cost of forking".  That certainly seemed to be the case with GCC/EGCS,
the effort to try to hold them together seemed to overload the
'official' team.

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

And the branches which are still free will tend to deviate from the
proprietary ones, making it harder (and more costly) for the proprietary
maintainers to merge them back.  For instance a free branch may
implement something the proprietary branch has (but didn't release), but
in a different and incompatible way.  This, I suspect, will limit the
attractiveness of the BSD software to proprietary vendors and so be
self-limiting.

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

It can do, I think that it needn't.  It's back to the leadership issue
and having some single point of 'official' contact.  That is something
which Linus has done, for instance, there is one 'official' tree (OK,
two, development and stable!) and the forked variants are known to be
that, and you take your chance wit hthem.

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

Which is sort of what happened with GCC and spawned the EGCS project.

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

And then add the functionality to the cleaner code.  That's what most of
us would like to do, but management constraints don't always allow it.
(But management is a different rant <g>...)

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

They are also temporary forks to try things out, or in the case of RH
and SuSE they are changes which are re-applied to each new kernel
version (RH publish patches to the kernel, I don't know about SuSE).
Like the patch to include ACPI which I need to apply...

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

IIRC the Perl license is compatible with the GPL, if they're using that.
Or if the GPL function is released as an LGPL standalone function (as
opposed to something released as part of a library), or it is a
self-contained module which is 'bundled' with the Perl script, I think
there is no problem.

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

I think that where you have "end users" who only want to use the product
"as is" (i.e. the vast majority of computer users) it is difficult for
them to see any benefit to FLOSS.  The only freedom they care about is
that to copy and share binaries, and most of them do that whether they
are allowed to by the licence or not (and according to a recent survey
IT companies are among the worst 'offenders' at that).  They don't want
the source code, they'll pay someone else to do upgrades anyway, all
they want is "free as in beer" (or just "cheap as in beer in civilised
countries").

The closer you get to the code producers the more FLOSS is attractive,
because they (we) are the ones who actually benefit from the freedoms.

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

Me too <g>...

Chris C