gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Thoughts about gnuplot license and copyrights

[<tim...@en...>]

Daniel J Sebald wrote:

> Timoth=E9e Lecomte wrote:
>
>> Well defined ? This is where maintainers arrive. "Maintainers" are the
>> people who actually take care of the code, and distribute the program.
>> To my mind, it's more a practical definition than a legal one. Usually
>> it is the person or the group of people who decide when to release a n=
ew
>> version. Currently, as the license does ask for too much restriction o=
n
>> released modified code (the patched way), the 'absolute' maintainer is
>> Thomas by default, as nobody is allowed to release a new version witho=
ut
>> his agreement. This is the problem.
>
>
> I think we're on the same page, Timoth=E9e, i.e., envisioning some
> loose-knit group of individuals with some authority (for what it's
> worth) to maintain the code and a convenient way to keep that going.=20
> I like the way you've described it.  But it is always good, I think,
> to be a bit more legally conscientious (especially if the license
> deviates slightly from an accepted and understood license), just so
> the intentions are understood down the road--sort of an impartial
> check.  There's been some good discussion here, but come five years
> from now it's part of the digital ether.
>
> Dan

I understand your point about defining legally this group. As Ethan
explained, it's what the pine license does, and in this case the group
which authorizes releases is the University of Washington. You can note
that there are major differences between pine and gnuplot : 'pine' is a
trademark (as 'firefox' is for an other example), and there is a
powerful and long-standing legal entity behind pine, the university.

To remain pragmatic, I think that we can't reach the same conditions for
gnuplot.
As Hans-Bernhard Broeker also explained, a trademark would be needed to
protect the name 'gnuplot'. To remain pragmatic, nobody will provide the
money to have a 'gnuplot' trademark.
And if we define a "maintainers group", it would still be a list of
named individuals who can disappear one day. The solution would be a
sort of foundation, but I can't imagine such a complex legal entity for
just gnuplot.

That's why I just propose to use a slightly more permissive license
about release conditions. Thus we preserve simplicity : no need to
legally define a maintainer group if the license does not mention it.

Timoth=E9e

Re: Thoughts about gnuplot license and copyrights

[Daniel J S. <dan...@ie...>]

Timothée Lecomte wrote:

> Well defined ? This is where maintainers arrive. "Maintainers" are the
> people who actually take care of the code, and distribute the program.
> To my mind, it's more a practical definition than a legal one. Usually
> it is the person or the group of people who decide when to release a new
> version. Currently, as the license does ask for too much restriction on
> released modified code (the patched way), the 'absolute' maintainer is
> Thomas by default, as nobody is allowed to release a new version without
> his agreement. This is the problem.

I think we're on the same page, Timothée, i.e., envisioning some loose-knit group of individuals with some authority (for what it's worth) to maintain the code and a convenient way to keep that going.  I like the way you've described it.  But it is always good, I think, to be a bit more legally conscientious (especially if the license deviates slightly from an accepted and understood license), just so the intentions are understood down the road--sort of an impartial check.  There's been some good discussion here, but come five years from now it's part of the digital ether.

Dan

Re: Thoughts about gnuplot license and copyrights

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

> If protection of their and their's works reputation is what they want, 
> people are supposed register a brand name for the product and sue for 
> infringing on that.  As for the rest, the relevant question is: what's 
> in a name?

Allow me... gnuplot by any other name would still plot as sweet.

(c) Some 17th century dude

Re: Thoughts about gnuplot license and copyrights

[Hans-Bernhard B. <br...@ph...>]

Dave Denholm wrote:
> Hans-Bernhard Broeker <br...@ph...> writes:
> (you didn't cc the list - was that intentional ?)

Ermm. no.  Shift key must be blocked or sumpin' ;-[

I'm putting them back on now.

> It's not clear that GPL does prevent usurpation... 

It only prevents silent usurpation, because you can't legally remove all 
traces of previous work from a GPL'ed program.  An usurpator can't, in 
particular, remove other people's copyright notices without breaking the 
law.  Nor can he change the licence.  Nor can he legally hide the 
modified source files containing his changes to avoid revealing his evil 
self.

> it encourages forks, and and it doesn't seem able to prevent a forked
> version of the sources from keeping the same calling itself "gnugo
> 3.8" or whatever.

It doesn't.  Copyright (and thus the GPL) is not about protecting 
anybody's (or their product's) good name, it's about protecting their work.

As OSS authors, we consciously already decided to give up a large part 
of the work's protection.

If protection of their and their's works reputation is what they want, 
people are supposed register a brand name for the product and sue for 
infringing on that.  As for the rest, the relevant question is: what's 
in a name?

Re: Thoughts about gnuplot license and copyrights

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

> The problem gnuplot would have with that approach is that there is no 
> such legal body in sight.  We'ld have to go ahead and found one, or 
> convince all the relevant persons to agree on an existing one to carry 
> the flag.

An alternative to discuss with T.W.

Dan

Re: Thoughts about gnuplot license and copyrights

[Dave D. <dde...@es...>]

Timoth=E9e Lecomte <tim...@en...> writes:

> I'm not a desperate fan of the gpl, but I think that this license
> handles these problems (maintainship by a self-defined community) in a
> good way, by preserving to a good extent the spirit of the original
> gnuplot license (preserving from usurpation, keeping the modified and
> published code as open as the original).

Actually, I'm not sure it does.... it almost defines that the
software has *no* owner, and therefore it is impossible to distinguish
the "real" version of the software from a forked version.

> Release of modified code is allowed, is easy. Fortunately it is not
> allowed without any restriction. Here are those restrictions (quote from
> the gpl) :

Is there anything in the GPL that allows "the maintainers" to release
a new version of "their own" software without exactly the same
restrictions applying to them ?

eg picking gnugo completely at random. (Not because I think it has
anything dodgy in its history. Merely because it's one GPL product I
have contributed code to in the not-too-distant past.)

On some day in the past, there was a software product called
"gnugo 3.4" released. There is a group of people around who consider
themselves to be "the maintainers of gnugo". They added some code to
gnugo 3.4, producing a derived work. They released this and called it
"gnugo 3.6".

