Re: Thoughts about gnuplot license and copyrights

[Ethan M. <merritt@u.washington.edu>]

On Thursday 19 January 2006 09:43 am, Dave Denholm wrote:
>
> Suppose I set up a rival cvs, drop in a source release as
> version 1, and then just start hacking.
>
> a) can I put the cvs onto the internet, and allow anyone to connect
> to download any version (including the latest) of my forked gnuplot ?
>
> b) suppose I instead set up a cron job to, every night, upload to a
> file server a cut of the head revision and a set of diffs from #1 to
> the head revision.
>
> (b) definitely seems to violate the spirit of the license at
> least. Yet I can't really see much difference between (a) and (b).

It's probably pointless trying to guess what the legal system
would decide in a hypothetical case that revolved around this point.

However, let me add my thoughts on the spirit of the license.
I am not a tremendous fan of using the GPL for scientific software,
and in general I prefer a license like the older Perl "Artistic" license
or something similar to the  UW "pine" license.  These are at the
same time less restrictive that the GPL in terms of what the code
can be used for, but more restrictive in terms of forks and
redistribution of modified code.

For my own code (I'm not referring to gnuplot here, but to other
code packages I distribute) the motivation is as follows:
I wrote this code, and to some extent my professional reputation
is tied to its validity and usefulness.  In order for it to be of 
maximal use to others, I want to impose as few restrictions as
possible on use or local modifications.  On the other hand, suppose
someone modifies it for local use and in the process unwittingly
breaks something else.  If it works for them, fine.  But if the broken
version is redistributed, that's bad.  I don't want such externally
modified versions being distributed in such a way that the program's
failure is mis-attributed to the original design or implementation.
Therefore I ask that any modifications be contributed back to the
primary source tree, and/or be distributed as patches to it.  That
way everyone gets the benefit of external additions or development,
but they are also guaranteed to receive the original source and
modifications to it; this is also one of the chief goals of the GPL.

But yes, it is a real problem if the original rights holder[s] to such
a work go missing or inactive.  My only answer to that is a hope
that, at least in the case of scientific software, any person who
cared enough about the code to set those terms in the first place
also cares enough to eventually hand on the torch to someone
else so that both the project itself and the quality-control mechanism
continues on into the future.

As I understand it, the UW pine license takes a slightly different
approach to the same issue.  It allows you to use and redistribute the
official pine release unmodified.  You can also modify and 
redistribute the modified version, but if you do so you can no
longer call it "pine".  That way if a 3rd party is unhappy with the
modified version, it does not reflect badly on the pine development
team.
   http://www.washington.edu/pine/overview/legal.html
They stop short of authorizing forks, although the distinction between
a modification and a fork is rather vague.
[ They also contaminated it with a clause about US-sanctioned
  export restrictions, but that is a whole separate issue ]. 

I cannot say whether these same motivations or views are
held by the original gnuplot authors.

Perhaps Thomas Williams would be willing to authorize periodic
releases by the cvs development team, while retaining veto power?
I.e. [thinking out loud here], we'd prepare a release candidate and
a bugfix and comment period to last a minimun of XX months
before it could become an official release. Thomas Williams and
Colin Kelley would have the power to intervene and cancel the
planned release if for some reason it seemed to be taking gnuplot
in a direction they did not approve of.

In summary -
    I have great sympathy for the current gnuplot license, but
I agree that somehow we need to negotiate a guarantee that
the code can continue to be developed, and that there is some
mechanism in the future for anointing "official" release versions
on which subsequent patches are based.  

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA