Menu
▾
▴
gnuplot-beta
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-01-19 16:44:19
|
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 |
|
From: Dave D. <dde...@es...> - 2006-01-19 17:43:21
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-01-19 18:55:23
|
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 |
|
From: Petr M. <mi...@ph...> - 2006-01-19 20:49:57
|
> 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 |
|
From: Daniel J S. <dan...@ie...> - 2006-01-20 04:33:29
|
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 |
|
From: Hans-Bernhard B. <br...@ph...> - 2006-01-20 13:42:10
|
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. |
|
From: Daniel J S. <dan...@ie...> - 2006-01-21 12:53:07
|
Timoth=E9e Lecomte wrote: > 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. >=20 > To remain pragmatic, I think that we can't reach the same conditions fo= r > gnuplot. Why not? I know the common belief now days is that only "big" entities h= ave or can afford rights, representation, etc. But the law isn't restric= ted to them. In fact, a lot of these legal concepts probably were origin= ally intended to protect the individual. > As Hans-Bernhard Broeker also explained, a trademark would be needed to > protect the name 'gnuplot'. To remain pragmatic, nobody will provide th= e > money to have a 'gnuplot' trademark. I'm not assuming that. International trademark looks to be $500 (it's in= swiss currency) for ten years. Not unreasonable. But that's an aside. = (Might make it easy though to recover www.gnuplot.com from that person w= ho gobbled it up.) Let's put it this way. You mentioned having a little assurance that work= doesn't get wasted. Well, take the work of the number of people who hav= e contributed and add up their time as though it were charged an hourly r= ate. Wow, that would be one damn big monetary gift; intended, I think, f= or science. It wouldn't kill me to contribute monetarily to solidifying = a license so long as it's reasonable. > And if we define a "maintainers group", it would still be a list of > named individuals who can disappear one day. Hence, why I propose that if a member of the group goes silent for a year= , someone else is allowed to take over. If it gets to the point where th= ere isn't a dozen or so people who could be a pool for just a few maintai= ners then nobody cares anymore. Or do a D. Knuth thing and freeze it for= good. > The solution would be a > sort of foundation, but I can't imagine such a complex legal entity for > just gnuplot. Not complex. Keep it simple. Nobody is attempting to collect royalties. >=20 > 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. That's one alternative I'm saying leave on the table. I guess my feeling is that gnuplot has had some license now for a long ti= me. If out of the blue it changes to a different license it would be goo= d, I think, to have it made clear that T.W. has signed off on that. Cert= ainly an email from T.W. wouldn't hold much water. (Someone could claim = the email was made up by someone else.) Something he can sign (notarized= ) that can be put in a safe deposit box would be nice. To change the lic= ense without there being a clear understanding of that intention would ju= st add more confusion. Dan |
|
From: <tim...@en...> - 2006-01-22 00:43:58
|
Daniel J Sebald wrote: > Timoth=E9e Lecomte wrote: > >> 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 not= e >> 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 f= or >> gnuplot. > > > Why not? I know the common belief now days is that only "big" > entities have or can afford rights, representation, etc. But the law > isn't restricted to them. In fact, a lot of these legal concepts > probably were originally intended to protect the individual. Ok, it is possible, but personnaly I don't want > >> As Hans-Bernhard Broeker also explained, a trademark would be needed t= o >> protect the name 'gnuplot'. To remain pragmatic, nobody will provide t= he >> money to have a 'gnuplot' trademark. > > > I'm not assuming that. International trademark looks to be $500 (it's > in swiss currency) for ten years. Not unreasonable. But that's an > aside. (Might make it easy though to recover www.gnuplot.com from > that person who gobbled it up.) > > Let's put it this way. You mentioned having a little assurance that > work doesn't get wasted. Well, take the work of the number of people > who have contributed and add up their time as though it were charged > an hourly rate. Wow, that would be one damn big monetary gift; > intended, I think, for science. It wouldn't kill me to contribute > monetarily to solidifying a license so long as it's reasonable. I completely agree with you : the work already done deserves a monetary contribution. But solidifying the license can also be done without any money. It's just a matter of what we want to protect, and how far we are ready to go. >> And if we define a "maintainers group", it would still be a list of >> named individuals who can disappear one day. > > > Hence, why I propose that if a member of the group goes silent for a > year, someone else is allowed to take over. If it gets to the point > where there isn't a dozen or so people who could be a pool for just a > few maintainers then nobody cares anymore. Or do a D. Knuth thing and > freeze it for good. Well, as we should probably not freeze it ;-), I find the first proposal a valid solution. > >> The solution would be a >> sort of foundation, but I can't imagine such a complex legal entity fo= r >> just gnuplot. > > > Not complex. Keep it simple. Nobody is attempting to collect royaltie= s. Royalties, no, but signatures, yes. I don't like paper work, but I admit it is feasible. >> 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. > > > That's one alternative I'm saying leave on the table. > > I guess my feeling is that gnuplot has had some license now for a long > time. If out of the blue it changes to a different license it would > be good, I think, to have it made clear that T.W. has signed off on > that. Certainly an email from T.W. wouldn't hold much water.=20 > (Someone could claim the email was made up by someone else.)=20 > Something he can sign (notarized) that can be put in a safe deposit > box would be nice. To change the license without there being a clear > understanding of that intention would just add more confusion. > > Dan Yes, if there's a change, we should be able to prove that TW has approved it. I have wondered how things go for other projects. Indeed, instead of trying to resolve the gnuplot's license disadvantage ourselves, we can get the inspiration from others (that's not copyrighted !). So I have made a compilation of information on famous scientific open-source software. Let's see : * octave ( numerical computations): GPL, "octave" doesn't seem to be a trademark, octave is a GNU product, so it is proctected by the Free Software Foundation, which takes good care of copyrights (see http://www.gnu.org/prep/maintain/maintain.html : the FSF asks for a plain paper from each important contributor that gives his copyright to the FSF, as for each GNU software) * the R project (statistical language): GPL, no trademark, backed by the R foundation for general guidelines and the Free Software Foundation as it is a GNU project. The statutes of the R foundation are available here : http://www.r-project.org/foundation/Rfoundation-statutes.pdf * Maxima (computer algebra system) : GPL, no trademark ("maxima" is already the trademark of a fishing lines company), no organization behind. Maxima comes from DOE-Macsyma, written by the department of Energy (as far as I understand) and was officially donated to the community under the GPL. Here is the letter which proves it : http://maxima.sourceforge.net/misc/maxima-doe-auth.png * Pari/GP (computer algebra system) : GPL, no trademark, no foundation Was formally a proprietary project, and switched to the gpl. Here is a related entry in the FAQ : "Why use such a "restrictive" license as the GPL? Will you change it? The short answer to the second question is no. We are quite happy with the GPL. The original license (up to version 2.0) was proprietary, too casually worded, and lead to various conflicts. Starting from version 2.0, we wanted a well known license for the whole PARI/GP package, that would leave contributors secure with the future use of their code and, as far as possible, not prevent anyone from helping out. It was soon agreed that PARI/GP should become free software. The GPL was a natural choice. It is certainly well-known, and it satisfied every developer involved in the project, as well as their respective employers. For the latter, the alternatives would have been more restrictive, certainly not closer to the LGPL, BSD, or the Artistic license. Most free Computer Algebra Systems also use the GPL, presumably for related reasons." * Axiom (computer algebra system ) : BSD-style, no trademark ("axiom" is already the trademark of an automotive company), no foundation but the devs seem to think of it (see http://wiki.axiom-developer.org/AxiomFoundation , its role would be to promote axiom development). Axoim was an IBM software, then sold to "NAG", which stoped to sell it (not a financial success), and released it under a BSD-style license. * Ginac ( "ginac is not a computer algebra system") : GPL, no trademark, no organization * Scilab ( numerical computations ) : open source custom license described as non-free by the FSF, as it does not allow commercial distribution of the modified code. "Scilab" is a trademark, the Scilab Consortium controls its development. * Jacal (computer algebra system ) : GPL, no trademark, no organization * Boinc (distributed computing ) : LGPL, no trademark, copyright holder is the University of California And now other more general software : * the linux kernel : GPL, "linux" is a tradermark, a non-profit corporation is there to protect the trademark (http://www.linuxmark.org/), the rest is self-organized around Linus Torvalds * Gnome : LGPL (can be linked to proprietary code), "gnome" is a tradermark, the Gnome foundation is behind it * KDE : GPL (as Qt), "kde" is a tradermark, the KDE.e.v is a non-profit organization behind it (http://ev.kde.org/) * Xfce ( desktop environment ): GPL/LGPL/BSD depending on files, no trademark, no foundation * Xorg : original X11 license, very permissive, non-copyleft (ie allow to impose further restrictions on a distributed code), "xorg" doesn't seem to be a trademark, there is limited-liability-company, the Xorg foundation, that supervises the development * XFree86 : modified X11 license (gpl incompatible, that causes the fork), "xfree86" is a trademark, XFree86 Project Inc. is a company behind= it * firefox, thunderbird : MPL (gpl incompatible due to a few restrictions), "firefox", "thunderbird", "mozilla" are trademarks, protected by the Mozilla Foundation, a non-profit organization * wxWidgets : modified LGPL (more permissive), "wxWidgets" is not a trademark (they already changed from wxWindows due to trademark problems with Microsoft), there used to be a "wxWindows foundation", but it disappeared due to the lack of consensus and fears about copyrights that were given to the foundation (I quote http://www.wxwidgets.org/sf/ : "However, assignment was perceived by some to have serious disadvantages, such as the problem of what to do with the IP should the Foundation be dissolved." ) =3D=3D>That's interesting ! * FFmpeg ( audio/video toolkit ) : LGPL (+ GPL modules), "FFmpeg" is a trademark of the author of the project, no organization * amarok ( music player ): GPL, no trademark, copyright is protected by the KDEev as it is part of KDE * Stellarium ( planetarium ) : GPL, no trademark, no organization * Celestia ( space simulation ) : GPL, no trademark, no organization * Inkscape ( svg graphics ) : GPL, no trademark, no organization That's already a long list, although I must be forgetting important ones. The important points are : - some have a trademark, even individuals have (FFmpeg) - some don't have, and don't seem to suffer too much (Octave, Maxima, etc= .) - some have a legal organization behind them, which has often the role to 'supervise' development by defining global directions (R Foundation, Mozilla Foundation...), mostly to verify that copyrights and trademarks are respected (FSF, KDEev, Mozilla Foundation, Linuxmark...), sometimes to control all of the development process (Scilab) - some had an organization, but lost it as it was not that efficient (wxWidgets) ! - many are GPL or LGPL and seem to be fine with it ! - Interestingly enough, some projects come from proprietary products and became GPLed (Pari/GP - decision explained above, Maxima ) - the FSF has a strong policy regarding copyrights : it asks for signed paper for each important contributor - if we want to define a legal board of maintainers, we could have ideas from the R foundation (see statutes above) - if Thomas Williams was to accept a change in the license, we can have an idea of the corresponding paper for Maxima (see link above) What do I conclude ? We could be fine with the GPL. Even the linux kernel is GPLed, although I honestly find that it represents a lot more work as gnuplot ! So the GPL can protect gnuplot reliably. We could be fine without a trademark. It seems possible to protect the name 'gnuplot', but that's a different problem, and should probably be adressed after the license is. We can be fine without a legal organization. We can also define an organization that supervises the development, but taking complete control on releases for example would makes gnuplot look like Scilab which is still sometimes criticized for its almost closed development. What do you conclude ? Timoth=E9e |
|
From: Daniel J S. <dan...@ie...> - 2006-01-22 02:34:29
|
Timothée Lecomte wrote: >>>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. >> >> >>I'm not assuming that. International trademark looks to be $500 (it's >>in swiss currency) for ten years. Not unreasonable. But that's an >>aside. (Might make it easy though to recover www.gnuplot.com from >>that person who gobbled it up.) It's an aside. Different but not totally unrelated issue. >>Hence, why I propose that if a member of the group goes silent for a >>year, someone else is allowed to take over. If it gets to the point >>where there isn't a dozen or so people who could be a pool for just a >>few maintainers then nobody cares anymore. Or do a D. Knuth thing and >>freeze it for good. > > > Well, as we should probably not freeze it ;-), Twenty, thirty years from now? The project having evolved to the point of needing little maintenance? Who knows? Useful list below, thanks. Short comments within: > I have wondered how things go for other projects. Indeed, instead of > trying to resolve the gnuplot's license disadvantage ourselves, we can > get the inspiration from others (that's not copyrighted !). So I have > made a compilation of information on famous scientific open-source > software. Let's see : > > > * octave ( numerical computations): GPL, "octave" doesn't seem to be a > trademark, octave is a GNU product, so it is proctected by the Free > Software Foundation, which takes good care of copyrights (see > http://www.gnu.org/prep/maintain/maintain.html : the FSF asks for a > plain paper from each important contributor that gives his copyright to > the FSF, as for each GNU software) We could probably talk to John Eaton about more specifics if we wanted. By plain paper you mean something with signatures? (And notarized, I'd argue.) > > * the R project (statistical language): GPL, no trademark, backed by the > R foundation for general guidelines and the Free Software Foundation as > it is a GNU project. The statutes of the R foundation are available here > : http://www.r-project.org/foundation/Rfoundation-statutes.pdf > > * Maxima (computer algebra system) : GPL, no trademark ("maxima" is > already the trademark of a fishing lines company), Doesn't have any bearing on a software license as fishing equipment is unrelated to software. > no organization behind. > Maxima comes from DOE-Macsyma, written by the department of Energy (as > far as I understand) and was officially donated to the community under > the GPL. Not according to the letter. It apparently isn't GPL but says if the derivative work is GPL then Maxima's license must also accompany the GPL license. > Here is the letter which proves it : > http://maxima.sourceforge.net/misc/maxima-doe-auth.png Paperwork? > > * Pari/GP (computer algebra system) : GPL, no trademark, no foundation > Was formally a proprietary project, and switched to the gpl. Here is a > related entry in the FAQ : > "Why use such a "restrictive" license as the GPL? Will you change it? > > The short answer to the second question is no. > We are quite happy with the GPL. The original license (up to version > 2.0) was proprietary, too casually worded, and lead to various > conflicts. Starting from version 2.0, we wanted a well known license for > the whole PARI/GP package, that would leave contributors secure with the > future use of their code and, as far as possible, not prevent anyone > from helping out. It was soon agreed that PARI/GP should become free > software. > The GPL was a natural choice. It is certainly well-known, and it > satisfied every developer involved in the project, as well as their > respective employers. For the latter, the alternatives would have been > more restrictive, certainly not closer to the LGPL, BSD, or the Artistic > license. Most free Computer Algebra Systems also use the GPL, presumably > for related reasons." This Henri Cohen seems to be still active in development or directly oversees it, probably made the license transition that much easier. > > * Axiom (computer algebra system ) : BSD-style, no trademark ("axiom" is > already the trademark of an automotive company), Again, there can be multiple trademarks if the two companies are in unrelated fields. [snip] > * amarok ( music player ): GPL, no trademark, copyright is protected by > the KDEev as it is part of KDE Also the name of a Mike Oldfield album. :-) > That's already a long list, although I must be forgetting important > ones. The important points are : > - some have a trademark, even individuals have (FFmpeg) > - some don't have, and don't seem to suffer too much (Octave, Maxima, etc.) Trademark is for protecting the name, probably more for a business. But if some strange court case arises down the road where someone like Octave, Maxima, etc. loses the right to use the name, there'll be a mad scramble at the trademark office. > - some have a legal organization behind them, which has often the role > to 'supervise' development by defining global directions (R Foundation, > Mozilla Foundation...), mostly to verify that copyrights and trademarks > are respected (FSF, KDEev, Mozilla Foundation, Linuxmark...), sometimes > to control all of the development process (Scilab) > - some had an organization, but lost it as it was not that efficient > (wxWidgets) ! > - many are GPL or LGPL and seem to be fine with it ! > - Interestingly enough, some projects come from proprietary products and > became GPLed (Pari/GP - decision explained above, Maxima ) Pari/GP hardly seems to have originally been proprietary. Universities are slightly different than companies because of the where the money comes from. (Although, universities seem to be going more and more down that road as even the public schools become more and more private because state governments lessen and lessen support.) > - the FSF has a strong policy regarding copyrights : it asks for signed > paper for each important contributor > - if we want to define a legal board of maintainers, we could have ideas > from the R foundation (see statutes above) > - if Thomas Williams was to accept a change in the license, we can have > an idea of the corresponding paper for Maxima (see link above) > > > What do I conclude ? > > We could be fine with the GPL. Even the linux kernel is GPLed, although > I honestly find that it represents a lot more work as gnuplot ! So the > GPL can protect gnuplot reliably. > We could be fine without a trademark. It seems possible to protect the > name 'gnuplot', but that's a different problem, and should probably be > adressed after the license is. Agreed. > We can be fine without a legal organization. My vision is not that far, but others might disagree. > We can also define an > organization that supervises the development, but taking complete > control on releases for example would makes gnuplot look like Scilab > which is still sometimes criticized for its almost closed development. I'm thinking more a loosely legal agreement about the authority of maintainers. And it probably doesn't have so much to do with the license. But enough authority for stamp of approval release (no warranty!), but not enough to move development outside the intended path. > What do you conclude ? First, thanks again for the thorough summary. I need some time to think. Dan |
|
From: <tim...@en...> - 2006-01-22 10:13:50
|
Daniel J Sebald wrote: > Useful list below, thanks. Short comments within: > Timoth=E9e Lecomte wrote: > >> I have wondered how things go for other projects. Indeed, instead of >> trying to resolve the gnuplot's license disadvantage ourselves, we can >> get the inspiration from others (that's not copyrighted !). So I have >> made a compilation of information on famous scientific open-source >> software. Let's see : >> >> >> * octave ( numerical computations): GPL, "octave" doesn't seem to be a >> trademark, octave is a GNU product, so it is proctected by the Free >> Software Foundation, which takes good care of copyrights (see >> http://www.gnu.org/prep/maintain/maintain.html : the FSF asks for a >> plain paper from each important contributor that gives his copyright t= o >> the FSF, as for each GNU software) > > > We could probably talk to John Eaton about more specifics if we > wanted. By plain paper you mean something with signatures? (And > notarized, I'd argue.) With signatures, yes. Here is the relevant part of the link above : "If you maintain an FSF-copyrighted package certain legal procedures are required when incorporating legally significant changes written by other people. This ensures that the FSF has the legal right to distribute the package, and the standing to defend its GPL-covered status in court if necessary. Before incorporating significant changes, make sure that the person who wrote the changes has signed copyright papers and that the Free Software Foundation has received and signed them. We may also need a disclaimer from the person's employer." >> * Maxima (computer algebra system) : GPL, no trademark ("maxima" is >> already the trademark of a fishing lines company), > > > Doesn't have any bearing on a software license as fishing equipment is > unrelated to software. >> * Axiom (computer algebra system ) : BSD-style, no trademark ("axiom" = is >> already the trademark of an automotive company), > > > Again, there can be multiple trademarks if the two companies are in > unrelated fields. > > [snip] > >> * amarok ( music player ): GPL, no trademark, copyright is protected b= y >> the KDEev as it is part of KDE > > > Also the name of a Mike Oldfield album. :-) Ok, I didn't know that there can be multiple trademarks for different activities. > >> no organization behind. >> Maxima comes from DOE-Macsyma, written by the department of Energy (as >> far as I understand) and was officially donated to the community under >> the GPL. > > Not according to the letter. It apparently isn't GPL but says if the > derivative work is GPL then Maxima's license must also accompany the > GPL license. Indeed the letter doesn't say it has to be released under the GPL. I would say that it enumerates a list of conditions and says that Willam Shelter has the right to sublicense the modified code he wants to distribute. Derivated work stands here for the work done from the original copy that has been donated to him. He probably chose the gpl because it was compatible with the requirements of this letter. > >> Here is the letter which proves it : >> http://maxima.sourceforge.net/misc/maxima-doe-auth.png > > > Paperwork? Yes, paperwork... >> * Pari/GP (computer algebra system) : GPL, no trademark, no foundation >> Was formally a proprietary project, and switched to the gpl. Here is a >> related entry in the FAQ : >> "Why use such a "restrictive" license as the GPL? Will you change >> it? >> >> The short answer to the second question is no. >> We are quite happy with the GPL. The original license (up to versi= on >> 2.0) was proprietary, too casually worded, and lead to various >> conflicts. Starting from version 2.0, we wanted a well known license f= or >> the whole PARI/GP package, that would leave contributors secure with t= he >> future use of their code and, as far as possible, not prevent anyone >> from helping out. It was soon agreed that PARI/GP should become free >> software. >> The GPL was a natural choice. It is certainly well-known, and it >> satisfied every developer involved in the project, as well as their >> respective employers. For the latter, the alternatives would have been >> more restrictive, certainly not closer to the LGPL, BSD, or the Artist= ic >> license. Most free Computer Algebra Systems also use the GPL, presumab= ly >> for related reasons." > > > This Henri Cohen seems to be still active in development or directly > oversees it, probably made the license transition that much easier. Agreed. >> That's already a long list, although I must be forgetting important >> ones. The important points are : >> - some have a trademark, even individuals have (FFmpeg) >> - some don't have, and don't seem to suffer too much (Octave, Maxima, >> etc.) > > > Trademark is for protecting the name, probably more for a business.=20 > But if some strange court case arises down the road where someone like > Octave, Maxima, etc. loses the right to use the name, there'll be a > mad scramble at the trademark office. Agreed too. >> - Interestingly enough, some projects come from proprietary products a= nd >> became GPLed (Pari/GP - decision explained above, Maxima ) > > > Pari/GP hardly seems to have originally been proprietary.=20 > Universities are slightly different than companies because of the > where the money comes from. (Although, universities seem to be going > more and more down that road as even the public schools become more > and more private because state governments lessen and lessen support.) It's the author who said that the original license was proprietary... "The original license (up to version 2.0) was proprietary, too casually worded, and lead to various conflicts." >> We can be fine without a legal organization. > > > My vision is not that far, but others might disagree. > >> We can also define an >> organization that supervises the development, but taking complete >> control on releases for example would makes gnuplot look like Scilab >> which is still sometimes criticized for its almost closed development. > > > I'm thinking more a loosely legal agreement about the authority of > maintainers. And it probably doesn't have so much to do with the > license. But enough authority for stamp of approval release (no > warranty!), but not enough to move development outside the intended pat= h. So we would need to define cleanly how this group will work, but if it's properly done and functional, it's ok ! > >> What do you conclude ? > > > First, thanks again for the thorough summary. I need some time to thin= k. > > Dan You're welcome ! Timoth=E9e |
|
From: <tim...@en...> - 2006-01-22 10:16:03
|
Timoth=E9e Lecomte wrote: >Daniel J Sebald wrote: > > =20 > >>Timoth=E9e Lecomte wrote: >> >> =20 >> >>>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 not= e >>>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 f= or >>>gnuplot. >>> =20 >>> >>Why not? I know the common belief now days is that only "big" >>entities have or can afford rights, representation, etc. But the law >>isn't restricted to them. In fact, a lot of these legal concepts >>probably were originally intended to protect the individual. >> =20 >> > >Ok, it is possible, but personnaly I don't want > =20 > Wow, I realize that I have forgotten to finish my sentence. I meant to say that legal protections remain complicated to handle. But I agree with you, it's feasible. |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-01-22 02:05:28
|
On Saturday 21 January 2006 05:41 pm, Timoth=E9e Lecomte wrote: > - the FSF has a strong policy regarding copyrights : it asks for signed > paper for each important contributor The current front page for gnuplot document lists 23 contributors in addition to the two original copyright holders. =20 > What do you conclude ? I conclude that you would need on the order of 25 signatures to fully satisfy the FSF, if that is your goal. But that specific criterion would only be triggered if you were attempting to transfer copyright to the FSF, which is rather extreme. =20 =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: <tim...@en...> - 2006-01-22 10:20:36
|
Ethan A Merritt wrote: >On Saturday 21 January 2006 05:41 pm, Timoth=E9e Lecomte wrote: > =20 > >>- the FSF has a strong policy regarding copyrights : it asks for signed >>paper for each important contributor >> =20 >> >The current front page for gnuplot document lists 23 contributors >in addition to the two original copyright holders. > =20 > >>What do you conclude ? >> =20 >> >I conclude that you would need on the order of 25 signatures to >fully satisfy the FSF, if that is your goal. >But that specific criterion would only be triggered if you were >attempting to transfer copyright to the FSF, which is rather extreme. > =20 > It's not my goal, and I completely agree with the "extreme" adjective ! I just wanted to confirm what Daniel J Sebald explained about the necessity to have some legal proof if we want to do something to the current license, such as a written letter from Thomas Williams. |
|
From: Hans-Bernhard B. <br...@ph...> - 2006-01-23 15:08:50
|
Ethan A Merritt wrote: > I conclude that you would need on the order of 25 signatures to fully > satisfy the FSF, if that is your goal. But that specific criterion > would only be triggered if you were attempting to transfer copyright > to the FSF, which is rather extreme. You would need equally many signatures regardless of what kind of legal body you assign the copyright to. Whether that's the FSF, a to-be-founded gnuplot foundation, a single person, or something completely different; it doesn't change a thing. It's mostly straightforward application of copyright law that dictates this. Copyright have to be assigned explicitly, in writing, to be upheld in court. Some people here seem to assume that the FSF is making their version of such a process needlessly complicated, and that it must surely be possible to do it a lot easier than that. I doubt that. I don't believe any of us can out-lawyer Prof. Eben Moglen. Not even RMS, for that matter. Which leaves us with basically two options: * Don't wake a sleeping lion. I.e. keep on going like we've been doing ever since about the days of the pre-3.6 beta source tarballs, under the optimistic assumption that nobody will feel an urge to actually sue us. * Get ready to face the music. Sign over the copyrights to some legal body. Either to an existing institution, or an individual or to a foundation to be created for the purpose. Possible benefits of the latter approach would be that such an entity could properly join SF.net's project donation system to raise some funds, towards paying for stuff like DNS fees, registering a trademark and maybe getting back stolen domain names. |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-01-23 16:59:08
|
On Monday 23 January 2006 07:10 am, Hans-Bernhard Broeker wrote: > Ethan A Merritt wrote: > > I conclude that you would need on the order of 25 signatures to > > fully satisfy the FSF, if that is your goal. But that specific > > criterion would only be triggered if you were attempting to > > transfer copyright to the FSF, which is rather extreme. > > You would need equally many signatures regardless of what kind of > legal body you assign the copyright to. Maybe; I'm not sure. But I think the issue of copyright is sidetracking the main point under discussion. It is not necessary to transfer copyright in order to change a license. End users have access to the code, with certain restrictions, because of the license. The current holder of the copyright is not all that relevant if the license grants permanent rights to others. If ther code were relicensed following the model of GPL or BSD or Pine, development could continue even if the original copyright holders were to drop out of sight. What is true, however, is that in order to change the license we would have to get the explicit approval of Thomas, and it would certainly be safest to get explicit approval from as many other names on the list as possible. I point out again that individual contributors can make their contributions available under multiple licenses. Timoth=E9e, for example, can mark his wxWidgets code as being licensed under the GPL if he wishes. In this case he must *also* license it under gnuplot's current license (or possibly LGPL) in order for gnuplot to use it. But dual-licensing would allow 3rd parties to re-use the driver code in other projects regardless of the course of gnuplot development. > * Get ready to face the music. Sign over the copyrights to some > legal body. Either to an existing institution, or an individual or > to a foundation to be created for the purpose. You have left out the most expedient option, IMHO: 3) Leave the copyright as is, but change the license. =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Hans-Bernhard B. <br...@ph...> - 2006-01-25 15:17:30
|
Ethan Merritt wrote: > Only the license needs to persist. A permanent license remains valid > even if the original licensing body no longer exists. The problem is that AFAIK copyright falls under civil law, i.e. if somebody decided to violate the license after the copyright holder(s) have become terminally unavailable, there's nobody left who could sue them. A license without a legal body holding it would become unenforcable, and that cannot ever be a good thing. The more immediate problem with the gnuplot license as-is, is that after the copyright holders are gone, nobody can ever make an official release again. That's a "single point of failure" problem, and really needs to be addressed. The GPL addresses it by granting all licensees full distribution privileges, other license (you've mentioned PINE), by relying on an effectively immortal copyright holder. |
|
From: <tim...@en...> - 2006-02-07 18:11:26
|
Dear gnuplot developpers,
I have been very impressed by the overall enthusiasm last month about=20
the future of gnuplot (42 messages !). The discussion has been=20
constructive. Some time went by, and I think it would be interesting to=20
sum up the points of view, and probably ask to Thomas Williams what *he*=20
thinks of this.
So the main issue is that the current license drives gnuplot to a=20
"single point of failure", because releases rely on the agreement of=20
copyright holders, who will be gone one day.
The proposed solutions are, from the easier to the most radical :
* don't do anything, and wait to see gnuplot die in the more-or-less=20
long run
* change the license by contacting all copyright holders.
What license ? A license just permissive enough to make releases allowed=20
without relying on a fragile individual :
- a modified gnuplot license that names a legal body, a group of=20
people, like a foundation, which is allowed to make releases,
or
- gpl, because it is "standard", well-known, written by people aware=20
of the laws, or
or
- another appropriate license.
* transfer the copyrights to a legal body, existing or to be created,=20
immortal by design, which will be the group allowed to make releases,=20
but also to enforce the license if needed, and eventually to raise funds=20
or to register and enforce a trademark
All of the solutions that really handle gnuplot's future (all but the=20
first) are legally viable and imply a decision from the copyrights' holde=
rs.
Finally, one person has remained definitely silent for this discussion :=20
Thomas Williams. Lars, can you try to ask him for his position about the=20
license issue, as you proposed in one of your messages ?
Thank you very much for your consideration.
Best regards,
Timoth=E9e Lecomte
|