I'm not sure that the GPL gives this people the right to reuse the
name "gnugo" for their version, as opposed to anyone else.

Changing only the version number must be sufficient notice that
changes have been made, since that's usually all a maintainer will do
when they release new versions.

A colleague here (not a lawyer...) reports that this does come up from
time to time and that, sometimes, people do indeed release
unauthorized forks of gpl code, changing only the version number, and
passing their version off as a new release.



dd
--=20
Dave Denholm              <dde...@es...>       http://www.esmertec=
.com

Re: Thoughts about gnuplot license and copyrights

[<tim...@en...>]

Daniel J Sebald wrote:

> Timoth=E9e Lecomte wrote:
>
>> I would really prefer to solve the whole licensing issue (easy release=
 +
>> code reusability), either by choosing a well-known license (gpl or
>> compatible), or by allowing redistribution of modified source code and
>> binaries without restriction.
>
>
> Don't know if I agree with the extent of that.  That basically means
> no copyright whatsoever.  I'm not really against using open software
> in a patched way.  But there has to be some indication by the person
> doing the distribution that said project was mainly developed by
> others and made available freely and there is no warranty attributed
> to the original source.
>
> It's a fair use issue as I see it.  If someone sells a software
> product that utilizes gnuplot, would that be breaking the copyright?=20
> Maybe, maybe not, but I'll hazard a guess no because RedHat, et al.
> would be in violation.  But to do so and not make it readily known
> that gnuplot is in fact available elsewhere and not part of said
> product is misleading and unfair.
>
> Dan=20

I did not want to mean 'without any restriction', but actually with
fewer restrictions than today.


Daniel J Sebald wrote:

> Petr Mikulik wrote:
>
>>> Perhaps Thomas Williams would be willing to authorize periodic
>>> releases by the cvs development team, while retaining veto power?
>>
>>> 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.
>>
>> That would be fine. Gnuplot developers (defined to be those having
>> right to contribute to cvs) would be approved to continue gnuplot
>> development, support and releases.
>
> Wouldn't you think it should be copyright holders who have that
> authority?  Having access to CVS doesn't seem to me to have a legal
> basis.  Someone's signature on a piece of paper at a lawyer's office
> in Belgium might... or make that Paris (rather than have the document
> sent to them for notarizing, developers could travel there).

We have to make a difference between "copyright holders" and
"maintainers" of the program :

"Copyright holders" are those who define how their code is allowed to be
used, modified, distributed. This is a legal definition, and the we can
pursue somebody who doesn't respect the license, thanks to this
copyright. Currently, Thomas is the copyright holder of most code in
gnuplot (along with other people, listed in the first mail of this
discussion). It won't change, unless he gives his copyright to another
person, but that's not a usual practise, and moreover that's not needed
provided the license he chooses is well defined.

Well defined ? This is where maintainers arrive. "Maintainers" are the
people who actually take care of the code, and distribute the program.
To my mind, it's more a practical definition than a legal one. Usually
it is the person or the group of people who decide when to release a new
version. Currently, as the license does ask for too much restriction on
released modified code (the patched way), the 'absolute' maintainer is
Thomas by default, as nobody is allowed to release a new version without
his agreement. This is the problem.

To solve this on the long-run, it's the license that has to be changed,
not the copyright holders. So if we want to do something, it is to
persuade Thomas to modify the license. It should allow somebody else to
release. Who ? Restricting this right to some named people is not a
long-standing solution, as these people could disappear. According to
what happens to almost every open source projects, the maintainers are
usually chosen by their activity on the project, and named from one to
another, but without really legal definition somewhere in the files.

I think we can all agree with the following : gnuplot development is
assured by a community, and this community is opened to everyone who
wants to contribute for different motivations. Currently, it doesn't
represent the reputation of some individuals, even if the initial work
was done by Thomas and Colin only. Gnuplot contributors are known as
"gnuplot contributors", not really as individuals. There's no need to
write somewhere explicitely who are the developpers. They are
self-defined. That's why I would like to see gnuplot under a license
that doesn't name explicitely who is authorized to release.

I'm not a desperate fan of the gpl, but I think that this license
handles these problems (maintainship by a self-defined community) in a
good way, by preserving to a good extent the spirit of the original
gnuplot license (preserving from usurpation, keeping the modified and
published code as open as the original).
Release of modified code is allowed, is easy. Fortunately it is not
allowed without any restriction. Here are those restrictions (quote from
the gpl) :
        "a)  You must cause the modified files to carry prominent
notices stating that you changed the files and the date of any change.

        b) You must cause any work that you distribute or publish, that
in whole or in part contains or is derived from the Program or any part
thereof, to be licensed as a whole at no charge to all third parties
under the terms of this License.

        c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such interactive
use in the most ordinary way, to print or display an announcement
including an appropriate copyright notice and a notice [about no
warranty (as it is free software which can be modified), etc.... cut
here ... ]"

It assures that the modification remain under the same license, so that
the "copyright holder" has not made of choice for nothing. The modified
code has to be clearly identified ("prominent notices") : that should
prevent anybody for corrupting gnuplot, so that consciencious
contributors' reputation is safe.



Do you think these arguments can persuade Thomas and other copyright
holders ?


Timoth=E9e

gnuplot 4.1 source

[Winnie <wi...@cb...>]

hi,
I'd love to use gnuplot 4.1 but I can't download the source code via 
cvs, and my university computer help disk cannot resolve the problem. I 
wonder is there any way I can obtain a copy of the version 4.1 source code?
Thanks
Winnie

Re: Thoughts about gnuplot license and copyrights

[Hans-Bernhard B. <br...@ph...>]

Petr Mikulik wrote:
> Sourceforge is full of dead projects -- once the main author disappears, 
> others have not enough rights to continue.

If so, that's not exactly SourceForge's fault.  They do all they can to 
avoid that problem.  They have an established 'take over orphaned 
project' plan for such cases, and they're trying to bury the actual dead 
ones.

