Re: advice for free software package named almost identically to non-free software
Hi Paul, On Sun, Jun 11, 2017 at 10:19:16AM +0800, Paul Wise wrote: > On Sun, Jun 11, 2017 at 7:42 AM, Nicholas D Steeves wrote: > > > Do you think it's ok to internally provide backwards compatibility? > > eg, for a library, newname provides/fulfils oldname, for a long period > > of time...perhaps a year. I'm trying to think of all the non-Debian > > users who would also be affected by this change. > > That would be a decision for upstream but I guess it would probably be OK. I've given the upstream contact your email so he can write to you directly. Maybe I'm paranoid and overestimate the motivation and skills of litigious goons! Worst-case scenario being a google-tracked mailing list boosts the page-ranking of the almost-identically-named software and attracts the attention of those who would cause stress for others. Thank you for the advice, Nicholas signature.asc Description: Digital signature
Re: advice for free software package named almost identically to non-free software
Hi Ian,
On Mon, Jun 12, 2017 at 12:27:12PM +0100, Ian Jackson wrote:
> Nicholas D Steeves writes ("advice for free software package named almost
> identically to non-free software"):
> > An upstream has named their GPL software almost identically to a
> > proprietary piece of software. Both the free and the proprietary
> > software are developed in the U.S.A. The upstream has confirmed that
> > the name is not a registered trademark in the U.S.A, but the
> > proprietary software unambiguously precedes the free version; thus, if
> > ever there is a dispute, the developer of the first version has the
> > "prior art" argument on their side.
>
> Hi.
>
> I can't help feeling that this story is missing something. I don't
> disagree with anything Paul Wise has said, but:
I apologise for being so vague and cryptic...if this wasn't a
public and google-searcheable list I would have been much more
forthcoming. I'm not the upstream, btw! ;-)
> > The developer of the free software implementation has asked me if it
> > would be sufficient to ask permission from the author of the
> > proprietary developer to name his software similarly. If this is
> > acceptable, would you please provide a template I can send to the
> > author of the free implementation?
>
> In most situations I can imagine, the proprietary software author
> would be very unlikely to give permission. Indeed, I would expect
> them to object if they knew about it, so, contacting them to ask for
> it might well trigger the latent problem.
>
> If the free upstream suggests that they might ask for permission,
> presumably they have a different understanding of the proprietary
> authors' views. Perhaps they know (of) each other or have some other
> relationship that we're missing.
To the best of my knowledge they do not. In summary, when it occurred
to me that the naming could be an issue I contacted upstream, he asked
what is usually done in cases like these, I said I'd ask debian-legal.
The optimist in me expressed the sentiment that maybe asking for
permission from the proprietary software author would be sufficient,
but I qualified this with something along the lines of "please don't
contact him until I receive a reply from debian-legal as to if this is
a wise course of action".
> So, as far as the question actually asked I think Paul is right. But
> I have a strong feeling of "something odd going on here". It may be
> that if we knew more of the background, we could give better advice.
I've given the upstream contact your email so he can write to you
directly. Maybe I'm paranoid and overestimate the motivation and
skills of litigious goons!
Thank you
signature.asc
Description: Digital signature
Re: advice for free software package named almost identically to non-free software
On Fri, Jun 09, 2017 at 09:52:35AM +0800, Paul Wise wrote: > On Fri, Jun 9, 2017 at 6:29 AM, Nicholas D Steeves wrote: > > > An upstream has named their GPL software almost identically to a > > proprietary piece of software. > > I think it would be best to pro-actively rename the software now > rather than wait until renaming the software would be more painful. > Even if the proprietary software developer gives their permission, > they could always sell the software to someone else, who might not be > as forgiving of the naming similarity. That's a really good point, and something I hadn't considered! I've forwarded this to our upstream contact. Thank you, Nicholas signature.asc Description: Digital signature
Re: advice for free software package named almost identically to non-free software
Nicholas D Steeves writes ("advice for free software package named almost
identically to non-free software"):
> An upstream has named their GPL software almost identically to a
> proprietary piece of software. Both the free and the proprietary
> software are developed in the U.S.A. The upstream has confirmed that
> the name is not a registered trademark in the U.S.A, but the
> proprietary software unambiguously precedes the free version; thus, if
> ever there is a dispute, the developer of the first version has the
> "prior art" argument on their side.
Hi.
I can't help feeling that this story is missing something. I don't
disagree with anything Paul Wise has said, but:
> The developer of the free software implementation has asked me if it
> would be sufficient to ask permission from the author of the
> proprietary developer to name his software similarly. If this is
> acceptable, would you please provide a template I can send to the
> author of the free implementation?
In most situations I can imagine, the proprietary software author
would be very unlikely to give permission. Indeed, I would expect
them to object if they knew about it, so, contacting them to ask for
it might well trigger the latent problem.
If the free upstream suggests that they might ask for permission,
presumably they have a different understanding of the proprietary
authors' views. Perhaps they know (of) each other or have some other
relationship that we're missing.
So, as far as the question actually asked I think Paul is right. But
I have a strong feeling of "something odd going on here". It may be
that if we knew more of the background, we could give better advice.
Regards,
Ian.
Re: advice for free software package named almost identically to non-free software
On Sun, Jun 11, 2017 at 7:42 AM, Nicholas D Steeves wrote: > Do you think it's ok to internally provide backwards compatibility? > eg, for a library, newname provides/fulfils oldname, for a long period > of time...perhaps a year. I'm trying to think of all the non-Debian > users who would also be affected by this change. That would be a decision for upstream but I guess it would probably be OK. -- bye, pabs https://wiki.debian.org/PaulWise
Re: advice for free software package named almost identically to non-free software
On Fri, Jun 09, 2017 at 09:52:35AM +0800, Paul Wise wrote: > On Fri, Jun 9, 2017 at 6:29 AM, Nicholas D Steeves wrote: > > > An upstream has named their GPL software almost identically to a > > proprietary piece of software. > > I think it would be best to pro-actively rename the software now > rather than wait until renaming the software would be more painful. > Even if the proprietary software developer gives their permission, > they could always sell the software to someone else, who might not be > as forgiving of the naming similarity. Do you think it's ok to internally provide backwards compatibility? eg, for a library, newname provides/fulfils oldname, for a long period of time...perhaps a year. I'm trying to think of all the non-Debian users who would also be affected by this change. Thank you for help and the feedback! Nicholas signature.asc Description: Digital signature
Re: advice for free software package named almost identically to non-free software
On Fri, Jun 9, 2017 at 6:29 AM, Nicholas D Steeves wrote: > An upstream has named their GPL software almost identically to a > proprietary piece of software. I think it would be best to pro-actively rename the software now rather than wait until renaming the software would be more painful. Even if the proprietary software developer gives their permission, they could always sell the software to someone else, who might not be as forgiving of the naming similarity. -- bye, pabs https://wiki.debian.org/PaulWise
Re: How to free US governmental code
On Mon, Jun 29, 2015 at 06:07:52PM -0400, James Cloos wrote: WL == Walter Landry wlan...@caltech.edu writes: WL I found something here WL ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change WL I do not think it applies in this case. WL Cheers, WL Walter Landry Thanks for finding that. That is certainly limited to BSD. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6 US Government code authored by US Govt. employees is one of the few things that remains public domain _in the US_ Here, you have code written by contractors for the US government. Is there a contact for LANL anywhere ? - if you ask LANL themselves, they may be able to establish who owns the code now and how to free it up appropriately. They will have access to corporate policies / lawyers etc. for their situation and can get permission to give permission. All the best, AndyC -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m3egku88xz@carbon.jhcloos.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150630131511.ga2...@galactic.demon.co.uk
Re: How to free US governmental code
Ole Streicher oleb...@debian.org wrote: Hi, In one of the packages I am currently working on (idlastro [1]), some files have the following license [2]: | Copyright 1992, The Regents of the University of California. This | software was produced under U.S. Government contract (W-7405-ENG-36) | by Los Alamos National Laboratory, which is operated by the University | of California for the U.S. Department of Energy. The U.S. Government | is licensed to use, reproduce, and distribute this software. Neither | the Government nor the University makes any warranty, express or | implied, or assumes any liability or responsibility for the use of | this software. Surely, this makes the code non-free. However, I have no idea whom to ask to change to license to something DFGS-compatible. What are the experiences with this kind of copyright: are there any chances to make it free? Looking around the ftp site http://idlastro.gsfc.nasa.gov/ftp/ there is a top level file LICENSE dated 2014 that looks like a simple BSD license for Wayne Landsman. Since Wayne is also listed as a contributor to eqpole_grid.pro, he should be sympathetic to relicensing. A Google search for Wayne Landsman Astronomy turns up a likely contact at GSFC. You should ask Wayne directly. He would then contact the legal department at UC, though that would involve some work on his end. Also, are you planning on distributing http://idlastro.gsfc.nasa.gov/ftp/pro/misc/blkshift.pro That and a few other files have a non-commercial use license. Cheers, Walter Landry -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150629.070201.414466700400025959.wlan...@caltech.edu
Re: How to free US governmental code
In one of the packages I am currently working on (idlastro [1]), some files have the following license [2]: | Copyright 1992, The Regents of the University of California. This | software was produced under U.S. Government contract (W-7405-ENG-36) | by Los Alamos National Laboratory, which is operated by the University | of California for the U.S. Department of Energy. The U.S. Government | is licensed to use, reproduce, and distribute this software. Neither | the Government nor the University makes any warranty, express or | implied, or assumes any liability or responsibility for the use of | this software. Surely, this makes the code non-free. However, I have no idea whom to ask to change to license to something DFGS-compatible. I'm inclined to agree with you. Works that the U.S. Government contracts for are sadly not public domain. What are the experiences with this kind of copyright: are there any chances to make it free? You'd have to contact The Regents of the University of California, since they own the copyright. Or, perhaps, you might have more luck asking the program's author, who can ask the University on your behalf. pgpcNsKzlSkEf.pgp Description: PGP signature
Re: How to free US governmental code
Walter Landry wlan...@caltech.edu writes: Ole Streicher oleb...@debian.org wrote: | Copyright 1992, The Regents of the University of California. This | software was produced under U.S. Government contract (W-7405-ENG-36) | by Los Alamos National Laboratory, which is operated by the University | of California for the U.S. Department of Energy. The U.S. Government | is licensed to use, reproduce, and distribute this software. Neither | the Government nor the University makes any warranty, express or | implied, or assumes any liability or responsibility for the use of | this software. What are the experiences with this kind of copyright: are there any chances to make it free? Looking around the ftp site http://idlastro.gsfc.nasa.gov/ftp/ there is a top level file LICENSE dated 2014 that looks like a simple BSD license for Wayne Landsman. As far as I understand the history of idlastro, Wayne collected parts of the lib from other sources, and I am afraid that he did not really take care of the individual license of each file he touched and included. Otherwise he probably would have changed the license statement to BSD. Since Wayne is also listed as a contributor to eqpole_grid.pro, he should be sympathetic to relicensing. A Google search for Wayne Landsman Astronomy turns up a likely contact at GSFC. You should ask Wayne directly. He would then contact the legal department at UC, though that would involve some work on his end. I asked him, and I also found the (probable) original author and contacted him. Also, are you planning on distributing http://idlastro.gsfc.nasa.gov/ftp/pro/misc/blkshift.pro That and a few other files have a non-commercial use license. Yes, but they look much less formal -- One author made already parts of his software free (mpfit: under a non-standard ISC-alike license), and the other already responded that he will help me to get his sources free. The license above was just the one where I didn't know what to do best. Best regards Ole -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ytz7fqmk3dl@news.ole.ath.cx
Re: How to free US governmental code
OS == Ole Streicher oleb...@debian.org writes: OS In one of the packages I am currently working on (idlastro [1]), some OS files have the following license [2]: OS | Copyright 1992, The Regents of the University of California. ... Since the copyright is The Regents of the University of California, one wonders whether the their relicensing statement, where they dropped the 4th clause retoactively, covers this, too. I can't find the instance of that statement which I saved, nor via goog, so I cannot be sure whether it limited the relicensing to software which was released under the original BSD license, or coverred all software copyrighted by the Regents. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6 -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m3pp4e8koy@carbon.jhcloos.org
Re: How to free US governmental code
James Cloos cl...@jhcloos.com wrote: OS == Ole Streicher oleb...@debian.org writes: OS In one of the packages I am currently working on (idlastro [1]), some OS files have the following license [2]: OS | Copyright 1992, The Regents of the University of California. ... Since the copyright is The Regents of the University of California, one wonders whether the their relicensing statement, where they dropped the 4th clause retoactively, covers this, too. I can't find the instance of that statement which I saved, nor via goog, so I cannot be sure whether it limited the relicensing to software which was released under the original BSD license, or coverred all software copyrighted by the Regents. I found something here ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change I do not think it applies in this case. Cheers, Walter Landry -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150629.110515.1437842410455001293.wlan...@caltech.edu
Re: How to free US governmental code
WL == Walter Landry wlan...@caltech.edu writes: WL I found something here WL ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change WL I do not think it applies in this case. WL Cheers, WL Walter Landry Thanks for finding that. That is certainly limited to BSD. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6 -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m3egku88xz@carbon.jhcloos.org
Re: Joke non-free clauses?
On Tue, 13 Apr 2010 08:42:22 +0800 Shan-Bin Chen (DreamerC) dreamerwolf...@gmail.com wrote: They forked a new version from 0.9.2 , and the library in Debian is 0.9.3 . I think the problem that could be solved between versions. Because the authors in deadbeef want to release with GPL and LGPL Version 2, I'm seriously concerned about this joke. What kind license could they use in '0.9.3'? is BSD ok? or GPL? See: http://dumb.sourceforge.net/index.php?page=licences As I understand it, the addition of Clause 8 should have solved this problem, and they should be able to go ahead and use 0.9.3. Please let me know if this is not the case. I forget precisely what the problem was. It's something about DUMB's licence placing restrictions that the GPL forbids, but that doesn't quite make sense to me since the restrictions are only on DUMB which is not licensed under the GPL. If anyone would be kind enough to clarify for me, it would be much appreciated :) I should also like to apologise if I have offended anyone, either with the licence itself or during any discussion of the licence that has taken place. It was never my intention to cause any problems. I hope everyone can take the jokes in the spirit they were intended. After all, this must be one of the more interesting problems you guys have had to solve, and I hope I have brought some comic relief to the job. :) The non-joke parts of DUMB's licence are copied almost verbatim from zlib's licence, incidentally. Ben :) -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100413231449.07c22...@kurumi
Re: Joke non-free clauses?
Some points: Jokes are great, but licenses are not the place to make them. Come to DebConf and make them over conversation and $BEVERAGE instead. License proliferation is bad, license standardisation/consolidation is good! The DUMB license is extremely far from clear. License clarity is extremely important to ensure that people's understanding of the license is on common ground. Just witness the various debates over the years about the GPL, linking and derivative works. I'm sure there are many examples of unclear licenses that people steer clear of too. Clause 8 specifically mentions Debian, which may or may not mean that the license clashes with DFSG 8 (and possibly 5 7). http://www.debian.org/social_contract Perhaps you would be willing to revert to the verbatim zlib license? Clauses 4, 5 and 6 may as well not exist since they are invalidated by clause 8. Clause 8 only exists to invalidate clauses 4, 5 and 6. So, clauses 4, 5, 6 and 8 don't need to exist. The only purpose of clauses 4, 5, 6 and 8 are thus to cause confusion and/or humor. I would argue that neither of these has any place in a license and you should thus switch to a standard license (like the zlib license) -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/o2we13a36b31004131923s60149907t568dfaa7bd8ae...@mail.gmail.com
Re: Joke non-free clauses?
Hi, 2010/4/9 Paul Wise p...@debian.org: libdumb is already in Debian: http://packages.debian.org/libdumb It woulud be nice if you could switch to a more standard license instead of inventing your own. I'd recommend one of BSD, ISC, MIT/Expat, LGPL, GPL. http://packages.debian.org/changelogs/pool/main/libd/libdumb/current/copyright Thank you, point out the problem. 2010/4/9 Ben Davis ent...@users.sf.net: Could you clarify: is there a problem with DUMB v0.9.3, or is it that DUMB v0.9.2 is non-free and the notice resolving the situation for 0.9.2 no longer remains? They forked a new version from 0.9.2 , and the library in Debian is 0.9.3 . I think the problem that could be solved between versions. Because the authors in deadbeef want to release with GPL and LGPL Version 2, I'm seriously concerned about this joke. What kind license could they use in '0.9.3'? is BSD ok? or GPL? regards, -- Shan-Bin Chen (DreamerC) dreamerwolf...@gmail.com -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/g2n1c35ace01004121742t19da4ee3v68878934390ff...@mail.gmail.com
Re: Joke non-free clauses?
Hi, recently I try to package deadbeef [1] into Debian and Ubuntu, but it includes the libdumb (0.9.2). It seems that the libdumb has a license issue which blocked the upload. We need to clear the license issue, and make sure that everyone agree. [1] http://deadbeef.sourceforge.net/ an audio player , src : git://github.com/dreamerc/deadbeef-debian.git regards, -- Shan-Bin Chen (DreamerC) dreamerwolf...@gmail.com -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/u2h1c35ace01004080832nc23fb08fmde62df015dcd7...@mail.gmail.com
Re: Joke non-free clauses?
Hi, You mention DUMB v0.9.2, whereas the latest version is 0.9.3. Is this intentional on the part of the 'deadbeef' package? When DUMB v0.9.2 was the latest version and the problem was first brought to my attention, I put a notice on the website stating that Point 4 of the licence was renounced. For DUMB v0.9.3, I removed the notice, because the new licence had further points in it, one of which was meant to prevent the licence from being non-free. It turns out I didn't do a very good job of being legally clear! There is now a notice on the website about a further clause in DUMB v0.9.3 which I believe is legally clear but still hopefully some fun. I was informed that it was sufficient to make DUMB suitable for inclusion in the free repository. Could you clarify: is there a problem with DUMB v0.9.3, or is it that DUMB v0.9.2 is non-free and the notice resolving the situation for 0.9.2 no longer remains? Thanks, Ben :) On Thu, 8 Apr 2010 23:32:36 +0800 Shan-Bin Chen (DreamerC) dreamerwolf...@gmail.com wrote: Hi, recently I try to package deadbeef [1] into Debian and Ubuntu, but it includes the libdumb (0.9.2). It seems that the libdumb has a license issue which blocked the upload. We need to clear the license issue, and make sure that everyone agree. [1] http://deadbeef.sourceforge.net/ an audio player , src : git://github.com/dreamerc/deadbeef-debian.git regards, -- Shan-Bin Chen (DreamerC) dreamerwolf...@gmail.com -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100408232517.2f1d8...@kurumi
Re: Joke non-free clauses?
Francesco Poli f...@firenze.linux.it (24/02/2010): Or maybe they are jokes that look like non-free clauses, I am not sure which one makes more sense or better describes the situation... Looks like upstream clarified the “joke status”? http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=18;bug=533555 Mraw, KiBi. signature.asc Description: Digital signature
Re: Joke non-free clauses?
reopen 533555 thanks On Wed, 24 Feb 2010, Cyril Brulebois wrote: Francesco Poli f...@firenze.linux.it (24/02/2010): Or maybe they are jokes that look like non-free clauses, I am not sure which one makes more sense or better describes the situation... Looks like upstream clarified the “joke status”? http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=18;bug=533555 There's no indication that thatcadguy is actually upstream. [At least, thatcadguy isn't listed as a Developer that I could see on SF in a few minutes of checking.] The meaning of clause 6 is rather difficult to parse and basically a complete lawyerbomb. Humor is fine, but humor in licenses with possible legal consequences isn't really something we should be distributing in main or contrib. If the real maintainers can actually be contacted by mail and get a binding response that clauses 4-6 are jokes, and promise to remove or make them clearly requests in future releases, I think that'd be sufficient. Don Armstrong -- Our days are precious, but we gladly see them going If in their place we find a thing more precious growing A rare, exotic plant, our gardener's heart delighting A child whom we are teaching, a booklet we are writing -- Frederick Rükert _Wisdom of the Brahmans_ [Hermann Hesse _Glass Bead Game_] http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2010022419.gv28...@volo.donarmstrong.com
Re: Joke non-free clauses?
tag 533555 patch retitle 533555 Clauses 4-6 can be ignored by a new clause 8; clarify copyright file summary -1 533555 severity 533555 minor thanks On Wed, 24 Feb 2010, Don Armstrong wrote: If the real maintainers can actually be contacted by mail and get a binding response that clauses 4-6 are jokes, and promise to remove or make them clearly requests in future releases, I think that'd be sufficient. After a series of e-mails with the upstream maintainer, I've gotten clarification that clauses 4-6 are meant to be jokes via the addition of a new clause 8: http://dumb.sourceforge.net/index.php?page=licences [There isn't a clause 7.] I'm personally still not happy with the license, but that's because it's not sane, not because the intent is to make it fail the DFSG. [I don't have an opinion about whether Debian continues to distribute DUMB.] Don Armstrong -- Leukocyte... I am your father. -- R. Stevens http://www.dieselsweeties.com/archive.php?s=1546 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100225072709.ge28...@volo.donarmstrong.com
Re: GNU Simpler Free Documentation License: discussion draft
On Mon, 25 Aug 2008 12:51:25 +1000 Ben Finney wrote: Francesco Poli [EMAIL PROTECTED] writes: On Sun, 24 Aug 2008 16:05:44 +1000 Ben Finney wrote: [...] The FSF has a draft license named the Simpler Free Documentation License URL:http://gplv3.fsf.org/doclic-dd1-guide.html; that page says that the SFDL was published in draft form on 2006-09-26. And was analyzed by me on debian-legal back on 2006-12-08: http://lists.debian.org/debian-legal/2006/12/msg00124.html Yes, I recall that (and thank you again for this good analysis). You're welcome! [...] So far, I can not see *any* comments at that document URL:http://gplv3.fsf.org/comments/gsfdl-draft-1.html. […] Wait, I sent 20 comments. Do you see them at the URL above? I don't (in my Javascript-enabled browser). Actually, I don't either... [...] I worry that discussion will be greatly discouraged if comments, once made, are essentially invisible to newcomers. That worry isn't for this forum to address, though. The FSF public consultation system has already been criticized from an accessibility/usability standpoint... -- http://frx.netsons.org/doc/index.html#nanodocs The nano-document series is here! . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgptFr1AcFhLX.pgp Description: PGP signature
Re: GNU Simpler Free Documentation License: discussion draft
On Sun, 24 Aug 2008 16:05:44 +1000 Ben Finney wrote: Howdy all, Hi! [...] The FSF has a draft license named the Simpler Free Documentation License URL:http://gplv3.fsf.org/doclic-dd1-guide.html; that page says that the SFDL was published in draft form on 2006-09-26. And was analyzed by me on debian-legal back on 2006-12-08: http://lists.debian.org/debian-legal/2006/12/msg00124.html [...] So far, I can not see *any* comments at that document's URL. The released version of the FDL has attracted a litany of well-reasoned criticisms, many of them relating to freedom-related problems with the license terms; has anyone used the above discussion draft interface for the draft SFDL to comment on whether those criticisms also apply to this license? Wait, I sent 20 comments. Here they are (no need to login, or to enable a Javascript interpreter to see them): http://gplv3.fsf.org/comments/rt/readsay.html?Query=%20Creator%20=%20%27frx%27%20%20AND%20%27CF.NoteUrl%27%20LIKE%20%27gsfdl-draft-1%27%20Rows=50 If you want to see my comments on the draft text, use the following URL (needs Javascript): http://gplv3.fsf.org/comments/gsfdl-draft-1.html?Query=%20Creator%20=%20%27frx%27%20%20AND%20%27CF.NoteUrl%27%20LIKE%20%27gsfdl-draft-1%27%20Order=DESCOrderBy=idRows=50 Other people sent their comments, as well. Currently, I can see 178 of them (no need to login or to enable Javascript): http://gplv3.fsf.org/comments/rt/readsay.html?Query=%20%27CF.NoteUrl%27%20LIKE%20%27gsfdl-draft-1%27%20Order=DESCOrderBy=idRows= I hope this helps. -- http://frx.netsons.org/doc/index.html#nanodocs The nano-document series is here! . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpINuDVBNPM5.pgp Description: PGP signature
Re: GNU Simpler Free Documentation License: discussion draft
Francesco Poli [EMAIL PROTECTED] writes: On Sun, 24 Aug 2008 16:05:44 +1000 Ben Finney wrote: [...] The FSF has a draft license named the Simpler Free Documentation License URL:http://gplv3.fsf.org/doclic-dd1-guide.html; that page says that the SFDL was published in draft form on 2006-09-26. And was analyzed by me on debian-legal back on 2006-12-08: http://lists.debian.org/debian-legal/2006/12/msg00124.html Yes, I recall that (and thank you again for this good analysis). [...] So far, I can not see *any* comments at that document URL:http://gplv3.fsf.org/comments/gsfdl-draft-1.html. […] Wait, I sent 20 comments. Do you see them at the URL above? I don't (in my Javascript-enabled browser). Here they are (no need to login, or to enable a Javascript interpreter to see them): http://gplv3.fsf.org/comments/rt/readsay.html?Query=%20Creator%20=%20%27frx%27%20%20AND%20%27CF.NoteUrl%27%20LIKE%20%27gsfdl-draft-1%27%20Rows=50 If you want to see my comments on the draft text, use the following URL (needs Javascript): http://gplv3.fsf.org/comments/gsfdl-draft-1.html?Query=%20Creator%20=%20%27frx%27%20%20AND%20%27CF.NoteUrl%27%20LIKE%20%27gsfdl-draft-1%27%20Order=DESCOrderBy=idRows=50 Other people sent their comments, as well. Currently, I can see 178 of them (no need to login or to enable Javascript): http://gplv3.fsf.org/comments/rt/readsay.html?Query=%20%27CF.NoteUrl%27%20LIKE%20%27gsfdl-draft-1%27%20Order=DESCOrderBy=idRows= Yes, I see them at those URLs just fine. Yet, at the plain URL (without query parameters) of the same document URL:http://gplv3.fsf.org/comments/gsfdl-draft-1.html shows no comments. Despite the fact that it gives the same comments are highlighted in these colours introduction at the top. How on earth is someone supposed to conclude that there are any comments at all? The impression I get from the (no query parameters) document is that comments *would* be highlighted if there were any, but currently there are none. The page does nothing to dispel that impression. I worry that discussion will be greatly discouraged if comments, once made, are essentially invisible to newcomers. That worry isn't for this forum to address, though. -- \ “People demand freedom of speech to make up for the freedom of | `\ thought which they avoid.” —Soren Aabye Kierkegaard (1813-1855) | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat's Free fonts
Christian Perrier wrote: (-legal CC'ed with Alan's agreement) Quoting Alan Baghumian ([EMAIL PROTECTED]): Hi, I've sent an email to Bryan (CCed you) and he told me he will forward it to Red Hat staff, but still no response. May we try to upload it and see what FTP master will decide or you prefer to forget it? I re-read the debian-legal thread. The conclusion seems pretty clear to me: the license is invalid and we should therefore consider that we have no license at all. As a consequence, the only conclusion is to avoid uploading. At least, this is my advice. Someone else may think differently and upload, leaving the decision to the ftpmaster(s). I would also suggest waiting before packaging and uploading. Thankfully it looks like the RedHat decision-makers and the Fedora contributors are willing to look at the problems with the upstream tarball and its licensing: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239884 http://www.linux.com/article.pl?sid=07/05/16/1318240 https://www.redhat.com/archives/fedora-marketing-list/2007-May/msg00025.html A discussion is going on to suggest better ways of providing these fonts to the community and making Liberation a collaborative project. -- Nicolas Spalinger http://scripts.sil.org http://alioth.debian.org/projects/pkg-fonts/ https://launchpad.net/~fonts signature.asc Description: OpenPGP digital signature
Re: Red Hat's Free fonts
(-legal CC'ed with Alan's agreement) Quoting Alan Baghumian ([EMAIL PROTECTED]): Hi, I've sent an email to Bryan (CCed you) and he told me he will forward it to Red Hat staff, but still no response. May we try to upload it and see what FTP master will decide or you prefer to forget it? I re-read the debian-legal thread. The conclusion seems pretty clear to me: the license is invalid and we should therefore consider that we have no license at all. As a consequence, the only conclusion is to avoid uploading. At least, this is my advice. Someone else may think differently and upload, leaving the decision to the ftpmaster(s). signature.asc Description: Digital signature
Re: RFH: Non-free files in Emacs
After cautiously reading you message, here are my intends about the listed files. Please correct me if you think I'm wrong. [CRUFT] Remove from any package [NON-FREE] Move to non-free [MAIN] Keep in main [EMAIL PROTECTED] (Nathanael Nerode) writes: Files in the /etc directory of emacs21 which may be legally problematic follow. If you can't stand to read this all, the brief summary: * As well as the ones you spotted before, DISTRIB, GNU, MOTIVATION, and gfdl.1 are non-free. * There are a lot of files without any copyright or licensing information, and upstream probably will want to fix this. I would remove a lot of these even if they turn out to be free, as much of it is useless cruft. ObLicense: I hereby give permission to forward this message or any part of it (verbatim) to anyone who you think might find it useful. - First, an oddity: e/eterm -- binary included in the source tarball! Debian's general policy is to rebuild such things. [CRUFT] Has to be rebuilt from e/eterm.ti -- Second, files with explicit license notices which aren't standard free licenses, apart from the non-free files you already identified (The ones you already identifed are CENSORSHIP [NON-FREE] or [CRUFT] Shall we ever bother shiping unrelated essays? copying.paper [NON-FREE] INTERVIEW [NON-FREE] or [CRUFT] Shall we ever bother shiping unrelated essays? LINUX-GNU [NON-FREE] THE-GNU-PROJECT [NON-FREE] WHY-FREE). [NON-FREE] It deals with software freedom, so maybe not [CRUFT] COPYING -- Non-free (verbatim only), but we make an exception for it because it's the license for the program. [MAIN] DEBUG -- old GNU documentation license (unique copyleft). Free. [MAIN] DISTRIB -- Non-free. No explicit permission to make modified copies (verbatim only). [NON-FREE] GNU -- Non-free. Modified copies may not be made. [NON-FREE] MOTIVATION -- Non-free. Reprinted with permission, no permission to modify. [NON-FREE] or [CRUFT] This text is not related to Emacs, shall we really keep it? OTHER.EMACSES -- old GNU documentation license (unique copyleft). Free. [MAIN] TUTORIAL and TUTORIAL.* -- old GNU documentation license (unique copyleft). Free. [MAIN] emacstool.1 -- GFDL-licensed without Invariant Sections, Front-Cover Texts, or Back-Cover Texts -- so considered acceptable. However, it's also irrelevant to Debian, since it's suntools-specific, so remove it, just so you don't have to worry about it any more. [CRUFT] gfdl.1 -- Licensed for distribution, but obviously this is a non-free document (changing it is not allowed). We would make an exception for it if it were the license for any part of the package. If all the GFDL documentation is removed, it must be removed too. [NON-FREE] termcap.src [CRUFT] ... BABYL [MAIN] It describes a file format used by rmail or Gnus COOKIES -- anonymous authorship [CRUFT] FTP -- almost certainly too short to have a copyright [MAIN] where to get information about how to download Emacs through FTP HELLO -- almost certainly not copyrightable [MAIN] JOKES -- This consists of a bunch of different people's email messages, apparently without permission to reproduce forever [CRUFT] LEDIT -- email message from the person contributing ledit.l. Of course, copyright and licensing is never discussed [CRUFT] LPF -- does the organization even exist anymore? [CRUFT] MACHINES [CRUFT] MAILINGLISTS -- Last updated 1999 emacs seems to be the home of cruft. [MAIN] Informative about how to reach emacs lists? MH-E-NEWS [MAIN] still used upstream since mh-e incorporated into Emacs MH-E-ONEWS [CRUFT] Removed upstream MORE.STUFF [MAIN] describes available external packages for Emacs Makefile [MAIN] used to build e/eterm ORDERS [MAIN] ORDERS.EUROPE -- Don't the upstream emacs maintainers ever clean anything up? This is pretty obsolete. ORDERS.JAPAN -- see ORDERS.EUROPE [CRUFT] Both removed upstream PROBLEMS [MAIN] README [MAIN] SERVICE [MAIN] or [CRUFT] Where to get help about emacs? TERMS [MAIN] TODO [MAIN] Xkeymap.txt [MAIN] celibacy.1 [CRUFT] condom.1 [CRUFT] -- Post-1988 (1992). e/eterm.ti -- Not copyrightable, as a collection of facts about eterm. [MAIN] echo.msg -- Released 1985 in US without copyright notice, so public domain. [CRUFT] emacs.bash -- By Noah Friedman. [MAIN] might be usefull. Noah probably assigned his copyright to the FSF emacs.csh -- By Michael DeCorte. [MAIN] Likewise. enriched.doc [MAIN] text sample of emacs editing capabilities future-bug -- Email message by Karl Fogel [EMAIL PROTECTED]. [CRUFT] ledit.l [CRUFT] ms-78kermit -- Post-1988 (1989). Author Andy Lowry. [MAIN] or [CRUFT] terminals settings ms-kermit -- Post-1988 (1990). Author Robert Earl ([EMAIL PROTECTED]) [MAIN] or [CRUFT] terminals
Re: RFH: Non-free files in Emacs
Jérôme Marant wrote: After cautiously reading you message, here are my intends about the listed files. Please correct me if you think I'm wrong. [CRUFT] Remove from any package [NON-FREE] Move to non-free [MAIN] Keep in main I agree with all of these, except: [EMAIL PROTECTED] (Nathanael Nerode) writes: [...] COPYING -- Non-free (verbatim only), but we make an exception for it because it's the license for the program. [MAIN] [CRUFT]; packages should not include copies of the GPL, but should instead refer to /usr/share/common-licenses/GPL. yow.lines -- large numbers of quotations from Bill Griffith's Zippy comics, without permission. There are so damn many of them that it worries me. (Unlike the other lists, which don't consist entirely of work by one author.) I'd remove it. Any other people want to weigh in? [CRUFT] Emacs actually does use this; M-x yow and M-x psychoanalyze-pinhead draw Zippy quotes from this file. That doesn't necessarily change the freeness status of it (though the quotes may still fall under fair use or similar), but it probably changes it to [NON-FREE] at least. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: RFH: Non-free files in Emacs
[EMAIL PROTECTED] (Nathanael Nerode) writes: Files in the /etc directory of emacs21 which may be legally problematic follow. Thank you very much. This is an impressive piece of work. I'll take some time to read it cautiously and come back if any question. Cheers, -- Jérôme Marant
Re: RFH: Non-free files in Emacs
Files in the /etc directory of emacs21 which may be legally problematic follow. If you can't stand to read this all, the brief summary: * As well as the ones you spotted before, DISTRIB, GNU, MOTIVATION, and gfdl.1 are non-free. * There are a lot of files without any copyright or licensing information, and upstream probably will want to fix this. I would remove a lot of these even if they turn out to be free, as much of it is useless cruft. ObLicense: I hereby give permission to forward this message or any part of it (verbatim) to anyone who you think might find it useful. - First, an oddity: e/eterm -- binary included in the source tarball! Debian's general policy is to rebuild such things. -- Second, files with explicit license notices which aren't standard free licenses, apart from the non-free files you already identified (The ones you already identifed are CENSORSHIP,copying.paper,INTERVIEW,LINUX-GNU,THE-GNU-PROJECT,WHY-FREE). COPYING -- Non-free (verbatim only), but we make an exception for it because it's the license for the program. DEBUG -- old GNU documentation license (unique copyleft). Free. DISTRIB -- Non-free. No explicit permission to make modified copies (verbatim only). GNU -- Non-free. Modified copies may not be made. MOTIVATION -- Non-free. Reprinted with permission, no permission to modify. OTHER.EMACSES -- old GNU documentation license (unique copyleft). Free. TUTORIAL and TUTORIAL.* -- old GNU documentation license (unique copyleft). Free. emacstool.1 -- GFDL-licensed without Invariant Sections, Front-Cover Texts, or Back-Cover Texts -- so considered acceptable. However, it's also irrelevant to Debian, since it's suntools-specific, so remove it, just so you don't have to worry about it any more. gfdl.1 -- Licensed for distribution, but obviously this is a non-free document (changing it is not allowed). We would make an exception for it if it were the license for any part of the package. If all the GFDL documentation is removed, it must be removed too. termcap.src -- Mostly unlikely to be copyrightable: it's mostly a collection of facts. But it does contain some extremely substantial comment text, which probably *is* covered by copyright, thanks to the Berne Convention, which you may have figured out I am not at all fond of. The material in the oldest versions was BSD-licensed; the material in the most recent version is fairly explicitly made public domain (belongs to no one and everyone). Unfortunately it's a mishmash of contributions by lots of people with little care to the legal niceties. Anyone who contributed to either the 4.4BSD version or a version with the big COPYRIGHTS AND OTHER DELUSIONS hunk in it (9.4.0 onward) presumably knew what they were doing, and anyone who contributed to a pre-1988 version was putting their work in the public domain. Unfortunately, I'd have to check antique diffs and changelogs to see whether anybody contributed substantial amounts of comments under other circumstances. I wouldn't worry about it though. Frankly most of it is obsolete anyway. - Finally, files with no explicit license notice. These are either free or non-distributable. Berne Convention law is pretty evil in some ways: it assumes that everything is fully covered by copyright with no or few permissions granted; this applies to anything first published after some date in 1988 in the US. (Items published in the US prior to 1988 without copyright notices are in the public domain, unless the author makes a big fuss and complains that the copyright notice omission wasn't their fault and was unintentional.) So the status of most of these depends on whether files with no copyright notices at all should be taken to be part of emacs and therefore subject to the GPL along with the rest of it. Unfortunately some of the stuff in the /etc directory is clearly *not* part of emacs and *not* licensed under the GPL, and most of the files in emacs have explicit license notices, which tends to make me believe that the answer is no, we shouldn't assume that. (Contrast Linux, where most files do not have explicit license notices, and the top-level license notice explictly states that it applies to everything in the package without another license notice.) Or it may depend on the file. The Zippy the Pinhead quotes and the random email messages which people may not have wanted to license under the GPL are particularly worrisome. Files like README and the Makefile are probably best understood as part of Emacs. Anyway, I list them all below. These are the license-free files which I found. Most of these have no clear date of publication, and no clear author, but where they do I mention it. Two were clearly published before 1988 and are in the public domain; the rest do not have documented copyright or licensing information. The upstream emacs maintainers
Re: RFH: Non-free files in Emacs
[EMAIL PROTECTED] (Nathanael Nerode) And the license-free graphics files. These probably have a better claim to be part of emacs and under the general license than the rest, because there's no place to put a separate license statement in these files. Some of these files look like C code. Can't the licence info be put in a C comment in them? Some of them like emacs.icon already have a comment. Either way, these don't seem a huge worry. emacs.icon emacs.xbm gnu.xpm gnus-pointer.xbm gnus-pointer.xpm gnus.pbm gnus.xpm letter.xbm splash.pbm splash.xpm splash8.xpm -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFH: Non-free files in Emacs
Nathanael Nerode [EMAIL PROTECTED] wrote: Files in the /etc directory of emacs21 which may be legally problematic follow. termcap.src This file is (mechanically generated) from ncurses' terminfo.src, and a moment's consideration would show that there is substantial creative content, not just facts. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFH: Non-free files in Emacs
Nathanael Nerode wrote: Files in the /etc directory of emacs21 which may be legally problematic follow. * There are a lot of files without any copyright or licensing information, and upstream probably will want to fix this. I would remove a lot of these even if they turn out to be free, as much of it is useless cruft. Upstream will almost certainly *not* want to fix this, as much as we might want them to. I don't think duplicating gnu.org/philosophy in the emacs source tarball is a particularly good idea, but the emacs authors (or at least those with a say in the matter) seem to. ObLicense: I hereby give permission to forward this message or any part of it (verbatim) to anyone who you think might find it useful. Heh. Second, files with explicit license notices which aren't standard free licenses, apart from the non-free files you already identified [...] COPYING -- Non-free (verbatim only), but we make an exception for it because it's the license for the program. Even if not a freeness issue, it should be removed in favor of /usr/share/common-licenses/GPL. [...] Finally, files with no explicit license notice. These are either free or non-distributable. The upstream emacs maintainers might want this list. GNU policy is generally to put a copyright and license notice in every file, and I suspect the absence from some of these files (like README and Makefile) is simply an oversight, and that these files are in fact FSF copyright. Frankly this directory could do with a good spring cleaning: anonymous cookie recipes are really not necessary, and 8-year-old order forms are ridiculous. That line of reasoning seems quite reasonable; at a minimum, perhaps they'd at least change it from legally ambigious to verbatim copying only, which would at least clarify the situation. [...] LPF -- does the organization even exist anymore? The most recent news item on http://lpf.ai.mit.edu/ dates from 2005-10-22, so they seem to still exist, if not with a great deal of activity. ISTR seeing this on gnu.org somewhere with a verbatim only license attached, but I could be wrong, and google doesn't seem to see it at the moment. Makefile I don't have this in my copy. celibacy.1 condom.1 -- Post-1988 (1992). Probably a better fit for the funny-manpages package than the emacs package. echo.msg -- Released 1985 in US without copyright notice, so public domain. Potentially modified since then; the CVS logs for emacs only go back to Sun Oct 3 12:34:45 1999, and that still leaves 14 years for potentially copyrightable modifications. In any case, more suited for the funny-manpages package than the emacs package. sex.6 -- Issued without copyright notice prior to 1988 (1987), so it's in the public domain. Modified since then, according to emacs CVS. In any case, more suited for the funny-manpages package than the emacs package. spook.lines -- unlikely to be copyrightable, so I would assume it is public domain Word lists can be copyrightable if the selection of the words involved actual creativity rather than an exhaustive list; that list certainly seems to qualify. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: RFH: Non-free files in Emacs
celibacy.1 condom.1 -- Post-1988 (1992). Probably a better fit for the funny-manpages package than the emacs package. sex.6 -- Issued without copyright notice prior to 1988 (1987), so it's in the public domain. Modified since then, according to emacs CVS. In any case, more suited for the funny-manpages package than the emacs package. Actually they are there too, in section 1fun. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFH: Non-free files in Emacs
Jérôme Marant wrote:
Far away from flamewars and heated discussions, the Emacs maintainers
(Rob Browning and I) are in a process of moving non-free files to
a dedicated package.
Thank you very much for working on this.
In order to avoid repackaging as much as possible once done, we would
like to make sure that any problematic file has been identified
(they are all located in /usr/share/emacs/21.4/etc), so a second
review would be welcome.
The following files have already been identified as offending:
etc/{CENSORSHIP,copying.paper,INTERVIEW,LINUX-GNU,THE-GNU-PROJECT,WHY-FREE}
Thanks in advance for your help.
Just to confirm the parameters of this review, are you assuming that any
file not explicitly licensed falls under the GPL of Emacs? Or should we
flag files which have no explicit license? Quite a number of the files
in etc/ have no explicit license.
Also, etc/MOTIVATION contains:
[reprinted with permission of the author
from the Monday 19 January 1987 Boston Globe]
with no license notice given, and authorization to reprint does not
necessarily include authorization to modify.
- Josh Triplett
signature.asc
Description: OpenPGP digital signature
Re: RFH: Non-free files in Emacs
Josh Triplett [EMAIL PROTECTED] writes: Just to confirm the parameters of this review, are you assuming that any file not explicitly licensed falls under the GPL of Emacs? Or should we flag files which have no explicit license? Quite a number of the files in etc/ have no explicit license. This is a very good question, I asked myself already. I tend to think that when no licensing information is given, the COPYING applies. But since I'm not a licensing specialist, I'd like a confirmation. Also, etc/MOTIVATION contains: [reprinted with permission of the author from the Monday 19 January 1987 Boston Globe] with no license notice given, and authorization to reprint does not necessarily include authorization to modify. I would not be surpised this one really lacks a proper license. Thanks. -- Jérôme Marant
Re: RFH: Non-free files in Emacs
* Jérôme Marant: Far away from flamewars and heated discussions, the Emacs maintainers (Rob Browning and I) are in a process of moving non-free files to a dedicated package. What about the Texinfo documentation? Currently, it's GFDL plus invariant sections.
Re: RFH: Non-free files in Emacs
Florian Weimer [EMAIL PROTECTED] writes: * Jérôme Marant: Far away from flamewars and heated discussions, the Emacs maintainers (Rob Browning and I) are in a process of moving non-free files to a dedicated package. What about the Texinfo documentation? Currently, it's GFDL plus invariant sections. Their are part of the non-free files but they are well identified, so they don't need any investigation, unlike etc files. -- Jérôme Marant
Re: How to free GFDL'ed documents with existing Front Cover texts
Frank Küster wrote: Hi, assume a document licensed under GFDL, with no invariant sections (and ...) has a front cover text (like A GNU Manual) and a back cover text (like You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development.). What should the developers do in order to make it DFSG-free (and not annoy RMS too much)? Dual-license it under the GPL. There are so many good reasons for this it's silly not to do it; for starters it allows moving material from the manual to the program and back without trouble. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?...
Re: x.org non free?
Mickaël Leduque [EMAIL PROTECTED] writes: (I'm not related with debian, except being a debian user) I'm a bit worried by this file I found in x.org source : xc/README.crypto I'm sure this question has been answered hundreds of times and there's nothing worrying here, but the contents of this file seems to make all the files that are related to it non free. What did I miss? I'm not a developer either, but from the legal point of view you're right, I'd say. Their README.crypto as found in the google cache on http://64.233.183.104/search?q=cache:VhI_C_FqbYsJ:hanzubon.jp/mirrors/xorg/cvs/xc/README.crypto+x.org+xc/README.cryptohl=declient=firefox says: Without limiting the generality of the foregoing, hardware, software, technology or services provided under this license agreement may not be exported, reexported, transferred or downloaded to or within (or to a national resident of) countries under U.S. economic embargo including the following countries: Cuba, Iran, Libya, North Korea, Sudan and Syria. This list is subject to change. I.E. they are making US export restrictions part of their license -- at least in german law, it doesn't matter whether they called the file LICENSE or README, they made it clear that they want to make this binding. This seems to be a violation of Nr. 5 of the DFSG, saying: The license must not discriminate against any person or group of persons. Also, the x.org README.crypto limits redistribution: You may not export or re-export this software or any copy or adaptation in violation of any applicable laws or regulations. I'd say this conflicts Nr. 1 of the DFSG, saying: The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale. So maybe somebody should talk to the x.org team. I think it's well possible that they simply wanted to make sure to comply with US law and overshot the mark. Ciao Michael
Re: x.org non free?
Michael Below [EMAIL PROTECTED] writes: Mickaël Leduque [EMAIL PROTECTED] writes: (I'm not related with debian, except being a debian user) I'm a bit worried by this file I found in x.org source : xc/README.crypto I'm sure this question has been answered hundreds of times and there's nothing worrying here, but the contents of this file seems to make all the files that are related to it non free. What did I miss? I'm not a developer either, but from the legal point of view you're right, I'd say. Their README.crypto says: Without limiting the generality of the foregoing, hardware, software, technology or services provided under this license agreement may not be exported, reexported, transferred or downloaded to or within (or to a national resident of) countries under U.S. economic embargo including the following countries: Cuba, Iran, Libya, North Korea, Sudan and Syria. This list is subject to change. I.E. they are making US export restrictions part of their license -- I think they are simply stating facts, to make the user aware of the situation. at least in german law, it doesn't matter whether they called the file LICENSE or README, they made it clear that they want to make this binding. This seems to be a violation of Nr. 5 of the DFSG, saying: The license must not discriminate against any person or group of persons. Also, the x.org README.crypto limits redistribution: You may not export or re-export this software or any copy or adaptation in violation of any applicable laws or regulations. Again, this is only stating facts that are always true, whether explicitly stated or not. I'd say this conflicts Nr. 1 of the DFSG, saying: The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale. If the law places restrictions on distribution, there is nothing a license can do about it. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: x.org non free?
Mns Rullgrd wrote: Michael Below [EMAIL PROTECTED] writes: I'm not a developer either, but from the legal point of view you're right, I'd say. Their README.crypto says: Without limiting the generality of the foregoing, hardware, software, technology or services provided under this license agreement may not be exported, reexported, transferred or downloaded to or within (or to a national resident of) countries under U.S. economic embargo including the following countries: Cuba, Iran, Libya, North Korea, Sudan and Syria. This list is subject to change. I.E. they are making US export restrictions part of their license -- I think they are simply stating facts, to make the user aware of the situation. If the law places restrictions on distribution, there is nothing a license can do about it. Is it not the case, however, that this paragraph is made a part of the license, immutable without the consent of all of the copyright owners? Meaning that, should the law change, the license won't? -- Lewis Jardine IANAL, IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: x.org non free?
Lewis Jardine writes: Måns Rullgård wrote: Michael Below [EMAIL PROTECTED] writes: I'm not a developer either, but from the legal point of view you're right, I'd say. Their README.crypto says: Without limiting the generality of the foregoing, hardware, software, technology or services provided under this license agreement may not be exported, reexported, transferred or downloaded to or within (or to a national resident of) countries under U.S. economic embargo including the following countries: Cuba, Iran, Libya, North Korea, Sudan and Syria. This list is subject to change. I.E. they are making US export restrictions part of their license -- I think they are simply stating facts, to make the user aware of the situation. If the law places restrictions on distribution, there is nothing a license can do about it. Is it not the case, however, that this paragraph is made a part of the license, immutable without the consent of all of the copyright owners? Meaning that, should the law change, the license won't? Which license? The copyright license from X.org contributors, or the export license from the US government? From the rest of README.crypto, I think it's clear that they are *not* attempting to condition the copyright license on acceptance of US export restrictions, and that they are instead just reminding users of the legal requirements imposed on anyone subject to the jurisdiction of the United States. For those outside the US's jurisdiction, the copyright license is the only one relevant to software freedom. Michael Poole
Re: x.org non free?
Måns Rullgård [EMAIL PROTECTED] writes: Michael Below [EMAIL PROTECTED] writes: I'm not a developer either, but from the legal point of view you're right, I'd say. Their README.crypto says: Without limiting the generality of the foregoing, hardware, software, technology or services provided under this license agreement may not be exported, reexported, transferred or downloaded to or within (or to a national resident of) countries under U.S. economic embargo including the following countries: Cuba, Iran, Libya, North Korea, Sudan and Syria. This list is subject to change. I.E. they are making US export restrictions part of their license -- I think they are simply stating facts, to make the user aware of the situation. I don't think so. Actually, both portions I quoted are reversed in the README. So first, you are told that you may not violate law (and it's true, one can disagree whether this is an additional requirement of the license, as I would see it because of the commanding tone, or a badly worded information). And then they are mentioning additional requirements. These requirements go beyond the US export law: As they are put, they also deny the right to export x.org source to North Korea etc. to people not in the US. If I exported the source to such a country, I wouldn't violate german law, but I would violate the license contract with the x.org authors. Michael Below
Re: x.org non free?
On Friday 25 March 2005 07:33 am, Michael Below wrote: Måns Rullgård [EMAIL PROTECTED] writes: Michael Below [EMAIL PROTECTED] writes: I'm not a developer either, but from the legal point of view you're right, I'd say. Their README.crypto says: Without limiting the generality of the foregoing, hardware, software, technology or services provided under this license agreement may not be exported, reexported, transferred or downloaded to or within (or to a national resident of) countries under U.S. economic embargo including the following countries: Cuba, Iran, Libya, North Korea, Sudan and Syria. This list is subject to change. I don't think so. Actually, both portions I quoted are reversed in the README. So first, you are told that you may not violate law (and it's true, one can disagree whether this is an additional requirement of the license, as I would see it because of the commanding tone, or a badly worded information). And then they are mentioning additional requirements. These requirements go beyond the US export law: As they are put, they also deny the right to export x.org source to North Korea etc. to people not in the US. If I exported the source to such a country, I wouldn't violate german law, but I would violate the license contract with the x.org authors. Michael Below The licensors cannot grant you the right to do something that is prohibited by law. Nor can they authorize an action which they themselves cannot commit. The economic embargoes mentioned are quite broad, and if the U.S. Gov't decided to stick its nose into the situation, I wouldn't be surprised if X.org would be criminally liable if others were exporting their code to embargoed nations if X.org knew about it. The language thus stands as a liability deferment mechanism... like the no warranty is provided to the extent allowable by law. As for overshooting the mark... if only it were that simple. You the user and potential exporter may not be liable under German law. But like I said before, I'm willing to bet there is vicarious liability in this situation. An embargo without such provisions would result in hundreds of shell corporations that would sell goods to listed countries and then collapse without assets when sued for breaking the embargo. Vicarious liability ensures that those who actually benefit from breaking the embargo are punished. All that being said, the embargoes are stupid... but Debian can't just stick its head in the sand and pretend like its not a problem. Speaking of which... whatever happened to the none-US archives. Seems like that was setup to resolve this sort of problem. Sean Law School Lurker
Re: x.org non free?
On Fri, Mar 25, 2005 at 12:03:46PM +0100, Mickaël Leduque wrote: (I'm not related with debian, except being a debian user) I know x.org is not in debian (yet?), but before bothering someone there, I prefer talking about it here. I'm a bit worried by this file I found in x.org source : xc/README.crypto I'm sure this question has been answered hundreds of times and there's nothing worrying here, but the contents of this file seems to make all the files that are related to it non free. What did I miss? This is more a statement of what we can do upstream -- since the Xwraphelp.c file is developed in the US, and the main point of export is xorg.freedesktop.org (located in Portland), it's a general statement, since we can't knowingly export from the US to someone who will turn around and export to Cuba or Syria or whatever it is. It's mainly an exercise in BXA arse-covering, and should be worded a bit more clearly, I suppose. signature.asc Description: Digital signature
Re: PHP non-free or wrongly named?
David Moreno Garza wrote: I think Joey's mail is quite good since it is just stating facts. Truth cannot be made up, specially on free software (and non-free also) legal issues. It took me a long time to learn this one, but it's true - it's not just what you say, it's the way that you say it. I have no quibble with the factual content of his mail. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PHP non-free or wrongly named?
Martin Schulze wrote: I've been informed about details of the PHP license: For php3: 5. The name PHP must not be used to endorse or promote products derived from this software without prior written permission from the PHP Development Team. This does not apply to add-on libraries or tools that work in conjunction with PHP. In such a case the PHP name may be used to indicate that the product supports PHP. For php4: 4. Products derived from this software may not be called PHP, nor may PHP appear in their name, without prior written permission from [EMAIL PROTECTED] You may indicate that your software works in conjunction with PHP by saying Foo for PHP instead of calling it PHP Foo or phpfoo Since Debian is (or at least may be) distributing patches in their packages that are not part of upstream, we are distributing a derived product and hence must not name it PHP. This does not only affect Debian but also other distributions of PHP that are trying to enhance or fix PHP in some ways. I've sent this letter to the PHP group: Dear authors, we are a group of developers that build up an entire GNU/Linux system based on the Linux kernel, GNU utilities and a lot of other software. It is named Debian GNU/Linux http://www.debian.org/, you may already have heard about it. Recently we stomped over a paragraph in the license of PHP4 and wonder if we are allowed to distribute PHP4 packages at all, now and in the future. Here's the license except that left us wondering: 4. Products derived from this software may not be called PHP, nor may PHP appear in their name, without prior written permission from [EMAIL PROTECTED] You may indicate that your software works in conjunction with PHP by saying Foo for PHP instead of calling it PHP Foo or phpfoo We can indeed think of a problematic situation when we develop patches, broken or not, that are applied to the PHP4 source package when building the package. These could be improvements, corrections, extensions or just security fixes. If we need to contact you as upstream for each and every change, we'd have to decide whether PHP4 is distributable at all and needs to be moved to non-free or not. So basically, this boils down to Are arbitrary organisations or developers allowed to modify the PHP4 source and redistribute it and still calling it PHP4? [ ] yes, they are [ ] no, they are not, but calling the result something else is fine [ ] no, they are not at all From reading the above license except we fear that the second answer will be yours, but we better ask yourself. According to our own guidelines[1] a permission of the above for only the Debian project would not be sufficient, since it would render the license Debian-specific which it must not: 1. http://www.debian.org/social_contract#guidelines Even though this is a private mail, I would like to publish your answer, so please take into account when writing a response that it will most probably show up on the debian-legal[2] mailing list where this issue is discussed. If you don't like this, please send be a short answer stating that you don't wish to be quoted in public. 2. http://lists.debian.org/debian-legal/ Andi Gutmans [EMAIL PROTECTED] answered and told me that he speaks for the PHP Group: | As per your problem, having such a clause in the BSD-like license | is the way both Apache and PHP have been enforcing and protecting | their brand for a long time. Minor build changes and backported | security fixes are fine and if that's all you're doing there is no | need to rename the package. The problems arise when you start | making significant changes to the actual functionality of the | The license clause and intent is identical in the Apache license | which we believe you are also shipping. So as soon as our maintainer or security team adds more than onlyh build changes and backported security fixes, we'll have to rename the PHP (and Apache) packages. Regards, Joey -- If nothing changes, everything will remain the same. -- Barne's Law Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PHP non-free or wrongly named?
Martin Schulze wrote: I've sent this letter to the PHP group: Dear authors, we are a group of developers that build up an entire GNU/Linux system based on the Linux kernel, GNU utilities and a lot of other software. It is named Debian GNU/Linux http://www.debian.org/, you may already have heard about it. Martin, I may not be the most tactful person in the world, not a debian-legal regular or Debian developer, but I feel I should say that if I received an email like the one you sent the PHP developers, my first reaction would be rather negative towards the author and his organisation. The attitude which came across in your email seemed to be We're the big and important Debian project, and we've been violating your licence, which is a bit of a shame, but please tell us we can keep doing so, otherwise we'll yank your software from our distribution, and you wouldn't want that, would you? As the recipient of it, I certainly wouldn't be inspired to work out a constructive solution. Perhaps it would be advisable for letters which go out carrying the authority of Debian (We are a group of developers...) to be reviewed by the list before being sent? Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PHP non-free or wrongly named?
Michael Below wrote: Here's the license except that left us wondering: 4. Products derived from this software may not be called PHP, nor may PHP appear in their name, without prior written permission from [EMAIL PROTECTED] You may indicate that your software works in conjunction with PHP by saying Foo for PHP instead of calling it PHP Foo or phpfoo When I read this last sentence I started wondering about packages like phpbb, phpgroupware etc. As far as I know phpbb is an app for PHP, not a derived work. But the trademark issue might remain. Maybe one should ask the PHP group to clarify if their claim only applies to derived works, or if they are trying to enforce trademark rights on any use of PHP. If it's the latter, Debian might have to worry about it... Surely by definition the claim only applies to derived works, seeing as it is in the license for distribution of PHP? Rather than being a trademark claim, is it not the case that this is an attempt to achieve trademark-like behaviour with copyright law? -- Lewis Jardine IANAL, IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PHP non-free or wrongly named?
On Fri, 18 Feb 2005 17:12:48 +0100 Martin Schulze wrote: I've been informed about details of the PHP license: For php3: 5. The name PHP must not be used to endorse or promote products derived from this software without prior written permission from the PHP Development Team. This does not apply to add-on libraries or tools that work in conjunction with PHP. In such a case the PHP name may be used to indicate that the product supports PHP. I recently checked php3 copyright file and it states that PHP3 is dual licensed: PHP license or GNU GPL at the recipient's option: http://packages.debian.org/changelogs/pool/main/p/php3/php3_3.0.18-28/php3.copyright The DFSG compliance of the PHP license should not be a concern if we have the GPL as an option to be chosen, right? -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp4h2oKRrIBS.pgp Description: PGP signature
Re: PHP non-free or wrongly named?
On Tue, Feb 22, 2005 at 03:31:22AM +, MJ Ray wrote: Joel Aelwyn [EMAIL PROTECTED] wrote: [...] You may not have any cookies right now. It's a reflexive negation rewording of May I x - You may not x. [snip] Well, that's fine, but if I don't need your permission in order to have cookies, it's sort of irrelevant. Also, it doesn't actually require any action from me to achieve that state of not having your permission to have cookies and make your statement true. This is a head-strainer and I'm not surprised that anyone is unfamiliar with it. It's related to old jokes that my school teachers used to use: Can I leave the room? Not without my permission. A bit twisted, maybe, but it teaches. Yes; my impression is that it is likely that this is badly written in the same way that it is quite common for people to ask Can I? instead of May I?. Thank goodness nobody tried to use shall / will or who / whom. As I wrote earlier, legal interpretation of this sort of phrase needs someone other than me and if anyone is worried, please go ask PHP Group about it (if PHP Group is bothering to accept email yet) and maybe get blanket PHP for ... approval. Indeed, it seems like the standard fallback of ask for a clarification is in order. Gotta love TMDA systems, really. -- Joel Aelwyn [EMAIL PROTECTED] ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Re: PHP non-free or wrongly named?
I would say that debian does not treat trademark as a licence. Else we could not release with the debian release logo , nor the debian trademarked name. That would be pretty cool :) I am out of laugh thinking of we tellling the release manager ehrm sorry we have an RC on debian, it is not free. Could you contact the SPI to ask if they agree to free the debian name ! :- No offense, i always found legal issues pretty funny. You may not be wrong as the php trademark is defined in the licence itself, there is obviously a legislation mix. Is there a copyright on the trademark requiring us to ask for an exception to the licence to enable us to ask for the right to use their trademark ... damn Regards Alban -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: PHP non-free or wrongly named?
On Wed, Feb 23, 2005 at 07:18:37AM +0100, Alban browaeys wrote: I would say that debian does not treat trademark as a licence. Else we could not release with the debian release logo , nor the debian trademarked name. That would be pretty cool :) That's broken reasoning; it's like saying we should not treat software that prohibits commercial use as non-free, since otherwise Debian could not prohibit commercial use. Just because Debian wants to do something doesn't make it free; if it's non-free, Debian should stop doing it, too. (The reasoning that goes Trademarks don't make a work non-free, because you can always remove the trademark and functional elements aren't protected by trademark is much better, though there are a lot of questions, such as if it takes substantial effort to remove restricted trademarks from a work, should Debian do so, to ensure that the freedoms required by the DFSG can actually be exercised?, and others.) I am out of laugh thinking of we tellling the release manager ehrm sorry we have an RC on debian, it is not free. Could you contact the SPI to ask if they agree to free the debian name ! :- Debian does it, therefore it's free isn't a line of reasoning that one can use and still take Freeness seriously. -- Glenn Maynard
Re: PHP non-free or wrongly named?
Lewis Jardine [EMAIL PROTECTED] wrote: [...] Having just reread your post again, I think I realise what you are saying. Because they wrote the 'condition' as Products derived from this software may not be called PHP, nor may PHP appear in their name, without prior written permission from [EMAIL PROTECTED] instead of Either a)The name of the product does not contain 'PHP' OR b) the name of the product contains 'PHP' AND the licensee has prior written permission from [EMAIL PROTECTED], the condition is always self-evidently true. Now I'm not sure what you're saying here. I think they're just pointing out that you do not have permission and they are the ones to give permission. If this is the case, do you not think that your interpretation goes against both the obvious intended meaning of the condition, and the fact that the same wording convention is used in the other conditions of this license? Courts usually favour what the licensor meant-it-to-mean (when this is obvious to a reasonable person) rather than what they actually ended up saying. I think the obvious intended meaning is another assertion of representation norms. The other conditions of this licence use must not may. To what wording convention do you refer? Are you claiming that if I wrote Fred runs; Jane runs; Tom walks; Belinda runs then I really mean Tom runs because it follows a similar language pattern as the other clauses? If you are troubled by what the licensor means and the limits of the rights they assert, ask them. Under this interpretation, all clauses of the BSD license could be treated as statements of self-evident facts, thus making them all true, and the entire license a blanket permission grant. This is not a common or correct interpretation, however. No, there's two directions (must) and one statement (may). If this is not the case, I apologise for wasting your time. Thank you. It's not a total waste, as it throws the difference into sharp relief, I think. -- MJR/slef http://people.debian.org/~mjr/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PHP non-free or wrongly named?
MJ Ray wrote: As a first attempt to fix, if it's thought to be a problem, can you ask [EMAIL PROTECTED] to give blanket permission for php packaging to be called PHP or PHP for distribution-or-package-system? Tried that, received: 996 N ! Feb 21 PHP Automoderator 117 PHP posting confirmation for [EMAIL PROTECTED] Apparently they are not interested in mail from me. Fine. If somebody else is interested in getting their opinions, they may retry. I'm not going to respond to any tmda like system. The mail I sent was copied to debian-email, so you can find the content on master in the archive if you're not subscribed to debian-legal. Regards, Joey -- A mathematician is a machine for converting coffee into theorems. Paul Erdös Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PHP non-free or wrongly named?
On Mon, Feb 21, 2005 at 10:42:29AM +, MJ Ray wrote: Lewis Jardine [EMAIL PROTECTED] wrote: [...] I think the obvious intended meaning is another assertion of representation norms. The other conditions of this licence use must not may. To what wording convention do you refer? Are you claiming that if I wrote Fred runs; Jane runs; Tom walks; Belinda runs then I really mean Tom runs because it follows a similar language pattern as the other clauses? If you are troubled by what the licensor means and the limits of the rights they assert, ask them. You may not have any cookies right now. It's a reflexive negation rewording of May I x - You may not x. This is not the same usage as You may, or may not, encounter y. Perhaps this is a quirk of American English; I can't really be bothered enough to go dig up the full history. But it is sufficiently clear that at least some large set of people who are told You may not interpret it as an imperative statement, rather than an informational one, that it should be assumed to be a prohibition. I haven't even tried to follow the rest of the thread, it makes my head hurt right now, so what (if any) consequences this triggers in the interpretation, I couldn't tell you. -- Joel Aelwyn [EMAIL PROTECTED] ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: PHP non-free or wrongly named?
Nick Phillips [EMAIL PROTECTED] wrote: Nice unmarked trim. Try another tactic. [...] Is English your first language? Yes, born within 60 miles of Oxford, my English is as English as it gets, except when I talk dialect. Try another tactic. I find it hard to believe that any native speaker with a reasonable degree of literacy can misinterpret that paragraph in the way that you have, whilst still believing that it seems clear. Educated to postgrad level. Try another tactic. For the avoidance of doubt, that paragraph clearly means that: * you may not call your derived product PHP * PHP may not appear in your derived product's name if you wish to take advantage of the permissions to be granted, unless you have prior written permission to do so. [...] See, it is clear. The first bullet is a simple assertion of norms. The second is contradicted by the remainder of the paragraph anyway. Try another tactic if you want to boot PHP out. If you were really concerned for its well-being, you could work with the maint to check it out and resolve it to *your* satisfaction. -- MJR/slef http://people.debian.org/~mjr/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PHP non-free or wrongly named?
MJ Ray wrote:
Linguistically, this seems clear to me. Showing in context:
Redistribution and use in source and binary forms, with or without
modification, is permitted provided that the following conditions
are met:
[...]
4. Products derived from this software may not be called PHP, nor
may PHP appear in their name, without prior written permission
from [EMAIL PROTECTED] You may indicate that your software works in
conjunction with PHP by saying Foo for PHP instead of calling
it PHP Foo or phpfoo
Now, I hope nearly everyone defines the relevant sense of may
as have permission or similar. So, it's permitted provided
that {we don't have permission for some acts without permission
from [EMAIL PROTECTED] The {}d bit is probably always true unless someone
else gives us permission (huh?).
If it's not intended as a statement (and I hope it is) then I think
it's a case of Lawyer error: reboot Lawyer.
Having just reread your post again, I think I realise what you are
saying. Because they wrote the 'condition' as Products derived from
this software may not be called PHP, nor may PHP appear in their
name, without prior written permission from [EMAIL PROTECTED] instead of
Either a)The name of the product does not contain 'PHP' OR b) the name
of the product contains 'PHP' AND the licensee has prior written
permission from [EMAIL PROTECTED], the condition is always self-evidently true.
If this is the case, do you not think that your interpretation goes
against both the obvious intended meaning of the condition, and the fact
that the same wording convention is used in the other conditions of this
license? Courts usually favour what the licensor meant-it-to-mean (when
this is obvious to a reasonable person) rather than what they actually
ended up saying.
Under this interpretation, all clauses of the BSD license could be
treated as statements of self-evident facts, thus making them all true,
and the entire license a blanket permission grant. This is not a common
or correct interpretation, however.
If this is not the case, I apologise for wasting your time.
On the subject of statement vs condition, if the first sentence of four
were a statement, surely it should be a statement of trademark law as it
actually is*? That (when interpreted in this way) it is incorrect on at
least two counts** suggests that it should be interpreted as a
condition, not a statement, much like the GPL's You may not copy,
modify, sublicense, or distribute the Program except as expressly
provided under this License., which is incorrect if interpreted as a
statement of fact rather than a condition: in most jurisdictions, you
have 'fair use' rights in addition to the GPL.
* and thus be something like 'products (whether derived from this
software or not) may not misrepresent themselves as being the product
'PHP' when this is not the case'.
** trademark lay is not limited to only derived works, and trademark law
cannot prevent the truthful use of a trademark (for instance, 'Debian's
modified version of PHP' would not infringe trademark law, despite 'PHP'
being in the name).
--
Lewis Jardine
IANAL, IANADD
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PHP non-free or wrongly named?
Scripsit MJ Ray [EMAIL PROTECTED] Henning Makholm [EMAIL PROTECTED] wrote: [...] However, conventionally, may not do foo is supposed to be parsed as (a) whereas must not do foo is usually parsed analogously to (b) - which makes them actually mean the same in natural English. Which convention specified that change in meaning for may? May itself does not change its meaning. But it is not our modus operandi to consider something to be *free* based on such a reading that clearly diverges from what the author actually did mean. Would you please forward the explanation you appear to have received from the PHP licence author? I have not received any specific explanation. But I believe I have a basic understanding of the English language. -- Henning Makholm NB! Benbrud er et symptom, ikke en sygdom. Hvis du har brækket benet bør du gå til lægen for at få fastslået årsagen. Brug aldrig Herbalittm mod benbrud uden lægens anvisning.
Re: PHP non-free or wrongly named?
On Sat, Feb 19, 2005 at 02:59:04AM +, MJ Ray wrote:
Linguistically, this seems clear to me.
Redistribution and use in source and binary forms, with or without
modification, is permitted provided that the following conditions
are met:
[...]
4. Products derived from this software may not be called PHP, nor
may PHP appear in their name, without prior written permission
from [EMAIL PROTECTED] You may indicate that your software works in
conjunction with PHP by saying Foo for PHP instead of calling
it PHP Foo or phpfoo
Now, I hope nearly everyone defines the relevant sense of may
as have permission or similar. So, it's permitted provided
that {we don't have permission for some acts without permission
from [EMAIL PROTECTED] The {}d bit is probably always true unless someone
else gives us permission (huh?).
If it's not intended as a statement (and I hope it is) then I think
it's a case of Lawyer error: reboot Lawyer.
Is English your first language?
I find it hard to believe that any native speaker with a reasonable
degree of literacy can misinterpret that paragraph in the way that
you have, whilst still believing that it seems clear.
For the avoidance of doubt, that paragraph clearly means that:
* you may not call your derived product PHP
* PHP may not appear in your derived product's name
if you wish to take advantage of the permissions to be granted, unless
you have prior written permission to do so.
They go on to suggest ways in which you could convey the fact that
your product works in conjunction with PHP without pissing them off.
Cheers,
Nick
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PHP non-free or wrongly named?
Scripsit MJ Ray [EMAIL PROTECTED]
Linguistically, this seems clear to me.
No, there's always at least formally a possibility of confusion. Even
if we ignore the without prior written permission part, we can parse
4. Products derived from this software may not be called PHP,
in two different ways.
(a) Derived products (may not) be called PHP.
(b) Derived products may (not be called PHP).
Here (a) asserts the falsehood of we have permission to call it PHP,
whereas (b) asserts that we have permission to call it something else.
The tricky part is that if we exchange may with must one would
expect the meaning to change, becuase may means you have the choice
of doing this or not doing this, and must means your only option
is doing this. However, conventionally, may not do foo is supposed
to be parsed as (a) whereas must not do foo is usually parsed
analogously to (b) - which makes them actually mean the same in
natural English.
I leave it as an exercise for the studious reader to express this in
a modal logic where may is dual to must ;-)
So, it's permitted provided that {we don't have permission for some
acts without permission from [EMAIL PROTECTED]
Which is clearly a nonsensical interpretation, which means that you
should probably reboot your English parser, as it seems to have been
contaminated with some kind of rigid programming language semantics.
Word games such as these can be fun and occasionally useful for
demonstrating that a license could be interpreted in a non-free way.
But it is not our modus operandi to consider something to be *free*
based on such a reading that clearly diverges from what the author
actually did mean.
--
Henning Makholm Jeg har tydeligt gjort opmærksom på, at man ved at
følge den vej kun bliver gennemsnitligt ca. 48 år gammel,
og at man sætter sin sociale situation ganske overstyr og, så
vidt jeg kan overskue, dør i dybeste ulykkelighed og elendighed.
Re: Clarifying non-free parts of the GNU FDL
Steve Langasek wrote: On Tue, Sep 28, 2004 at 04:23:01PM -0700, Joe Buck wrote: These exceptions are granted for derivative works only if those works contain no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. That's a possibility, but without buy-in from the FSF, I don't regard the GFDL as a particularly good starting point for a free documentation license. It seems like the CC licenses might be a better basis. Another possibility is to simply use the GPL, and grant exceptions for various cases. Given that an ideal Free documentation license would be GPL-compatible (if not the GPL itself, which is pretty ideal), and that any GPL-compatible license must not have any restrictions that are not in the GPL (so it must consist of some subset of the GPL's conditions), then that GPL-compatible documentation license could instead be written as a set of exceptions to the GPL. For example, if one wanted to permit distributors of physical copies to refuse to provide source, then that could be written as an exception. (I personally think it is a good idea to require distributors, both physical and electronic, to provide source. However, many people wish to waive this condition for convenience, and that's fine; the resulting license would still be free, just less of a copyleft.) - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Clarifying non-free parts of the GNU FDL
On Mon, 04 Oct 2004 10:51:01 -0700 Josh Triplett wrote: Another possibility is to simply use the GPL, and grant exceptions for various cases. Given that an ideal Free documentation license would be GPL-compatible (if not the GPL itself, which is pretty ideal), and that any GPL-compatible license must not have any restrictions that are not in the GPL (so it must consist of some subset of the GPL's conditions), then that GPL-compatible documentation license could instead be written as a set of exceptions to the GPL. For example, if one wanted to permit distributors of physical copies to refuse to provide source, then that could be written as an exception.(I personally think it is a good idea to require distributors, both physical and electronic, to provide source. However, many people wish to waive this condition for convenience, and that's fine; the resulting license would still be free, just less of a copyleft.) Agreed fully. The GPL *is* suitable for documentation. And providing source is indeed important in order to permit the recipient to fully exercise the freedoms we value... -- Today is the tomorrow you worried about yesterday. .. Francesco PoliGnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpyhaV7Zk1Gz.pgp Description: PGP signature
Re: Clarifying non-free parts of the GNU FDL
On Tue, Sep 28, 2004 at 04:23:01PM -0700, Joe Buck wrote: Side issue #1: even a GFDL with exceptions is still going to be GPL incompatible. True, but that's also the case for several other licenses that are considered DFSG-free, so the point isn't relevant for this discussion. We can recommend dual licensing, but don't need to require it. It is not a freeness issue, but it is a real reason why developers of GPL software may wish to not use the GFDL as their documentation license. Side issue #2: people can add invariant sections later. If so, then those derived works would be non-DFSG-free, but the original work would still be free. The LGPL has similar issues. However, authors of LGPL software can be assured that contributions received under the terms of the LGPL are also free. Authors of works distributed under the GFDL who have taken special precautions to make their work DFSG-free must also take similar precautions whenever accepting contributions under the same license. Side issue #3: claims that we should tell people to use the GPL for documentation. That's a bad idea, as if I sell my GPL-covered printed book to a friend, and that book was produced from, say, DocBook SGML, I have to either give the friend the SGML source code, or else give him a written offer, good for three years, to give him the source code later. There is good reason for debian-legal to be thinking about licensing specifically designed for documentation, and the GFDL does have some good ideas, even if it is seriously flawed. There are reasons why authors of print books would not want to distribute under the GPL, but there are also reasons why authors of software would not want to use the GPL. Debian's purpose is not to ensure that our license recommendations meet the needs of all authors, it is to make authors aware of the available pre-existing license options that meet Debian's requirements for distribution and of the GFDL's problems under the DFSG. Side issue #4: claims that a license with exceptions would be a non-copyleft. No; derivative works still have to be licensed on the same terms. Not really; as long as the license is GFDL, the same terms would include the provision that others are allowed to add additional restrictions to derived works, in the form of invariant sections. This is distinctly not copyleft in nature. I would suggest producing some short, standard exceptions language, starting from what Nathanael wrote. I would also suggest adding text like the following: These exceptions are granted for derivative works only if those works contain no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. That's a possibility, but without buy-in from the FSF, I don't regard the GFDL as a particularly good starting point for a free documentation license. It seems like the CC licenses might be a better basis. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Clarifying non-free parts of the GNU FDL
On Tue, Sep 28, 2004 at 09:21:43PM -0400, Brian Thomas Sniffen wrote: Joe Buck [EMAIL PROTECTED] writes: Side issue #1: even a GFDL with exceptions is still going to be GPL incompatible. True, but that's also the case for several other licenses that are considered DFSG-free, so the point isn't relevant for this discussion. We can recommend dual licensing, but don't need to require it. It's particularly important for documentation of GPL'd works, where being able to move code and informative text back and forth -- for online help, for example -- is useful but made impossible by the licensing. I'm fine with recommending that people dual-license; as you say, it's a PITA otherwise. But incompatibility with the GPL does not cause GFDL non-freeness.
Re: Clarifying non-free parts of the GNU FDL
On Tue, Sep 28, 2004 at 10:03:22PM -0700, Joe Buck wrote: I'm fine with recommending that people dual-license; as you say, it's a PITA otherwise. But incompatibility with the GPL does not cause GFDL non-freeness. Assuming you meant DFSG here, I don't think anyone is suggesting that it does. -- Glenn Maynard
Re: Clarifying non-free parts of the GNU FDL
On 2004-09-29 00:23:01 +0100 Joe Buck [EMAIL PROTECTED] wrote: Side issue #3: claims that we should tell people to use the GPL for documentation. That's a bad idea, as if I sell my GPL-covered printed book to a friend, and that book was produced from, say, DocBook SGML, I have to either give the friend the SGML source code, or else give him a written offer, good for three years, to give him the source code later. FDL-covered works distribute a source-like version or an offer, reasonably prudent for a year (lawyerbomb!), of a source-like download later IIRC. This is only obligatory if you distribute 100, but would anyone want to hinder a friend? If you don't want to share source, maybe you want to use an MIT/X11-style licence? -- MJR/slefMy Opinion Only and not of any group I know Creative copyleft computing - http://www.ttllp.co.uk/ LinuxExpo.org.uk village 6+7 Oct http://www.affs.org.uk
Re: Clarifying non-free parts of the GNU FDL
Joe Buck [EMAIL PROTECTED] writes: I'm pleased to see that documentation writers are trying to figure out a way to clean up some issues with the GNU FDL. It seems, though, that some of the commenters are getting sidetracked by side issues. Side issue #1: even a GFDL with exceptions is still going to be GPL incompatible. True, but that's also the case for several other licenses that are considered DFSG-free, so the point isn't relevant for this discussion. We can recommend dual licensing, but don't need to require it. It's particularly important for documentation of GPL'd works, where being able to move code and informative text back and forth -- for online help, for example -- is useful but made impossible by the licensing. Side issue #3: claims that we should tell people to use the GPL for documentation. That's a bad idea, as if I sell my GPL-covered printed book to a friend, and that book was produced from, say, DocBook SGML, I have to either give the friend the SGML source code, or else give him a written offer, good for three years, to give him the source code later. Yes, and if you used GPL'd code -- for a bunch of examples in the text, perhaps -- then you have to do that anyway. On the other hand, if you're printing books then you can just put an offer in the back, nice and easy -- and there'll be few versions, given current printing technology. Any future technology which makes more versions feasible also makes source distribution easier, too. And if you have to give out source, just give the source you had -- CD in the back, for example. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Clarifying non-free parts of the GNU FDL
On Wed, 22 Sep 2004 18:12:07 -0400 Nathanael Nerode wrote: If these clarifications were to be made, would the licence be considered DFSG-free? Um... I think so. Were there any other problem clauses? The possibility for further modifiers to *add* unmodifiable sections (Invariant Sections, Front/Back-cover Texts, ...)? With this permission in the license, a work is Free (as long as it doesn't include unmodifiable sections in the first place), but can easily generate derivatives that are non-free. This could be undesired by a copyright holder who wants a copyleft Free license... Anyway, Roger, consider that, one exception or additional permission after the other, we are approximately moving in the GPL-2 direction. I really recommend to choose the GPL-2 itself, as it is really the most studied and understood copyleft license. At least in dual license with the GFDL, but GPL-2 alone is my recommendation... -- | GnuPG Key ID = DD6DFCF4 | $ fortune Francesco |Key fingerprint = | Q: What is purple Poli| C979 F34B 27CE 5CD8 DC12 | and commutes? | 31B5 78F4 279B DD6D FCF4 | A: A boolean grape. pgpt2bcRkPJli.pgp Description: PGP signature
Re: Clarifying non-free parts of the GNU FDL
Roger Leigh wrote: During discussion with gimp-print upstream about the potential problems with the GNU FDL and the possibility of relicensing it, a number of issues have cropped up, which I'd be grateful if you could assist with. I have pointed to Manoj's draft position statement as a summary of the issues with the FDL found to date, which we have been discussing. If the documentation was to remain GFDL licenced, would be possible to add a clarification to the licence in order to counter the main problems which would affect this work? The work is written in Docbook/SGML, and contains no invariant sections. Specifically, would it be possible to 1) Allow storage/transmission on encrypted filesystems/links to counter the DRM restriction? Should be; can we come up with a good clause? In addition, despite and contrary to the requirements in section 2 of the GFDL, the copyright holders grant you the right to use technical measures to obstruct or control the reading or further copying of (1) copies you make and do not distribute or (2) copies you distribute, provided that you also make an unobstructed, uncontrolled copy available to the same recipients. 2) Not require forcing distribution of transparent copies with bulk opaque copies? Should be; can we come up with a good clause? ;-) In addition, the copyright holders exempt you from the requirements in section 3 of the GFDL. If these clarifications were to be made, would the licence be considered DFSG-free? Um... I think so. Were there any other problem clauses? Are there any other possible amendments that could be made to make the licence DFSG-free? Lastly, are there any alternative licences available? The author (and copyright holder) of the work would prefer a licence suited to documentation rather than programs (which I don't disagree with). You do realize that GFDL'ed documentation with a GPL'ed program means that moving stuff between the documentation and the program is possible *only* for the copyright holder. This is tedious in the extreme when the program or documentation has multiple copyright holders. Note that there are multiple copyright holders whenever more than one person contributes creative material of more than about 15 lines, unless one of them is employing all the others (work-for-hire), or they signed written, paper copyright assignments. GFDL/GPL dual-licensing would be a good thing for that reason. -- This space intentionally left blank.
Re: Clarifying non-free parts of the GNU FDL
On 2004-09-21 19:09:18 +0100 Roger Leigh [EMAIL PROTECTED] wrote: If the documentation was to remain GFDL licenced, would be possible to add a clarification to the licence in order to counter the main problems which would affect this work? [...] In general, I think they should grant exceptions to part of the licence and give additional permissions, rather than issue clarifications that contradict the licence or its author. The work is written in Docbook/SGML, and contains no invariant sections. [...] Does it contain any of the other modification-restricted sections? If these clarifications were to be made, would the licence be considered DFSG-free? Are there any other possible amendments that could be made to make the licence DFSG-free? With extensive additions, I think it could be DFSG-free. It will probably end up as non-copyleft, as all future authors would need to use the same extras. Lastly, are there any alternative licences available? The author (and copyright holder) of the work would prefer a licence suited to documentation rather than programs (which I don't disagree with). The GPL-2 is the usual recommendation here for this situation if you want copyleft. Its definition of Program can include documentation. For a docbook document, it seems particularly useful because of the source code concept. BTW, please could you CC me on any replies--I'm not subscribed to debian-legal. Done. -- MJR/slefMy Opinion Only and not of any group I know Creative copyleft computing - http://www.ttllp.co.uk/ http://www.thewalks.co.uk stand 13,Lynn Carnival,12 Sep
Re: Clarifying non-free parts of the GNU FDL
On Tue, 2004-09-21 at 13:09, Roger Leigh wrote: The Gimp-Print User's Guide (package gimpprint-doc) is currently licensed under the terms of the GNU FDL. During discussion with gimp-print upstream about the potential problems with the GNU FDL and the possibility of relicensing it, a number of issues have cropped up, which I'd be grateful if you could assist with. I have pointed to Manoj's draft position statement as a summary of the issues with the FDL found to date, which we have been discussing. If the documentation was to remain GFDL licenced, would be possible to add a clarification to the licence in order to counter the main problems which would affect this work? The work is written in Docbook/SGML, and contains no invariant sections. I assume by no invariant sections you also mean no cover texts, acknowledgements, or dedications. Specifically, would it be possible to 1) Allow storage/transmission on encrypted filesystems/links to counter the DRM restriction? 2) Not require forcing distribution of transparent copies with bulk opaque copies? If these clarifications were to be made, would the licence be considered DFSG-free? Are there any other possible amendments that could be made to make the licence DFSG-free? Tentatively, I would say yes, this is free. Tentatively because I stopped paying too much attention to the specifics of the FDL after no one at the FSF seemed interested in resolving the more serious problems. Similar to how we only discovered the DRM issues after being hung up on invariants for a while, there might be some more nasty clauses hiding in the license that no one has noticed yet (especially given the complexity of it). However, this license is still not GPL-compatible, meaning text can't easily be moved from GIMP-Print itself (or other printing programs) into the documentation and vice versa. Lastly, are there any alternative licences available? The author (and copyright holder) of the work would prefer a licence suited to documentation rather than programs (which I don't disagree with). I'm preparing a large amount of DocBook released under the GNU GPL, with the following notice: This document is licensed under the GNU General Public License version 2 as published by the Free Software Foundation. References to object code and executables in the GNU GPL are to be interpreted as the output of any document formatting or typesetting system, including intermediate and printed output. This license is GPL-compatible in both directions, and I don't see that it presents any serious problems just because I'm applying it to a non-program. Any license that tries to cater to some specifics of non-programs results in problems when you try to move text a document to a program and vice versa, which is a common case in software documentation. If upstream really needs a documentation-specific license, one possibility is releasing the documentation under a GFDL/GPL dual license. If the author does this, then we don't even need exceptions to the GFDL, because the GPL alone is free. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Clarifying non-free parts of the GNU FDL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe Wreschnig [EMAIL PROTECTED] writes: [Thanks Joe and MJ, your replies were very helpful, and much appreciated.] On Tue, 2004-09-21 at 13:09, Roger Leigh wrote: The Gimp-Print User's Guide (package gimpprint-doc) is currently licensed under the terms of the GNU FDL. During discussion with gimp-print upstream about the potential problems with the GNU FDL and the possibility of relicensing it, a number of issues have cropped up, which I'd be grateful if you could assist with. I have pointed to Manoj's draft position statement as a summary of the issues with the FDL found to date, which we have been discussing. If the documentation was to remain GFDL licenced, would be possible to add a clarification to the licence in order to counter the main problems which would affect this work? The work is written in Docbook/SGML, and contains no invariant sections. I assume by no invariant sections you also mean no cover texts, acknowledgements, or dedications. Yes. Specifically, would it be possible to 1) Allow storage/transmission on encrypted filesystems/links to counter the DRM restriction? 2) Not require forcing distribution of transparent copies with bulk opaque copies? If these clarifications were to be made, would the licence be considered DFSG-free? Are there any other possible amendments that could be made to make the licence DFSG-free? Tentatively, I would say yes, this is free. Tentatively because I stopped paying too much attention to the specifics of the FDL after no one at the FSF seemed interested in resolving the more serious problems. Similar to how we only discovered the DRM issues after being hung up on invariants for a while, there might be some more nasty clauses hiding in the license that no one has noticed yet (especially given the complexity of it). OK. So, if were were to add something along the lines of As an exception to the GNU FDL, you are permitted to use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. The restrictions applied when copying in quantity (clause 3) are likewise exempted. would that be sufficient? Could exempting clause 3 be used to allow distributors not to provide source at all (which is not the intent--source should be available from the distributor, just not /forced/ to be provided whether you want it or not). However, this license is still not GPL-compatible, meaning text can't easily be moved from GIMP-Print itself (or other printing programs) into the documentation and vice versa. That is a concern. GPL cross-compatibility would be most desirable. Lastly, are there any alternative licences available? The author (and copyright holder) of the work would prefer a licence suited to documentation rather than programs (which I don't disagree with). I'm preparing a large amount of DocBook released under the GNU GPL, with the following notice: This document is licensed under the GNU General Public License version 2 as published by the Free Software Foundation. References to object code and executables in the GNU GPL are to be interpreted as the output of any document formatting or typesetting system, including intermediate and printed output. This license is GPL-compatible in both directions, and I don't see that it presents any serious problems just because I'm applying it to a non-program. Any license that tries to cater to some specifics of non-programs results in problems when you try to move text a document to a program and vice versa, which is a common case in software documentation. If upstream really needs a documentation-specific license, one possibility is releasing the documentation under a GFDL/GPL dual license. If the author does this, then we don't even need exceptions to the GFDL, because the GPL alone is free. This is a very neat solution, which I do like. It solves the GPL compatibility issues completely. Thanks for your help! Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFBUJVFVcFcaSW/uEgRAldJAKC2lRwwERU5GI/2LzMGNJpNrSH4egCfeoxU SCa0U6mdBbSMNTy3dq0AzYM= =NWme -END PGP SIGNATURE-
Re: Clarifying non-free parts of the GNU FDL
On Tue, 2004-09-21 at 15:55, Roger Leigh wrote: Joe Wreschnig [EMAIL PROTECTED] writes: Specifically, would it be possible to 1) Allow storage/transmission on encrypted filesystems/links to counter the DRM restriction? 2) Not require forcing distribution of transparent copies with bulk opaque copies? If these clarifications were to be made, would the licence be considered DFSG-free? Are there any other possible amendments that could be made to make the licence DFSG-free? Tentatively, I would say yes, this is free. Tentatively because I stopped paying too much attention to the specifics of the FDL after no one at the FSF seemed interested in resolving the more serious problems. Similar to how we only discovered the DRM issues after being hung up on invariants for a while, there might be some more nasty clauses hiding in the license that no one has noticed yet (especially given the complexity of it). OK. So, if were were to add something along the lines of As an exception to the GNU FDL, you are permitted to use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. The restrictions applied when copying in quantity (clause 3) are likewise exempted. would that be sufficient? Could exempting clause 3 be used to allow distributors not to provide source at all (which is not the intent--source should be available from the distributor, just not /forced/ to be provided whether you want it or not). Unfortunately, by exempting from that part of clause 2 and all of clause 3, you have removed the (weak) copyleft of the FDL entirely. Anyone could distribute opaque copies on restricted media and never need to provide source. The only way around this is to use a different license, or to rewrite those clauses of the FDL entirely. I *really* don't recommend that, because it makes the situation even more confusing, and there may be numerous problems in the rewritten clauses as well. If you need a copyleft, the GPL remains the strongest, free-est, and most understood of the ones I am aware of. I would encourage the manual's author (and everyone else, for that matter) to reconsider the necessity of a documentation-only license; despite numerous claims that the GPL doesn't work, I've yet to see anyone propose real problems. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Clarifying non-free parts of the GNU FDL
On Tue, Sep 21, 2004 at 07:09:18PM +0100, Roger Leigh wrote: Specifically, would it be possible to 1) Allow storage/transmission on encrypted filesystems/links to counter the DRM restriction? 2) Not require forcing distribution of transparent copies with bulk opaque copies? If these clarifications were to be made, would the licence be considered DFSG-free? Are there any other possible amendments that could be made to make the licence DFSG-free? There are a few more clauses you need to waive (they're fairly boring and pointless clauses; I can't imagine anybody caring about them being removed). There's a list around here somewhere. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: New MySQL Free/Libre and Open Source Software (FLOSS) Exception licence.... (re #242449)
On Tue, Aug 10, 2004 at 12:55:05AM +0200, Christian Hammers wrote: MySQL addressed this issue now by making yet another version of their FLOSS Exception license public which should resolve all problems. About the new issue, it could be of interest to understand if OpenSSL license can be considered as covered by this FLOSS Exception (1). Can it be considered so on the basis of Open Source Definitioni v 1.9? (2) http://www.mysql.com/products/licensing/foss-exception.html (1) http://www.opensource.org/docs/definition.php (2) -- Francesco P. Lovergine
Re: New MySQL Free/Libre and Open Source Software (FLOSS) Exception licence.... (re #242449)
On 10/08/2004 Christian Hammers wrote: The MySQL and its libraries has been put under the GPL (not LGPL) a while ago and since then conflicts with PHP etc which is not GPL compatible but still DFSG compliant (or so I understood). how exatly, is php itself not gpl compatible, or only the php scripts? if php itself is gpl compatible (sorry, i simply don't know), the problem is about php-scripts not being gpl compatible? or is it the php package not being gpl compatible, but linked against mysql? what about python, do we have similar problems there? bye jonas
Re: New MySQL Free/Libre and Open Source Software (FLOSS) Exception licence.... (re #242449)
Jonas Meurer said on Tue, Aug 10, 2004 at 03:00:21AM +0200,: how exatly, is php itself not gpl compatible, or only the php scripts? From http://www.gnu.org/philosophy/license-list.html:- quote This license is used by most of PHP4. It is a non-copyleft free software license which is incompatible with the GNU GPL. We recommend that you not use this license for anything except PHP add-ons. /quote -- Mahesh T. Pai http://paivakil.port5.com free - (adj) able to act at will; not hampered; not under compulsion or restraint; free from obligations or duties; not bound to servitude; at liberty.
Re: CeCILL license : Free Software License for french research
Lucas Nussbaum wrote: On Tue, Jul 06, 2004 at 11:24:29PM +0200, Florian Weimer [EMAIL PROTECTED] wrote: * Lucas Nussbaum: IANAL, but the license[4] look quite ok for me, even if the part about GPL compatibility seems a bit unclear. It looks like a fallback close similar to the LGPL. My french is rusty, though, I shouldn't try to interpret contracts. 8- Alex Hudson [EMAIL PROTECTED] was able to find the english version of the license. It's here : http://www.inria.fr/valorisation/logiciels/Licence.CeCILL-V1.US.pdf I didn't even bother to read most of it; it's too damn long. Clause 5.3.4 should render it GPL-compatible. However, dammit, GPL is *not defined* in the license; it should be defined up top. This is a license bug. -- There are none so blind as those who will not see.
Re: CeCILL license : Free Software License for french research
On 2004-07-11 15:54:05 +0100 Francesco Poli [EMAIL PROTECTED] wrote: This looks like a weak definition of source code: what is *required* so as to modify a program written in C? I agree, this looks like a lawyerbomb. Moreover, I think it should say explicitly the GNU General Public License as published by the Free Software Foundation and specify one or more versions. Agreed. Maybe version specifier should be latest available version on the date of relicensing, or any later version? Do I understand this correctly? The Holder guarantees he/she will go on distributing the Initial Software until copyright expires: that's really a long time... :-? I wonder that too. What happens if the holder violates this? -- MJR/slefMy Opinion Only and not of any group I know http://www.ttllp.co.uk/ for creative copyleft computing Matthew Garrett is quite the good sort of fellow, despite what my liver is sure to say about him in [...] 40 years -- branden
Re: CeCILL license : Free Software License for french research
On Tue, 06 Jul 2004 16:19:57 -0700 Josh Triplett wrote: Lucas Nussbaum wrote: [...] Alex Hudson [EMAIL PROTECTED] was able to find the english version of the license. It's here : http://www.inria.fr/valorisation/logiciels/Licence.CeCILL-V1.US.pdf For ease of quoting and commentary, here is a text version, converted using pdftotext along with some manual reformatting. This is very much appreciated, TNX! [...] FREE SOFTWARE LICENSING AGREEMENT CeCILL Notice [...] Version 1 of 06/21/2004 CeCILL License PREAMBLE [...] In this respect, the user's attention is drawn to the risks associated with loading, using, modifying and/or developing or reproducing the software by the user in light of its specific status of free software, that may mean that it is complicated to manipulate, and that also therefore means that it is reserved for developers and experienced professionals having in-depth IT knowledge. I don't like this warning very much. It seems to strengthen the free software is for techies only misconception: IMHO free software is for anyone who is willing to appreciate it! But anyway... [...] This Agreement may be freely reproduced and published, provided it is not altered, and that no Articles are either added or removed herefrom. So you cannot create derivative licenses based on this one. [...] Version 1 of 06/21/2004 CeCILL License Article 1 -- DEFINITION [...] Source Code: means all the Software's instructions and program lines to which access is required so as to modify the Software. This looks like a weak definition of source code: what is *required* so as to modify a program written in C? Someone could argue that the C source files are not *required*, since you can modify the program starting from the executable: you only have to use a disassembler, a text editor and an assembler... Therefore, someone could claim he/she is distributing Source Code, while he/she is actually passing on a binary only package... [...] Article 3 -- ACCEPTANCE 3.1. The Licensee shall be deemed as having accepted the terms and conditions of this Agreement by the occurrence of the first of the following events: - (i) loading the Software by any or all means, notably, by downloading from a remote server, or by loading from a physical medium; So I accept the license as soon as I download the package. Even if I haven't had *any* opportunity to read it in advance? :-/ - (ii) the first time the Licensee exercises any of the rights granted hereunder. This is pretty similar to the GPL, instead... 3.2. One copy of the Agreement, containing a notice relating to the specific nature of the Software, to the limited warranty, and to the limitation to use by experienced users has been provided to the Licensee prior to its acceptance as set forth in Article 3.1 hereinabove, and the Licensee hereby acknowledges that it is aware thereof. This is not clear to me. Is it a requirement? One copy of the Agreement [...] has been provided to the Licensee [...] seems a factual statement, not a permission, nor a condition... Does it mean that a distributor must make sure that recipients read the license and acknowledge their awareness, *before* events (i) or (ii) from Article 3.1 occur? 4.2. TERM The Agreement shall remain in force during the whole legal term of protection of the economic rights over the Software. Until copyright expires, right? [...] Article 5 -- SCOPE OF THE RIGHTS GRANTED [...] Otherwise, the Licensor grants to the Licensee free of charge exploitation rights on the patents he holds on whole or part of the inventions implemented in the Software. IIUC, this a copyright *and* patent license at the same time... [...] 5.2. ENTITLEMENT TO MAKE CONTRIBUTIONS The right to make Contributions includes the right to translate, adapt, arrange, or make any or all modification to the Software, and the right to reproduce the resulting Software. The Licensee is authorized to make any or all Contribution to the Software provided that it explicitly mentions its name as the author of said Contribution and the date of the development thereof. This seems similar to the GPL#2a, but it says explicitly that the Contributor's name must be mentioned. Would a pseudonym suffice? Does this pass the dissident test? [...] 5.3.3. REDISTRIBUTION OF DYNAMIC MODULES When the Licensee has developed a Dynamic Module, the terms and conditions hereof do not apply to said Dynamic Module, that may be distributed under a separate Licensing Agreement. This seems somewhat similar to the LGPL (lack of) conditions for linking. 5.3.4. COMPATIBILITY WITH THE GPL LICENSE In the event that the Modified or unmodified Software includes a code that is subject to the provisions of the GPL License, the Licensee is authorized to redistribute the whole under the GPL License. In the event that the Modified Software includes a code that is subject to the
Re: CeCILL license : Free Software License for french research
On Tue, Jul 06, 2004 at 08:36:10PM -0700, Josh Triplett [EMAIL PROTECTED] wrote: The license also contains many clauses that suggest a belief that the license controls _use_ of the software, which has no backing in (US, at least) copyright law. While these clauses do not seem to be non-free, they do set a bad example. One of the goals was to create a license which is compatible with french law. (It isn't clear whether the GPL is.) However, all that is most likely a non-issue, given: 5.3.4. COMPATIBILITY WITH THE GPL LICENSE In the event that the Modified or unmodified Software includes a code that is subject to the provisions of the GPL License, the Licensee is authorized to redistribute the whole under the GPL License. In the event that the Modified Software includes a code that is subject to the provisions of the GPL License, the Licensee is authorized to redistribute the Modified Software under the GPL License. This clause seems to clearly allow usage of the licensed software under the GPL, which would remove any issues of Freeness with the rest of the license. IANAL, but I'm not sure of this clause. I find it too vague. 1) GPL is never explained. Any license named GPL would suit ? Like the Grr Pfff Lol License ? 2) Which version of GPL should be used ? Any ? The current version ? The current version or any later ? This could cause problems when integrating CeCILLed software into GPLed apps. What do you think of this ? -- | Lucas Nussbaum | [EMAIL PROTECTED][EMAIL PROTECTED]GPG: 1024D/023B3F4F | | jabber: [EMAIL PROTECTED] http://www.lucas-nussbaum.net | | fingerprint: 075D 010B 80C3 AC68 BD4F B328 DA19 6237 023B 3F4F |
Re: CeCILL license : Free Software License for french research
On Wed, 07 Jul 2004, Lucas Nussbaum wrote: One of the goals was to create a license which is compatible with french law. (It isn't clear whether the GPL is.) Presumably you're obliquely invoking droit d'auteur as the reason for incompatibility; ideally the vagaries of one locality's legal system shouldn't result in a license that is not free in localities unencumbered with the same. That is, a license which contains additional restrictions on what you can do in all jurisdictions simple to appease one is suboptimal, and likely non-free. [I'd imagine that wording like the no warranty parachutes which automatically bring the license into alignment with the local jurisdiction to be superior to limiting everyone globally.] 5.3.4. COMPATIBILITY WITH THE GPL LICENSE I'm not sure of this clause. I find it too vague. 1) GPL is never explained. Any license named GPL would suit ? Like the Grr Pfff Lol License ? Since this describes a superset of GPL(s) of which the GNU General Public License is one, I'd imagine it would work for our purposes. 2) Which version of GPL should be used ? Any ? The current version ? The current version or any later ? This could cause problems when integrating CeCILLed software into GPLed apps. Yes. It would have been optimal if the GPL itself allowed for incrementing versions by default unless overridden in the licensing. This should probably be clarified in the interest of sanity for those combining works under the CeCILL with works under the GPL. Don Armstrong -- Personally, I think my choice in the mostest-superlative-computer wars has to be the HP-48 series of calculators. They'll run almost anything. And if they can't, while I'll just plug a Linux box into the serial port and load up the HP-48 VT-100 emulator. -- Jeff Dege, [EMAIL PROTECTED] http://www.donarmstrong.com http://rzlab.ucr.edu
Re: CeCILL license : Free Software License for french research
* Lucas Nussbaum: IANAL, but the license[4] look quite ok for me, even if the part about GPL compatibility seems a bit unclear. It looks like a fallback close similar to the LGPL. My french is rusty, though, I shouldn't try to interpret contracts. 8-
Re: CeCILL license : Free Software License for french research
On Tue, Jul 06, 2004 at 11:24:29PM +0200, Florian Weimer [EMAIL PROTECTED] wrote: * Lucas Nussbaum: IANAL, but the license[4] look quite ok for me, even if the part about GPL compatibility seems a bit unclear. It looks like a fallback close similar to the LGPL. My french is rusty, though, I shouldn't try to interpret contracts. 8- Alex Hudson [EMAIL PROTECTED] was able to find the english version of the license. It's here : http://www.inria.fr/valorisation/logiciels/Licence.CeCILL-V1.US.pdf -- | Lucas Nussbaum | [EMAIL PROTECTED][EMAIL PROTECTED]GPG: 1024D/023B3F4F | | jabber: [EMAIL PROTECTED] http://www.lucas-nussbaum.net | | fingerprint: 075D 010B 80C3 AC68 BD4F B328 DA19 6237 023B 3F4F |
Re: CeCILL license : Free Software License for french research
Lucas Nussbaum wrote: On Tue, Jul 06, 2004 at 11:24:29PM +0200, Florian Weimer [EMAIL PROTECTED] wrote: * Lucas Nussbaum: IANAL, but the license[4] look quite ok for me, even if the part about GPL compatibility seems a bit unclear. It looks like a fallback close similar to the LGPL. My french is rusty, though, I shouldn't try to interpret contracts. 8- Alex Hudson [EMAIL PROTECTED] was able to find the english version of the license. It's here : http://www.inria.fr/valorisation/logiciels/Licence.CeCILL-V1.US.pdf For ease of quoting and commentary, here is a text version, converted using pdftotext along with some manual reformatting. - Josh Triplett FREE SOFTWARE LICENSING AGREEMENT CeCILL Notice This Agreement is a free software license that is the result of discussions between its authors in order to ensure compliance with the two main principles guiding its drafting: - firstly, its conformity with French law, both as regards the law of torts and intellectual property law, and the protection that it offers to authors and the holders of economic rights over software. - secondly, compliance with the principles for the distribution of free software: access to source codes, extended user-rights. The following bodies are the authors of the license CeCILL1: Commissariat à l'Energie Atomique -- CEA, a public scientific, technical and industrial establishment, having its principal place of business at 31-33 rue de la Fédération, 75752 PARIS cedex 15. Centre National de la Recherche Scientifique -- CNRS, a public scientific and technological establishment, having its principal place of business at 3 rue Michel-Ange 75794 Paris cedex 16. Institut National de Recherche en Informatique et en Automatique -- INRIA, a public scientific and technological establishment, having its principal place of business at Domaine de Voluceau, Rocquencourt, BP 105, 78153 Le Chesnay cedex. 1 Ce: CEA, C: CNRS, I: INRIA, LL: Logiciel Libre Version 1 of 06/21/2004 CeCILL License PREAMBLE The purpose of this Free Software Licensing Agreement is to grant users the right to modify and redistribute the software governed by this license within the framework of an open source distribution model. The exercising of these rights is conditional upon certain obligations for users so as to ensure that this status is retained for subsequent redistribution operations. Nevertheless, access to the source code, and the resulting rights to copy, modify and redistribute only provide users with a limited warranty and the software's author, the holder of the economic rights, and the successive licensors only have limited liability. In this respect, the user's attention is drawn to the risks associated with loading, using, modifying and/or developing or reproducing the software by the user in light of its specific status of free software, that may mean that it is complicated to manipulate, and that also therefore means that it is reserved for developers and experienced professionals having in-depth IT knowledge. Users are therefore encouraged to load and test the Software's suitability as regards their requirements in conditions enabling the security of their systems and/or data to be ensured and, more generally, to use and operate it in the same conditions as regards security. This Agreement may be freely reproduced and published, provided it is not altered, and that no Articles are either added or removed herefrom. This Agreement may apply to any or all software for which the holder of the economic rights decides to submit the operation thereof to its provisions. 2 Version 1 of 06/21/2004 CeCILL License Article 1 -- DEFINITION For the purposes of this Agreement, when the following expressions commence with a capital letter, they shall have the following meaning: Agreement: means this Licensing Agreement, and any or all of its subsequent versions. Software: means the software in its Object Code and/or Source Code form and, where applicable, its documentation, as is at the time when the Licensee accepts the Agreement. Initial Software: means the Software in its Source Code and/or Object Code form and, where applicable, its documentation, as is at the time when it is distributed for the first time under the terms and conditions of the Agreement. Modified Software: means the Software modified by at least one Contribution. Source Code: means all the Software's instructions and program lines to which access is required so as to modify the Software. Object Code: means the binary files originating from the compilation of the Source Code. Holder: means the holder of the economic copyright over the Initial Software. Licensee(s): mean(s) the Software user(s) having accepted the Agreement. Contributor: means a Licensee having made at least one Contribution. Licensor: means the Holder, or any or all other individual or legal entity, that distributes the Software under the Agreement. Contributions: mean any or all
Re: CeCILL license : Free Software License for french research
On 2004-07-07 00:19:57 +0100 Josh Triplett [EMAIL PROTECTED] posted: FREE SOFTWARE LICENSING AGREEMENT CeCILL First off, I was told again today that French has no direct equivalent word for software. Logiciel only means program. I've no idea what other words don't translate. Basically: Beware. [...] 4.2. TERM The Agreement shall remain in force during the whole legal term of protection of the economic rights over the Software. [...] and that, in the event that only the Software's Object Code is redistributed, the Licensee allows future Licensees unhindered access to the Software's full Source Code by providing them with the terms and conditions for access thereto, it being understood that the additional cost of acquiring the Source Code shall not exceed the cost of transferring the data. Possible practical problem: do we have to allow access for the entire term of the agreement, which could be until the copyright expires? [...] 13.2. In the absence of an out-of-court settlement within two (2) months as from their occurrence, and unless emergency proceedings are necessary, the disagreements or disputes shall be referred to the Paris Courts having jurisdiction, by the first Party to take action. Here we go again. Are these you will use *my* court terms acceptable or not? :-/ (By the way, comrade Garrett, it was Oslo not Amsterdam.) -- MJR/slefMy Opinion Only and not of any group I know http://www.ttllp.co.uk/ for creative copyleft computing To be English is not to be baneful / To be standing by the flag not feeling shameful / Racist or partial... (Morrissey)
Re: CeCILL license : Free Software License for french research
On Wed, Jul 07, 2004 at 02:22:51AM +0100, MJ Ray wrote: Here we go again. Are these you will use *my* court terms acceptable or not? :-/ It also has a bogus breathing, eating or talking means you agree to this clause, and it's annoyingly long for a free license. If there aren't any problems with the apparent dual-licensing with the GPL, though, then it's free. That clause, much like the rest of the license, is strange; I don't know if that's a result of translation or lawyers, but it should probably be looked at on its own. 5.3.4. COMPATIBILITY WITH THE GPL LICENSE In the event that the Modified or unmodified Software includes a code that is subject to the provisions of the GPL License, the Licensee is authorized to redistribute the whole under the GPL License. In the event that the Modified Software includes a code that is subject to the provisions of the GPL License, the Licensee is authorized to redistribute the Modified Software under the GPL License. -- Glenn Maynard
Re: CeCILL license : Free Software License for french research
Glenn Maynard wrote: On Wed, Jul 07, 2004 at 02:22:51AM +0100, MJ Ray wrote: Here we go again. Are these you will use *my* court terms acceptable or not? :-/ Not, in my opinion. It also has a bogus breathing, eating or talking means you agree to this clause, and it's annoyingly long for a free license. Not to mention other possibly non-free clauses: 6.2. OVER THE CONTRIBUTIONS The intellectual property rights over the Contributions are attached to the holder of the economic rights as designated by effective legislation. It is unclear whether this means the holder of the rights over the Contributions (since it doesn't use the capitalized term Holder), in which case it is a no-op, or whether it means that rights are assigned to the holder of the original rights, in which case it is an attempt at a mandatory copyright assignment, and non-free. I suspect the former meaning, but the clause is not clear enough to be certain. 6.4.2. The Licensee undertakes not to directly or indirectly infringe the intellectual property rights of the Holder and/or Contributors and to take, where applicable, vis-à-vis its staff, any or all measures required to ensure respect for said intellectual property rights of the Holder and/or Contributors. This seems far too broad to be Free. The license also contains many clauses that suggest a belief that the license controls _use_ of the software, which has no backing in (US, at least) copyright law. While these clauses do not seem to be non-free, they do set a bad example. However, all that is most likely a non-issue, given: If there aren't any problems with the apparent dual-licensing with the GPL, though, then it's free. That clause, much like the rest of the license, is strange; I don't know if that's a result of translation or lawyers, but it should probably be looked at on its own. 5.3.4. COMPATIBILITY WITH THE GPL LICENSE In the event that the Modified or unmodified Software includes a code that is subject to the provisions of the GPL License, the Licensee is authorized to redistribute the whole under the GPL License. In the event that the Modified Software includes a code that is subject to the provisions of the GPL License, the Licensee is authorized to redistribute the Modified Software under the GPL License. This clause seems to clearly allow usage of the licensed software under the GPL, which would remove any issues of Freeness with the rest of the license. However, there is one more clause to consider before the license can be considered Free by conversion to the GPL: 11.5. LANGUAGE The Agreement is drafted in both French and English. In the event of a conflict as regards construction, the French version shall be deemed authentic. So someone versed in legalistic French needs to read the French version of the license and check that clause 5.3.4 in that version clearly allows conversion to the GPL. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: definitions of free
On Sat, 2004-07-03 at 10:42, Josh Triplett wrote: Consider this sentence from the GNU Project's Free Software Definition: It is also acceptable for the license to require that, if you have distributed a modified version and a previous developer asks for a copy of it, you must send one. Any software with such a requirement would be non-DFSG-free. So that's not an appropriate restriction, at least according to the DFSG? What if it were just must be emailed - eg. if it were must be posted then the cost could be prohibitive for someone in the 3rd world right? But email, that should approach zero cost right? So the question is, is such a restriction appropriate/ moral? If it is not, why not? If it can be, under what circumstances? If so, then perhaps it's time for another GR (don't worry, IANA DD, so I can't actually propose such myself, yet :) tia zen
Re: definitions of free
On Sat, 03 Jul 2004 23:55:23 +1000 Zenaan Harkness wrote: On Sat, 2004-07-03 at 10:42, Josh Triplett wrote: Consider this sentence from the GNU Project's Free Software Definition: It is also acceptable for the license to require that, if you have distributed a modified version and a previous developer asks for a copy of it, you must send one. Any software with such a requirement would be non-DFSG-free. So that's not an appropriate restriction, at least according to the DFSG? True: it's not an acceptable restriction, from the DFSG point of view. What if it were just must be emailed - eg. if it were must be posted then the cost could be prohibitive for someone in the 3rd world right? But email, that should approach zero cost right? I don't think it's a matter of cost, but rather a matter of being forced to do something in case you previously performed a particular operation. At least, it seems to me that the above requirement would fail the desert island test[1]. [1] See http://people.debian.org/~bap/dfsg-faq.html for details about the desert island test. -- | GnuPG Key ID = DD6DFCF4 | You're compiling a program Francesco |Key fingerprint = | and, all of a sudden, boom! Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO, | 31B5 78F4 279B DD6D FCF4 | version 1.8.0 pgpNlqoxmBCEG.pgp Description: PGP signature
Re: definitions of free
Zenaan Harkness writes: Assumption: There will forever be different definitions of free. Question: what would it take to provide to the user the option to choose FSF Free as well as DFSG Free (and perhaps OSI) as the set of packages they wish to install? What would be the specific benefit to users of doing this? There are two significant and unavoidable costs to provide this feature: The infrastructure support for it and the policy work for it. The infrastructure support would be adding headers to all packages to identify their type(s) of freeness, and updating tools to support that. Is it worth the effort to support this when other projects (X, AMD64, etc) could use the manpower in ways that are clearly beneficial to Debian's users? The policy work involves the actual identification of freeness. DFSG-free is a (I believe strict) subset of OSI-free, and probably a superset of FSF-free. Why probably? See the disagreement over packages like upstream Linux. Debian can (and has) clarified the DFSG to resolve ambiguity; since Debian defines the DFSG, it is the obvious arbiter for interpretation of the DFSG. Who would arbitrate for other types of freeness? I see both the infrastructure and policy issues as being significant reasons to *not* identify packages as FSF Free or OSI Free or anything except DFSG Free (as in main vs non-free). It would take some very big benefits to users to outweigh those cons. Michael
Re: definitions of free
On Fri, 02 Jul 2004 17:57:57 -0400 Michael Poole wrote: The policy work involves the actual identification of freeness. DFSG-free is a (I believe strict) subset of OSI-free, and probably a superset of FSF-free. I don't think that DFSG-free is a superset of FSF-free. For non-programs there is no doubt, IMHO, (see GFDL, verbatim-copying, ...). For programs, I don't know: I don't have the time now to scan the FSF list of free program licenses and see if they include some that Debian considers non-free. [...] I see both the infrastructure and policy issues as being significant reasons to *not* identify packages as FSF Free or OSI Free or anything except DFSG Free (as in main vs non-free). I agree: it would be too complicated. -- | GnuPG Key ID = DD6DFCF4 | You're compiling a program Francesco |Key fingerprint = | and, all of a sudden, boom! Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO, | 31B5 78F4 279B DD6D FCF4 | version 1.8.0 pgpHWy486qs0d.pgp Description: PGP signature
Re: definitions of free
On Sat, 2004-07-03 at 07:57, Michael Poole wrote: Zenaan Harkness writes: Assumption: There will forever be different definitions of free. Question: what would it take to provide to the user the option to choose FSF Free as well as DFSG Free (and perhaps OSI) as the set of packages they wish to install? The infrastructure support would be adding headers to all packages to identify their type(s) of freeness, and updating tools to support that. Perhaps just a license field - but the infrastructure does seem non-trivial.
Re: definitions of free
Francesco Poli wrote: On Fri, 02 Jul 2004 17:57:57 -0400 Michael Poole wrote: The policy work involves the actual identification of freeness. DFSG-free is a (I believe strict) subset of OSI-free, and probably a superset of FSF-free. I don't think that DFSG-free is a superset of FSF-free. For non-programs there is no doubt, IMHO, (see GFDL, verbatim-copying, ...). For programs, I don't know: I don't have the time now to scan the FSF list of free program licenses and see if they include some that Debian considers non-free. Consider this sentence from the GNU Project's Free Software Definition: It is also acceptable for the license to require that, if you have distributed a modified version and a previous developer asks for a copy of it, you must send one. Any software with such a requirement would be non-DFSG-free. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: definitions of free
On 2004-07-02 22:28:54 +0100 Zenaan Harkness [EMAIL PROTECTED] wrote: Question: what would it take to provide to the user the option to choose FSF Free as well as DFSG Free (and perhaps OSI) as the set of packages they wish to install? Add to apt and friends some way to categorise packages other than by data from the archive index they appear in, then get FSF to publish package categorisations. The apt bit may be possible already: I don't know OTTOMH and haven't looked it up. -- MJR/slefMy Opinion Only and not of any group I know http://www.ttllp.co.uk/ for creative copyleft computing To be English is not to be baneful / To be standing by the flag not feeling shameful / Racist or partial... (Morrissey)
Re: reiser4 non-free?
[EMAIL PROTECTED] wrote: On Tue, 11 May 2004 10:57:01 PDT, Hans Reiser said: Random credits are the elegant answer. Displaying only the distro name at boot time is morally wrong. Would be nice - the RedHat/Fedora GUI installer already supports showing the current install status in one pane, and scrolling through a bunch of blurbs in another. It might be possible to get (at least) the Fedora side of the fence to include blurbs for the package contributors as well... That would be really nice.
Re: reiser4 non-free?
Brian Thomas Sniffen [EMAIL PROTECTED] writes: Jeremy Hankins [EMAIL PROTECTED] writes: Brian Thomas Sniffen [EMAIL PROTECTED] writes: In other words, some works under this license are free (for example, one containing no credits but the copyright notice) and others are non-free. Wouldn't such a work still be non-free? At the least, it definitely goes much farther than the analogous clause in the GPL. You can't include code (even optionally executed code) to suppress it, for example. If there are no credits, the prohibition on removing credits is null. Yes, but there's still the format placement of the copyright notice. E.g., the fact that it's printed regardless of input and interactivity. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
