Menu
▾
▴
gnuplot-beta
|
From: <tim...@en...> - 2006-01-17 15:14:39
|
Hi gnuplot developpers and users !
Recently, I have been thinking about the way gnuplot is licensed. As I
have worked a lot on the wxWidgets terminal (and am still working on
it), and as I am a strongly in favor of "libre" software, I wonder about
the future of this work...
On this mailing list, in september 2005, while talking about a possible
release of a 4.1 version, Hans-Bernhard Broeker explained :
" "People have got used to a release early --- release often" strategy.=20
Sorry, but with the licensing issues as they are, that's a non-option
for gnuplot. "
Well, "release often" is probably not the best idea, and I agree that
bugs have to be eradicated as much as possible before. However, I fear
that the situation of gnuplot tends to be : "rare release, cope with
CVS". And what will this evolve to when the people who hold the
copyrights cannot be contacted ?
With "grep -C 5 Copyright *" in the gnuplot source, I found that most of
the copyrights belong to Thomas Williams and Colin Kelley.
Some files are public domain (fit, matrix).
Most terminals don't mention who holds the copyright ("Copyright [a
year]") but specify an author later (should the reader understand that
they own the copyright ?).
Other files belong to :
Robert K. Cunningham (datafile),
Daniel Sebald (bin_hook),
Petr Mikulik (with the mention : "as open source as possible"),
Craig R. Schardt, Maurice Castro, Russell Lang (windows),
Hans-Bernhard Broeker (dynarray, windows),
Roger Fearick (pm),
Jos van der Woude (statistical functions, specfun),
Phil Type, Bruce Ravel, Gershon Elber (lisp),
Stephen L. Moshier (some code in specfun),
Lars Hecking (tables),
Ronald Florence (cgi.trm),
P. Klosowski (excl.trm),
James Darrell McCauley (grass.trm).
The copyright text mentions that it is not possible to distribute a
modified source code. So, who can give the permission ? Who gave it for
gnuplot 4.0 ? Who will give it for gnuplot 4.1 ? Who will give it later ?
I wonder if this situation has a future... What are the possibilities ?
To my (humble) mind, they are the following :
* Nothing changes concerning copyrights and license. CVS will be filled
by new (useful, powerful and innovative) code, and probably new files
with new people owning the corresponding copyrights. But one day, nobody
will be able to release officially and legally anything. gnuplot will
vanish in some backup disk at sourceforge.net ;-)
* Something is changed on gnuplot copyright. What for ? Probably to
allow easier distributions. How ? Either by modifying the current
license, or by choosing a well-known and well-understood license
commonly used in open source programs instead. What does this imply ?
Probably to contact all developpers who own their respective copyrights,
and ask for their approval on the proposed change. Some of them disagree
or are not joinable ? Their code should probably be rewritten from scratc=
h.
Well, it's a huge decision, but what do you honestly prefer ? The first
case ? Probably not. But that might happen, really.
I don't see a valid reason to not *protect* the work of great value that
gnuplot represents.
Of course, gnuplot can also vanish with a more adapted license. But
that's not a reason.
Of course, in the early days of gnuplot, the gpl (as an example) did not
exist. But that's not a reason for not changing now.
What do you think about it ? What do Thomas Williams and Colin Kelley
think about it, as they own the copyrights for most of gnuplot code ?
Do you agree that something should be done to protect gnuplot ?
I hope that I have not raised a "too-often raised" problem, already
answered many times. I really don't want to provoke anybody. Please
excuse me for any inconvenience and for the noise.
Best regards,
Timoth=E9e Lecomte
|
|
From: Lars H. <lhe...@us...> - 2006-01-17 15:37:50
|
> I hope that I have not raised a "too-often raised" problem, already > answered many times. I really don't want to provoke anybody. Please > excuse me for any inconvenience and for the noise. The topic pops up every now and then. Check the archives. |
|
From: <tim...@en...> - 2006-01-17 16:32:34
|
Lars Hecking wrote: >>I hope that I have not raised a "too-often raised" problem, already >>answered many times. I really don't want to provoke anybody. Please >>excuse me for any inconvenience and for the noise. >> =20 >> >=20 > The topic pops up every now and then. Check the archives. > > =20 > Well, sorry again for the inconvenience. I looked into archives, and the last message that I found about the license was written in 2004 (there has been a discussion in 2005 about how copyrights are written in the files, but not about the license itself= ). I have concluded that Thomas Williams is the one who has to give its agreement before an official release. Can you confirm ? Would it be possible to have further details on his position about the license ? Archives say that the gpl was refused. Is there a precise reason, or is Thomas William simply opposed to a change ? Another open-source license may fit the needs. By the way, as the FAQ doesn't mention it, the actual position of the author against licenses could be a good addition. To make this thread at least somehow useful, you will find below a compilation of what archives say. Best regards, Timoth=E9e lecomte ______________________ From Hans-Bernhard Broeker Date: 2004-07-29 On Thu, 29 Jul 2004, Roland Stigge wrote: [...] > I find it annoying that through a different license, > I'm not allowed to link this software with GPL programs, most > importantly, with GNU readline. You, me, and a lot of others. But the holders of the gnuplot copyright (who are no longer involved in active development, and indeed haven't bee= n in a *long* time) refuse to switch to GPL. We've tried a couple times, and even RMS himself has (allegedly?) tried. Nothing gave. _____________________________ From Lars Hecking Newsgroups: gmane.comp.graphics.gnuplot.devel Date: 2004-06-02 > Is there a chance to get the license changed, so that debian can ship > gnuplot with the gnu readline? The gnuplot license? Not much of a chance. However, I think this could work if readline was distributed under the LGPL instead of GPL. __________________________________ From: Hans-Bernhard Broeker Subject: Re: gnu readline / license Newsgroups: gmane.comp.graphics.gnuplot.devel Date: 2004-06-02 > Is there a chance to get the license changed, so that debian can ship > gnuplot with the gnu readline? Essentially: no. Neither side of this conflict appears willing to bugde. That has been tried in the past, but never succeeded. ________________________________ From Hans-Bernhard Broeker Subject: Ready for wrap-up everyone? Newsgroups: gmane.comp.graphics.gnuplot.devel Date: 2004-04-05 in case some of us forgot, the release target date I agreed us upon was end of *this* week? So, what's left to do that really has to be done before then? *) Lars: contact Tom Williams (and whoever else you contacted last time) for the formal "blessing" according to the gnuplot Copyright statement. _____________________________________ From Hans-Bernhard Broeker comp.graphics.apps.gnuplot Date : 28 Jul 2003 Objet : Re: copyright/license > Sorry if this is a silly question, but I wondered if there was any > progress/intention to try and find the original gnuplot authors and > ask for their permission to distribute gnuplot under GPL or some other > open source license that doesn't carry the restrictions of the current > setup.=20 It has been tried quite a while ago (for version 3.7.1, IIRC), and the answer was a rather strict "no" regarding GPL. =20 |
|
From: Lars H. <lhe...@us...> - 2006-01-17 17:15:04
|
> I have concluded that Thomas Williams is the one who has to give its > agreement before an official release. Can you confirm ? Would it be That is correct. As the other copyright holder, Colin Kelley, is missing in action, Thomas Williams is our only contact. > possible to have further details on his position about the license ? > Archives say that the gpl was refused. Is there a precise reason, or is > Thomas William simply opposed to a change ? Another open-source license > may fit the needs. I have discussed development issues with Thomas in the past, and the only time I ever mentioned license changes (and the "single point of failure" issue) there was no reply. I'm sure that particular email was received, and we were in contact again for the 4.0 release - which he liked a lot :) > By the way, as the FAQ doesn't mention it, the actual position of the > author against licenses could be a good addition. I really have nothing to back this up, but people like Dave Denholm or Alex Woo might. |
|
From: Dave D. <dde...@es...> - 2006-01-18 14:19:33
|
Lars Hecking <lhe...@us...> writes: >> I have concluded that Thomas Williams is the one who has to give its >> agreement before an official release. Can you confirm ? Would it be > > That is correct. As the other copyright holder, Colin Kelley, is missing > in action, Thomas Williams is our only contact. > >> possible to have further details on his position about the license ? >> Archives say that the gpl was refused. Is there a precise reason, or is >> Thomas William simply opposed to a change ? Another open-source license >> may fit the needs. My recollection is that Thomas Williams is (or was) opposed the notion that gnuplot might ever fork into multiple, incompatible versions. > > I have discussed development issues with Thomas in the past, and the only > time I ever mentioned license changes (and the "single point of failure" > issue) there was no reply. I'm sure that particular email was received, > and we were in contact again for the 4.0 release - which he liked a lot :) > >> By the way, as the FAQ doesn't mention it, the actual position of the >> author against licenses could be a good addition. > > I really have nothing to back this up, but people like Dave Denholm or > Alex Woo might. > I've dug out a very old mail folder "gnuplot.legal" which contains a thread from around August 1977 (wow, that's old...) But I suspect it's obsolete, since it was arguing about changing the license to allow distribution of modified binaries. Previously, this was completely prohibited, but it looks like the Copyright in the 4.0 sources at least does grant permission to distribute modified binaries, with a few restrictions. At the time, this was enough to happify Richard Stallman (who actually approached me around this time to write a truly free gnuplot clone if the license wouldn't get changed) It's currently just a collection of separate mh files, but if anyone's interested, I can pack it into an mbox and upload it somewhere. Since I never actually got round to making a gnuplot release during my time as maintenaner, I didn't have to go through all this pain myself! dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-01-18 18:58:55
|
On Wednesday 18 January 2006 06:18 am, Dave Denholm wrote: > It looks like the Copyright in the 4.0 > sources at least does grant permission to distribute modified > binaries, with a few restrictions. Right. It currently says: * Permission to modify the software is granted, but not the right to * distribute the complete modified source code. Modifications are to * be distributed as patches to the released version. Permission to * distribute binaries produced by compiling modified sources is granted, * provided you * 1. distribute the corresponding source modifications from the * released version in the form of a patch file along with the binaries, * 2. add special version identification to distinguish your version * in addition to the base release version number, * 3. provide your name and address as the primary contact for the * support of your modified version, and * 4. retain our contact information in regard to use of the base * software. * Permission to distribute the released version of the source code along * with corresponding source modifications in the form of a patch file is * granted with same provisions 2 through 4 for binary distributions. > At the time, this was enough to happify Richard Stallman (who > actually approached me around this time to write a truly free gnuplot > clone if the license wouldn't get changed) As I read it, and on the basis of previous correspondence with members of the Debian packaging group, this is also sufficient to allow the various linux distros to package and include 4.1 direct from the cvs version even without a new official release. It would require packaging the 4.1 source as a diff against 4.0. This would be a rather large diff file, admittedly. But it would certainly have been a reasonable mechanism for them to have released a bug-fix update to 4.0 based on our 4.0 stable branch. In the next release cycle we should try to make this more obvious to the various packaging teams. [insert standard I-am-not-a-lawyer disclaimer] But I really think we do need to start on the path to an official 4.2 release. Recent suggestions from several directions to put a 4.1 snapshot on the web site have produced little response. Does anyone have specific objections? It would not commit us to any fixed release date; it would just start the ball rolling. Ethan -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: <tim...@en...> - 2006-01-18 20:15:50
|
Dave Denholm wrote : > Lars Hecking <lhe...@us...> writes: > > =20 >>> I have concluded that Thomas Williams is the one who has to give its >>> agreement before an official release. Can you confirm ? Would it be >>> =20 >> That is correct. As the other copyright holder, Colin Kelley, is miss= ing >> in action, Thomas Williams is our only contact. >> >> =20 >>> possible to have further details on his position about the license ? >>> =20 > > =20 >>> Archives say that the gpl was refused. Is there a precise reason, or = is >>> Thomas William simply opposed to a change ? Another open-source licen= se >>> may fit the needs. >>> =20 > > > My recollection is that Thomas Williams is (or was) opposed the notion > that gnuplot might ever fork into multiple, incompatible versions. > > =20 >> I have discussed development issues with Thomas in the past, and the = only >> time I ever mentioned license changes (and the "single point of failu= re" >> issue) there was no reply. I'm sure that particular email was receive= d, >> and we were in contact again for the 4.0 release - which he liked a l= ot :) >> >> =20 >>> By the way, as the FAQ doesn't mention it, the actual position of the >>> author against licenses could be a good addition. >>> =20 >> I really have nothing to back this up, but people like Dave Denholm o= r >> Alex Woo might. >> >> =20 > > I've dug out a very old mail folder "gnuplot.legal" which contains a > thread from around August 1977 (wow, that's old...) > > But I suspect it's obsolete, since it was arguing about changing the > license to allow distribution of modified binaries. Previously, this > was completely prohibited, but it looks like the Copyright in the 4.0 > sources at least does grant permission to distribute modified > binaries, with a few restrictions. > > At the time, this was enough to happify Richard Stallman (who actually > approached me around this time to write a truly free gnuplot clone if > the license wouldn't get changed) > > It's currently just a collection of separate mh files, but if anyone's > interested, I can pack it into an mbox and upload it somewhere. > > > Since I never actually got round to making a gnuplot release during my > time as maintenaner, I didn't have to go through all this pain myself! > > > dd > =20 Well, that's interesting information ! (Wow, 1977 ! I was not born, and my parents just get married !) So, some years ago,Thomas Williams refused the gpl because forks would=20 be authorized. I may understand this position, as there is a risk to=20 lose the control over a program if one allows forks for it. However,=20 gnuplot is a long-standing software, and a slightly more permissive=20 license allowing direct redistribution of modified source code is a=20 decision for a brighter future, not a decision to make it disappear... Unfortunately, as far as I know, there is no license which at the same=20 time is compatible with the gpl and forbids forks. Do you think Thomas=20 may have a different opinion about the gnuplot license now ? As Ethan says, the current license is just enough to make distributions=20 package their binaries and apply a small patch over the source. But,=20 apart from distributors, I am concerned about the work done on the=20 trunk. Do you know if Thomas will ever be there to give its agreement to=20 a new release ? What will happen if someday he becomes unjoinable ? Thank you very much for these details, Dave, I find it interesting to=20 know what happened to such great piece of work in time. Best regards, Timoth=E9e Lecomte |
|
From: Lars H. <lhe...@us...> - 2006-01-19 09:28:48
|
> Unfortunately, as far as I know, there is no license which at the same > time is compatible with the gpl and forbids forks. Do you think Thomas > may have a different opinion about the gnuplot license now ? IMHO the gnuplot license is very close to the standard BSD license, which imposes fewer restrictions than the GPL. |
|
From: Robert H. <en...@no...> - 2006-01-19 13:00:17
|
> 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. |
|
From: <tim...@en...> - 2006-01-19 14:03:23
|
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.
|
|
From: Dave D. <dde...@es...> - 2006-01-19 15:14:46
|
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 |
|
From: Lars H. <lhe...@us...> - 2006-01-19 15:43:41
|
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 :) |
|
From: Dave D. <dde...@es...> - 2006-01-19 16:26:26
|
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 |
|
From: <tim...@en...> - 2006-01-19 17:22:09
|
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 |
|
From: <tim...@en...> - 2006-01-19 15:55:53
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2006-01-20 07:08:16
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2006-01-20 07:53:56
|
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 |
|
From: <tim...@en...> - 2006-01-20 15:08:18
|
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
|
|
From: Dave D. <dde...@es...> - 2006-01-20 16:27:28
|
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 |
|
From: Hans-Bernhard B. <br...@ph...> - 2006-01-20 19:03:30
|
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? |
|
From: Daniel J S. <dan...@ie...> - 2006-01-20 19:34:47
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2006-01-21 09:00:39
|
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 |
|
From: <tim...@en...> - 2006-01-21 11:41:05
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2006-01-20 04:11:24
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2006-01-20 18:25:31
|
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 |