Re: Thoughts about gnuplot license and copyrights

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:
> Don't know if I agree with the extent of that.  That basically means no 
> copyright whatsoever.  I'm not really against using open software in a 
> patched way.  But there has to be some indication by the person doing 
> the distribution that said project was mainly developed by others and 
> made available freely and there is no warranty attributed to the 
> original source.
> 
> It's a fair use issue as I see it.  If someone sells a software product 
> that utilizes gnuplot, would that be breaking the copyright?

I stand corrected, breaking the "license", not copyright.

Dan

Re: Thoughts about gnuplot license and copyrights

[Daniel J S. <dan...@ie...>]

Timoth=E9e Lecomte wrote:
> Dave Denholm wrote:
>=20
>=20
>>Timoth=E9e Lecomte <tim...@en...> writes:
>>=20
>>
>>
>>>Robert Hart wrote:
>>>  =20
>>>
>>>
>>>>>IMHO the gnuplot license is very close to the standard BSD license, =
which
>>>>>imposes fewer restrictions than the GPL.
>>>>>      =20
>>>>>
>>
>>My understanding is that GPL comes with lots of words of legalese,
>>but most of the restrictions are designed to prevent any one person
>=20
>>from restricting anyone else from doing what they want with the code.
>=20
>>BSD has few legal restrictions, but means that someone can modify the
>>source and then distribute with more restrictions (including binary onl=
y).
>>
>>The one thing I do tend to feel strongly about is that if I put in
>>time developing open-source software, I don't want someone else
>>exploiting it for profit. BSD license doesn't prevent that, though GPL
>>probably does.
>>=20
>>
>=20
> Yes, I agree with this. My feeling is that the gpl is really the result
> of a deep thinking to preserve copyleft, not only a long-and-unreadable
> text.
>=20
>=20
>>>>The purpose of the GPL, is not (just) to allow forks, or other indepe=
ndent
>>>>developments and patches, but also to allow code to be reused in enti=
rely
>>>>separate projects. AFAICT, there is nothing in the gnuplot license th=
at
>>>>would let me (say) use the gnuplot terminal drivers as the start poin=
t for
>>>>some other graphical program.=20
>>>>
>>
>>It may prevent the gnuplot terminal drivers from being
>>distributed with another program. (Maybe not : it says you cannot
>>distribute complete modified source tree, but doesn't see you cannot
>>distribute a partial set of unmodified sources..?)
>>=20
>>
>=20
> To my mind, a 'partial set of unmodified sources' is to understand as a
> 'complete modified source tree' according to the current copyright.
>=20
>=20
>>However, it doesn't prevent you from designing and distributing a
>>program which uses the same interface, allowing people who download it
>>to link it locally with gnuplot terminal drivers. Well, that was one
>>of the notions behind the terminal driver changes described in
>>term/README
>>
>>I guess an analogy would be with gnu readline : the GPL
>>prevents us from distributing a gnuplot binary that links with it, but
>>someone building from source can link *their* copy with gnu readline.
>>
>>For a while, we (well, I) was considering breaking gnuplot into layers
>>of libraries, with the lowest layer offering access to the graphics
>>drivers, and the highest layer offering most of the gnuplot
>>functionality. The gnuplot program would then just be a thin client of
>>the library. But that never happened.
>>=20
>>
>=20
> Well, that may happen one day ;-)
> I agree that linking is possible provided some conditions (mostly a
> 'local linking') but it's definetely complicated !
>=20
>=20
>>>>whilst happy to use gnuplot, are reluctant to get too involved in
>>>>developing it because of that.
>>>>
>>
>>[ reordering slightly]
>>
>>
>>>am exactly asking myself the same thing : is it worth getting
>>>seriously involved in gnuplot, if it someday vanishes just because
>>>Thomas won't be joinable to give his agreement ?
>>>  =20
>>>
>>
>>Depends on your motives : when I got involved with gnuplot, it was
>>because *I* was using it a lot, and I wanted to improve it for my own
>>use. Contributing the changes let others benefit from them, but more
>>importantly, meant I didn't have to rework the changes locally when a
>>new version came out. At the time, I didn't realise how rare new
>>releases were ;-)
>>=20
>>
>=20
> On my side, I had some time this year to contribute to an open-source
> project, and focused on gnuplot after having used octave for my physics
> studies. Letting others benefit from my work is one of my primary goal =
!
> And I would rather give my energy in something that I'm sure it has a
> stable future.
>=20
>=20
>>I was going to say that even if we can no longer make releases,
>>there's always the CVS that people can download the source
>>from. However, looking at the copyright again, could it be said that
>>having the CVS available on the internet is a violation of
>>
>>* Permission to modify the software is granted, but not the right to
>>* distribute the complete modified source code.
>>=20
>>
>=20
> You're probably right. I assume that cvs is used with the private
> agreement of Thomas.
>=20
>=20
>>>(I can't imagine somebody writing a script that patches the original
>>>source code, and then uses this modified code to patch his own code...
>>>as we might guess from the current copyright),
>>>  =20
>>>
>>
>>Again, the license prevents distribution of such a work, but you can
>>do anything you like with the sources locally.
>>=20
>>
>=20
> On the contrary, I was thinking of a way to satisfy gnuplot's license,
> ie to distribute the work as a patch plus the original source code...
> But anyway it's not reliable.
>=20
>=20
>>>* gpl, bsd, lgpl, mpl and other all allow to distribute modified code =
(I
>>>mean in usual form, not as a patch, and without asking for permission).
>>>This allows forks, but the most important is that it allows gnuplot
>>>developpers to release when they want, without relying on the agreemen=
t
>>>of somebody which may one day be unjoinable.
>>>
>>
>>Maybe one way out is to persuade Thomas Williams to grant permission
>>to a trusted nominee to release as and when required. Thomas would
>>retain the option to revoke that permission at a time of his choosing,
>>but it does mean that if he does vanish, there is one other person can
>>release..
>>
>>
>>dd
>>=20
>>
>=20
> Yes, it should be better in the short run than the current situation.
> But it's not really satisfying... as we will then rely on this trusted
> nominee, which can also become unjoinable one day... unless the nominee
> can name his successor if he wants to give away his responsibility...
>=20
> I would really prefer to solve the whole licensing issue (easy release =
+
> code reusability), either by choosing a well-known license (gpl or
> compatible), or by allowing redistribution of modified source code and
> binaries without restriction.

Don't know if I agree with the extent of that.  That basically means no c=
opyright whatsoever.  I'm not really against using open software in a pat=
ched way.  But there has to be some indication by the person doing the di=
stribution that said project was mainly developed by others and made avai=
lable freely and there is no warranty attributed to the original source.

It's a fair use issue as I see it.  If someone sells a software product t=
hat utilizes gnuplot, would that be breaking the copyright?  Maybe, maybe=
 not, but I'll hazard a guess no because RedHat, et al. would be in viola=
tion.  But to do so and not make it readily known that gnuplot is in fact=
 available elsewhere and not part of said product is misleading and unfai=
r.

Dan

Re: Thoughts about gnuplot license and copyrights

[Daniel J S. <dan...@ie...>]

Petr Mikulik wrote:
>> 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
> 
> 
> (La)TeX community has also such a kind of license: do whatever you want 
> with my code, but never call it the same if you distribute modified 
> versions.
> 
> (I vaguely remember a rumour that Debian had troubles even with 
> D.E.Knuth's license of TeX -- after he's gone, the version is set to pi 
> and no modification is allowed -- but that would be too hard decision 
> not to allow to package TeX for license religious reasons.)

TeX is sort of unique, it was developed by one person (I'm guessing) and copyright clearly falls to that individual.  Furthermore, he's made clear the intention.

But LaTeX is often the interface of choice for TeX.  If it is a solid core that remains unchanged (maybe a thing or two here or there could be better) then freezing may be a service.

Was there ever an analogous sort of thing in gnuplot?

> 
>> 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.
> 
> 
> Sourceforge is full of dead projects -- once the main author disappears, 
> others have not enough rights to continue.

Hence my comments about some oversight group.  Perhaps the day will come twenty years from now where so little activity in gnuplot takes place because it is such shiny sparkling, bug free stellar code.  Or maybe it will evolve in a way that outer layers can be placed on some core program.  Who knows?  You'd still like some group of people there to oversee copyright.

> 
>> They stop short of authorizing forks, although the distinction between
>> a modification and a fork is rather vague.
>>
>> Perhaps Thomas Williams would be willing to authorize periodic
>> releases by the cvs development team, while retaining veto power?
> 
> 
>>    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.
> 
> 
> That would be fine. Gnuplot developers (defined to be those having right 
> to contribute to cvs) would be approved to continue gnuplot development, 
> support and releases.

Wouldn't you think it should be copyright holders who have that authority?  Having access to CVS doesn't seem to me to have a legal basis.  Someone's signature on a piece of paper at a lawyer's office in Belgium might... or make that Paris (rather than have the document sent to them for notarizing, developers could travel there).

Dan

Re: Thoughts about gnuplot license and copyrights

[Daniel J S. <dan...@ie...>]

Dave Denholm wrote:

> Maybe one way out is to persuade Thomas Williams to grant permission
> to a trusted nominee to release as and when required. Thomas would
> retain the option to revoke that permission at a time of his choosing,
> but it does mean that if he does vanish, there is one other person can
> release..

I'd prefer it to be more than that.  I recall past discussion was that copyright has to be assigned to a *person*.  If gnuplot is meant to be a community development sort of thing, which I'm assuming it soon turned into after seeing all the names in files and the fact that no one ever objected to it or protected such copyright, then it should be maintained that way.  (I still fail to see how all of the additions in CVS since T.W. would fall copyright under someone not-so-active in its development.)

What would be nice is a gnuplot developers group who oversee this sort of thing.  Can copyright be transfered?  Ask T.W. if he is willing to do so, then have three people in the developers group attain copyright, with a very specific understanding (maybe backed up with a legal notice) that if ever one of the three is unable to respond to copyright matters within a year, the copyright will be transfered to someone else in the group.  And the language might be that copyright holders act in the spirit of community development.  I don't think there is anything about "open" software copyrights dealing with the copyright holders.

There would definitely be some paperwork, signatures and legal fees involved, but perhaps not too bad.  [Keep in mind that legal language itself is often inexact and left to judges to have "reasonable" interpretation.  That word "reasonable" shows up a lot in law.]  What good is a copyright if there is no one there to uphold it if ever some circumstance arises?

And by uphold I mean the developer group, after dicussion and recognizing someone or some company out there is attempting to usurp the software as their own, the copyright holders might have some authority to say, via lawyer, "hey, hold on".

Part of the problem is that legal systems and governments not being up to speed software technology in this area.  The day will probably come though when some kind of related court action appears (not necessarily gnuplot, but with so many such projects out there...).

Dan

Re: Thoughts about gnuplot license and copyrights

[Petr M. <mi...@ph...>]

> 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

(La)TeX community has also such a kind of license: do whatever you want with 
my code, but never call it the same if you distribute modified versions.

(I vaguely remember a rumour that Debian had troubles even with D.E.Knuth's 
license of TeX -- after he's gone, the version is set to pi and no 
modification is allowed -- but that would be too hard decision not to allow 
to package TeX for license religious reasons.)

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

Sourceforge is full of dead projects -- once the main author disappears, 
others have not enough rights to continue.

> They stop short of authorizing forks, although the distinction between
> a modification and a fork is rather vague.
>
> Perhaps Thomas Williams would be willing to authorize periodic
> releases by the cvs development team, while retaining veto power?

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

That would be fine. Gnuplot developers (defined to be those having right to 
contribute to cvs) would be approved to continue gnuplot development, 
support and releases. TW could veto it. If he disappears, the development 
goes further. That would guarantee gnuplot could still be developed in 15 
years, whoever is doing that.

Isn't there already some kind of this "semi-free" license already in use?

---
PM

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

Re: Thoughts about gnuplot license and copyrights

[Dave D. <dde...@es...>]

Ethan A Merritt <merritt@u.washington.edu> writes:

>>  * Permission to modify the software is granted, but not the right to
>>  * distribute the complete modified source code.
>
> Actually, I believe that distribution by CVS is exactly in line
> with that requirement. A CVS server, internally, is in fact a large
> set of sequential patches applied to a base version.  That is what
> lets you back-track to any previous date's version.  The fact that
> the server is capable of applying the patches for you on the server
> side, as well as handing you the base code and the separate patches,
> is a matter of convenience rather than substance.   
>


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. Now anyone can download a set of diffs to apply
locally, or they can download the tar of the head revision, which is
more convenient.


(b) definitely seems to violate the spirit of the license at
least. Yet I can't really see much difference between (a) and (b).



dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: Thoughts about gnuplot license and copyrights

[<tim...@en...>]

Lars Hecking wrote:
> Dave Denholm writes:
> [...]=20
>  =20
>> It may prevent the gnuplot terminal drivers from being
>> distributed with another program. (Maybe not : it says you cannot
>> distribute complete modified source tree, but doesn't see you cannot
>> distribute a partial set of unmodified sources..?)  =20
> This only serves to demonstrate how badly thought out the license is
> in the first place. Along with your cvs example further down.=20
Agreed.
>
>  I must add that getting permission for a release, while it sounds like
>  a big thing, was never a problem - my ipression was rather that tw is
>  happy enough to see ongoing development. There waws a discussion about
>  backwards-compatibility before the 4.0 release, due the syntax changes=
,
>  but that was resolved quickly (the 4.x branch will continue to accept
>  the old syntax).=20

>  Once this discussion is settled, I will write up a summary and raise
>  all the valid points with tw. It would be nice if at the same time I
>  was in a position to tell him we're closing in on a new release :) =20
That is a wise decision.
So, it would be nice to have the point of view of other developpers.

...

Dave Denholm a =E9crit :
> Lars Hecking <lhe...@us...> writes:
>
>  =20
>> Dave Denholm writes:
>> [...]=20
>>    =20
>>> It may prevent the gnuplot terminal drivers from being
>>> distributed with another program. (Maybe not : it says you cannot
>>> distribute complete modified source tree, but doesn't see you cannot
>>> distribute a partial set of unmodified sources..?)
>>>      =20
>>  This only serves to demonstrate how badly thought out the license is
>>  in the first place. Along with your cvs example further down.
>>    =20
Agreed.
>
> Actually, another program could include the *entire* unmodified
> gnuplot source distribution, and compile just the terminal drivers...
>  =20
Ok, it's possible, but to remain pragmatic, it's far from being practical.
>>> Maybe one way out is to persuade Thomas Williams to grant permission
>>> to a trusted nominee to release as and when required. Thomas would
>>> retain the option to revoke that permission at a time of his choosing=
,
>>> but it does mean that if he does vanish, there is one other person ca=
n
>>> release..
>>>      =20
>> =20
>>  I must add that getting permission for a release, while it sounds lik=
e
>>  a big thing, was never a problem
>>    =20
>
> One day, Thomas Williams *will* become unavailable, one way or
> another. One hopes that he will be around for a long time to come, but
> no-one is immortal.
>
>  - my ipression was rather that tw is
>  =20
>>  happy enough to see ongoing development. There waws a discussion abou=
t
>>  backwards-compatibility before the 4.0 release, due the syntax change=
s,
>>  but that was resolved quickly (the 4.x branch will continue to accept
>>  the old syntax).
>>    =20
> I trust no-one thinks that he is trying to block development. It's
> just unfortunate that this is probably the only way to avoid a fork.
>  =20
I am happy to know that Thomas pays attention to gnuplot, even if he=20
doesn't participate actively anymore. Unfortunately, Dave is right, he=20
can someday give away with his "responsibility" to bless new releases,=20
just by being unreachable for example.

> [...]
>>> could it be said that
>>> having the CVS available on the internet is a violation of
>>>
>>>  * Permission to modify the software is granted, but not the right to
>>> * distribute the complete modified source code.
>>>      =20
>> You're probably right. I assume that cvs is used with the private
>> agreement of Thomas.
>>    =20
> I'd assumed not, but maybe it gives a way out...
>
> gnuplot predates sourceforge and all the other hosts of open-source
> projects.
>
> If Thomas has (or will) sanction the cvs on sourceforce, then that
> gives us a working definition of which is the official master set of
> sources for gnuplot. So I wonder if we can open things up a bit, yet
> still prevent forking, by defining something in terms of that CVS.
>
> ie a released version of the gnuplot sources corresponds to a labelled
> version in cvs, Modifications can only be distribed in the form of
> patches to a specific labelled version. etc, etc.
>
>
> Hmm - it may not help if it ends up that only Thomas can do the
> labelling :-(  Maybe only he can label a major release, but the
> maintiners can independently label a minor release ?
>
>
> Not sure how that can be put into legalese, but...
Ethan wrote :

> Actually, I believe that distribution by CVS is exactly in line
> with that requirement. A CVS server, internally, is in fact a large
> set of sequential patches applied to a base version.  That is what
> lets you back-track to any previous date's version.  The fact that
> the server is capable of applying the patches for you on the server
> side, as well as handing you the base code and the separate patches,
> is a matter of convenience rather than substance. =20
Ok, so in some way cvs can be "legally" considered as a valid release way=
. IMHO it's not in the "spirit" of the copyright, and anyway it still pre=
vents from doing a standard package... Moreover, defining the license in =
the terms of a technology such as cvs is dangerous : for example, AFAIK s=
ourceforge will in the future switch to subversion...


Regards,

Timoth=E9e

Re: Thoughts about gnuplot license and copyrights

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

On Thursday 19 January 2006 07:14 am, Dave Denholm wrote:
> It may prevent the gnuplot terminal drivers from being
> distributed with another program. (Maybe not : it says you cannot
> distribute complete modified source tree, but doesn't see you cannot
> distribute a partial set of unmodified sources..?)

If it is a new driver, such as Timoth=E9e's wxWidgets driver,
then it is separated from the gnuplot core code by a
published API (in term_api.h and term/README). Furthermore, the
author can choose to make it available under multiple licenses.
=20
> I was going to say that even if we can no longer make releases,
> there's always the CVS that people can download the source
> from. However, looking at the copyright again, could it be said that
> having the CVS available on the internet is a violation of
>=20
>  * Permission to modify the software is granted, but not the right to
>  * distribute the complete modified source code.

Actually, I believe that distribution by CVS is exactly in line
with that requirement. A CVS server, internally, is in fact a large
set of sequential patches applied to a base version.  That is what
lets you back-track to any previous date's version.  The fact that
the server is capable of applying the patches for you on the server
side, as well as handing you the base code and the separate patches,
is a matter of convenience rather than substance.  =20


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Thoughts about gnuplot license and copyrights

[Dave D. <dde...@es...>]

Lars Hecking <lhe...@us...> writes:

> Dave Denholm writes:
> [...]=20
>> It may prevent the gnuplot terminal drivers from being
>> distributed with another program. (Maybe not : it says you cannot
>> distribute complete modified source tree, but doesn't see you cannot
>> distribute a partial set of unmodified sources..?)
>
>  This only serves to demonstrate how badly thought out the license is
>  in the first place. Along with your cvs example further down.
>

Actually, another program could include the *entire* unmodified
gnuplot source distribution, and compile just the terminal drivers...


>> Maybe one way out is to persuade Thomas Williams to grant permission
>> to a trusted nominee to release as and when required. Thomas would
>> retain the option to revoke that permission at a time of his choosing,
>> but it does mean that if he does vanish, there is one other person can
>> release..
>=20=20
>  I must add that getting permission for a release, while it sounds like
>  a big thing, was never a problem

One day, Thomas Williams *will* become unavailable, one way or
another. One hopes that he will be around for a long time to come, but
no-one is immortal.

 - my ipression was rather that tw is
>  happy enough to see ongoing development. There waws a discussion about
>  backwards-compatibility before the 4.0 release, due the syntax changes,
>  but that was resolved quickly (the 4.x branch will continue to accept
>  the old syntax).


I trust no-one thinks that he is trying to block development. It's
just unfortunate that this is probably the only way to avoid a fork.


However...

Timoth=E9e Lecomte <tim...@en...> writes:

>> I was going to say that even if we can no longer make releases,
>> there's always the CVS that people can download the source
>> from. However, looking at the copyright again, could it be said that
>> having the CVS available on the internet is a violation of
>>
>>  * Permission to modify the software is granted, but not the right to
>> * distribute the complete modified source code.
>=20=20
>
> You're probably right. I assume that cvs is used with the private
> agreement of Thomas.


I'd assumed not, but maybe it gives a way out...

gnuplot predates sourceforge and all the other hosts of open-source
projects.

If Thomas has (or will) sanction the cvs on sourceforce, then that
gives us a working definition of which is the official master set of
sources for gnuplot. So I wonder if we can open things up a bit, yet
still prevent forking, by defining something in terms of that CVS.

ie a released version of the gnuplot sources corresponds to a labelled
version in cvs, Modifications can only be distribed in the form of
patches to a specific labelled version. etc, etc.


Hmm - it may not help if it ends up that only Thomas can do the
labelling :-(  Maybe only he can label a major release, but the
maintiners can independently label a minor release ?



Not sure how that can be put into legalese, but...




dd
--=20
Dave Denholm              <dde...@es...>       http://www.esmertec=
.com

Re: Thoughts about gnuplot license and copyrights

[<tim...@en...>]

Dave Denholm wrote:

>Timoth=E9e Lecomte <tim...@en...> writes:
> =20
>
>>Robert Hart wrote:
>>   =20
>>
>>>>IMHO the gnuplot license is very close to the standard BSD license, w=
hich
>>>>imposes fewer restrictions than the GPL.
>>>>       =20
>>>>
>My understanding is that GPL comes with lots of words of legalese,
>but most of the restrictions are designed to prevent any one person
>from restricting anyone else from doing what they want with the code.
>
>BSD has few legal restrictions, but means that someone can modify the
>source and then distribute with more restrictions (including binary only=
).
>
>The one thing I do tend to feel strongly about is that if I put in
>time developing open-source software, I don't want someone else
>exploiting it for profit. BSD license doesn't prevent that, though GPL
>probably does.
> =20
>
Yes, I agree with this. My feeling is that the gpl is really the result
of a deep thinking to preserve copyleft, not only a long-and-unreadable
text.

>>>The purpose of the GPL, is not (just) to allow forks, or other indepen=
dent
>>>developments and patches, but also to allow code to be reused in entir=
ely
>>>separate projects. AFAICT, there is nothing in the gnuplot license tha=
t
>>>would let me (say) use the gnuplot terminal drivers as the start point=
 for
>>>some other graphical program.=20
>>>
>It may prevent the gnuplot terminal drivers from being
>distributed with another program. (Maybe not : it says you cannot
>distribute complete modified source tree, but doesn't see you cannot
>distribute a partial set of unmodified sources..?)
> =20
>
To my mind, a 'partial set of unmodified sources' is to understand as a
'complete modified source tree' according to the current copyright.

>However, it doesn't prevent you from designing and distributing a
>program which uses the same interface, allowing people who download it
>to link it locally with gnuplot terminal drivers. Well, that was one
>of the notions behind the terminal driver changes described in
>term/README
>
>I guess an analogy would be with gnu readline : the GPL
>prevents us from distributing a gnuplot binary that links with it, but
>someone building from source can link *their* copy with gnu readline.
>
>For a while, we (well, I) was considering breaking gnuplot into layers
>of libraries, with the lowest layer offering access to the graphics
>drivers, and the highest layer offering most of the gnuplot
>functionality. The gnuplot program would then just be a thin client of
>the library. But that never happened.
> =20
>
Well, that may happen one day ;-)
I agree that linking is possible provided some conditions (mostly a
'local linking') but it's definetely complicated !

>>>whilst happy to use gnuplot, are reluctant to get too involved in
>>>developing it because of that.
>>>
>[ reordering slightly]
>
>> am exactly asking myself the same thing : is it worth getting
>>seriously involved in gnuplot, if it someday vanishes just because
>>Thomas won't be joinable to give his agreement ?
>>   =20
>>
>Depends on your motives : when I got involved with gnuplot, it was
>because *I* was using it a lot, and I wanted to improve it for my own
>use. Contributing the changes let others benefit from them, but more
>importantly, meant I didn't have to rework the changes locally when a
>new version came out. At the time, I didn't realise how rare new
>releases were ;-)
> =20
>
On my side, I had some time this year to contribute to an open-source
project, and focused on gnuplot after having used octave for my physics
studies. Letting others benefit from my work is one of my primary goal !
And I would rather give my energy in something that I'm sure it has a
stable future.

>I was going to say that even if we can no longer make releases,
>there's always the CVS that people can download the source
>from. However, looking at the copyright again, could it be said that
>having the CVS available on the internet is a violation of
>
> * Permission to modify the software is granted, but not the right to
> * distribute the complete modified source code.
> =20
>
You're probably right. I assume that cvs is used with the private
agreement of Thomas.

>>(I can't imagine somebody writing a script that patches the original
>>source code, and then uses this modified code to patch his own code...
>>as we might guess from the current copyright),
>>   =20
>>
>
>Again, the license prevents distribution of such a work, but you can
>do anything you like with the sources locally.
> =20
>
On the contrary, I was thinking of a way to satisfy gnuplot's license,
ie to distribute the work as a patch plus the original source code...
But anyway it's not reliable.

>>* gpl, bsd, lgpl, mpl and other all allow to distribute modified code (=
I
>>mean in usual form, not as a patch, and without asking for permission).
>>This allows forks, but the most important is that it allows gnuplot
>>developpers to release when they want, without relying on the agreement
>>of somebody which may one day be unjoinable.
>>
>Maybe one way out is to persuade Thomas Williams to grant permission
>to a trusted nominee to release as and when required. Thomas would
>retain the option to revoke that permission at a time of his choosing,
>but it does mean that if he does vanish, there is one other person can
>release..
>
>
>dd
> =20
>
Yes, it should be better in the short run than the current situation.
But it's not really satisfying... as we will then rely on this trusted
nominee, which can also become unjoinable one day... unless the nominee
can name his successor if he wants to give away his responsibility...

I would really prefer to solve the whole licensing issue (easy release +
code reusability), either by choosing a well-known license (gpl or
compatible), or by allowing redistribution of modified source code and
binaries without restriction.

Thanks for your precious point of view, and your help in this situation !

Regards,

Timoth=E9e Lecomte

Re: Thoughts about gnuplot license and copyrights

[Lars H. <lhe...@us...>]

Dave Denholm writes:
[...] 
> It may prevent the gnuplot terminal drivers from being
> distributed with another program. (Maybe not : it says you cannot
> distribute complete modified source tree, but doesn't see you cannot
> distribute a partial set of unmodified sources..?)

 This only serves to demonstrate how badly thought out the license is
 in the first place. Along with your cvs example further down.

> I guess an analogy would be with gnu readline : the GPL
> prevents us from distributing a gnuplot binary that links with it, but
> someone building from source can link *their* copy with gnu readline.
 
 Readline is a fscked up case: it should really be distributed under LGPL
 rather than GPL ...

> Depends on your motives : when I got involved with gnuplot, it was
> because *I* was using it a lot, and I wanted to improve it for my own
> use. Contributing the changes let others benefit from them, but more
> importantly, meant I didn't have to rework the changes locally when a
> new version came out. At the time, I didn't realise how rare new
> releases were ;-)
 
 That pretty much sums it up for me, too ;-)

> Maybe one way out is to persuade Thomas Williams to grant permission
> to a trusted nominee to release as and when required. Thomas would
> retain the option to revoke that permission at a time of his choosing,
> but it does mean that if he does vanish, there is one other person can
> release..
 
 I must add that getting permission for a release, while it sounds like
 a big thing, was never a problem - my ipression was rather that tw is
 happy enough to see ongoing development. There waws a discussion about
 backwards-compatibility before the 4.0 release, due the syntax changes,
 but that was resolved quickly (the 4.x branch will continue to accept
 the old syntax).

 Once this discussion is settled, I will write up a summary and raise
 all the valid points with tw. It would be nice if at the same time I
 was in a position to tell him we're closing in on a new release :)

Re: Thoughts about gnuplot license and copyrights

[Dave D. <dde...@es...>]

Timoth=E9e Lecomte <tim...@en...> writes:

> Robert Hart wrote:
>
>>=20=20
>>
>>>IMHO the gnuplot license is very close to the standard BSD license, which
>>>=20=20=20=20
>>>
>>>imposes fewer restrictions than the GPL.


My understanding is that GPL comes with lots of words of legalese,
but most of the restrictions are designed to prevent any one person
from restricting anyone else from doing what they want with the code.

BSD has few legal restrictions, but means that someone can modify the
source and then distribute with more restrictions (including binary only).


The one thing I do tend to feel strongly about is that if I put in
time developing open-source software, I don't want someone else
exploiting it for profit. BSD license doesn't prevent that, though GPL
probably does.


>>>
>>
>>The purpose of the GPL, is not (just) to allow forks, or other independent
>>developments and patches, but also to allow code to be reused in entirely
>>separate projects. AFAICT, there is nothing in the gnuplot license that
>>would let me (say) use the gnuplot terminal drivers as the start point for
>>some other graphical program.=20
>>

It may prevent the gnuplot terminal drivers from being
distributed with another program. (Maybe not : it says you cannot
distribute complete modified source tree, but doesn't see you cannot
distribute a partial set of unmodified sources..?)

However, it doesn't prevent you from designing and distributing a
program which uses the same interface, allowing people who download it
to link it locally with gnuplot terminal drivers. Well, that was one
of the notions behind the terminal driver changes described in
term/README

I guess an analogy would be with gnu readline : the GPL
prevents us from distributing a gnuplot binary that links with it, but
someone building from source can link *their* copy with gnu readline.


For a while, we (well, I) was considering breaking gnuplot into layers
of libraries, with the lowest layer offering access to the graphics
drivers, and the highest layer offering most of the gnuplot
functionality. The gnuplot program would then just be a thin client of
the library. But that never happened.


>>whilst happy to use gnuplot, are reluctant to get too involved in
>>developing it because of that.
>>

[ reordering slightly]

> I am exactly asking myself the same thing : is it worth getting
> seriously involved in gnuplot, if it someday vanishes just because
> Thomas won't be joinable to give his agreement ?


Depends on your motives : when I got involved with gnuplot, it was
because *I* was using it a lot, and I wanted to improve it for my own
use. Contributing the changes let others benefit from them, but more
importantly, meant I didn't have to rework the changes locally when a
new version came out. At the time, I didn't realise how rare new
releases were ;-)


I was going to say that even if we can no longer make releases,
there's always the CVS that people can download the source
from. However, looking at the copyright again, could it be said that
having the CVS available on the internet is a violation of

 * Permission to modify the software is granted, but not the right to
 * distribute the complete modified source code.




> (I can't imagine somebody writing a script that patches the original
> source code, and then uses this modified code to patch his own code...
> as we might guess from the current copyright),

Again, the license prevents distribution of such a work, but you can
do anything you like with the sources locally.



> * gpl, bsd, lgpl, mpl and other all allow to distribute modified code (I
> mean in usual form, not as a patch, and without asking for permission).
> This allows forks, but the most important is that it allows gnuplot
> developpers to release when they want, without relying on the agreement
> of somebody which may one day be unjoinable.
>


Maybe one way out is to persuade Thomas Williams to grant permission
to a trusted nominee to release as and when required. Thomas would
retain the option to revoke that permission at a time of his choosing,
but it does mean that if he does vanish, there is one other person can
release..


dd
--=20
Dave Denholm              <dde...@es...>       http://www.esmertec=
.com

Re: Thoughts about gnuplot license and copyrights

[<tim...@en...>]

Robert Hart wrote:

> =20
>
>>IMHO the gnuplot license is very close to the standard BSD license, whi=
ch
>>   =20
>>
>>imposes fewer restrictions than the GPL.
>>   =20
>>
>
>The purpose of the GPL, is not (just) to allow forks, or other independe=
nt
>developments and patches, but also to allow code to be reused in entirel=
y
>separate projects. AFAICT, there is nothing in the gnuplot license that
>would let me (say) use the gnuplot terminal drivers as the start point f=
or
>some other graphical program.=20
>
>Additionally, I think there is a lot to be said for going with one of th=
e
>more standard licenses. If it actually is BSD, or GPL or LGPL, or MPL,
>then people know what that means. Whereas the gnuplot license seems to
>cause no end of confusion (partly due to the unfortunate coincidence in
>the use of "GNU" as part of the name), and I know people like myself,
>whilst happy to use gnuplot, are reluctant to get too involved in
>developing it because of that.
>
>Rob
> =20
>
I agree with you, Robert. You have pointed out two important points :

* gpl, bsd, lgpl, mpl are more explicit concerning the reuse of existing
code in other projects. The current gnuplot doesn't even seem to talk
about this case, and we probably have to conclude that it is forbidden
(I can't imagine somebody writing a script that patches the original
source code, and then uses this modified code to patch his own code...
as we might guess from the current copyright),

* gpl, bsd, lgpl, mpl and other all allow to distribute modified code (I
mean in usual form, not as a patch, and without asking for permission).
This allows forks, but the most important is that it allows gnuplot
developpers to release when they want, without relying on the agreement
of somebody which may one day be unjoinable.

I am exactly asking myself the same thing : is it worth getting
seriously involved in gnuplot, if it someday vanishes just because
Thomas won't be joinable to give his agreement ?

Can we help this situation to evolve for good ?

Thank you very much for your condideration.

Best regards,

Timoth=E9e Lecomte

___________________________

As a reference, here is the "Modified BSD license" (i.e. original BSD
without a point on advertising) :

    Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are me=
t:
       1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
       2. Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following disclaimer
in the documentation and/or other materials provided with the distributio=
n.
       3. The name of the author may not be used to endorse or promote
products derived from this software without specific prior written
permission.
    THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND [etc. : the
author is not responsible of possible damage caused by the software].

As you can see, the BSD license is really more "libre" that the gnuplot
one is.

Re: Thoughts about gnuplot license and copyrights

[Robert H. <en...@no...>]

> IMHO the gnuplot license is very close to the standard BSD license,
which
> imposes fewer restrictions than the GPL.

The purpose of the GPL, is not (just) to allow forks, or other independent
developments and patches, but also to allow code to be reused in entirely
separate projects. AFAICT, there is nothing in the gnuplot license that
would let me (say) use the gnuplot terminal drivers as the start point for
some other graphical program. 

Additionally, I think there is a lot to be said for going with one of the
more standard licenses. If it actually is BSD, or GPL or LGPL, or MPL,
then people know what that means. Whereas the gnuplot license seems to
cause no end of confusion (partly due to the unfortunate coincidence in
the use of "GNU" as part of the name), and I know people like myself,
whilst happy to use gnuplot, are reluctant to get too involved in
developing it because of that.

Rob



This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: Instructions in FAQ for anonymous CVS don't seem to work

[Petr M. <mi...@ph...>]

> I followed the instructions in the FAQ for getting to anonymous CVS, and they 
> don't seem to work

I've updated it them.

> The instructions at 
> http://www.gnuplot.info/development/index.html#DownloadCVS
> are similarly problematic.

They work.

---
PM