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
Panda3d Public License?
Has anyone looked at Disney's Panda3d Public License Version 2.0? http://www.panda3d.org/license.php Clause 4 seems worrysome (requires sending signifigant changes to Disney). Other parts seem redundant with copyright law. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Panda3d Public License?
Arc Riley [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Has anyone looked at Disney's Panda3d Public License Version 2.0? http://www.panda3d.org/license.php Clause 4 seems worrysome (requires sending signifigant changes to Disney). Other parts seem redundant with copyright law. Well Looking closely at the relevent clause: An electronic copy of the source code for major modifications that You make to the Software should be forwarded to Licensor at [EMAIL PROTECTED] as soon as the modifications are significant or stable enough for Licensor's evaluation for possible future distribution. Alternatively, you may notify Licensor of a location from which the modifications are available and may be downloaded by Licensor at Licensor's election. If by should they mean: You are Strongly Encouraged, then the clause is probbably acceptable. Disney should be contacted for clarifiation. Also Clause 4 has this potentially troubling line: In addition, You must identify Yourself as the originator of the modifications You made to the Software, if any, in a manner that reasonably allows subsequent recipients to identify You as the originator of the modifications. It is unclear if this requires identification by name, or if identification by psuedonym is acceptable. Clause 10 is troubling as it madates following US export control laws. That should not be a problem if Dinsney will clarify this as not being a binding clause of the licence, but is merely a non-binding reminder of the relevent US law. It would be good to remind disney that they do not intend to sue over violation of that clause, so it need not be a binding clause of the licence. Other portentially problematic clauses are clause 11, which appears to be choice of venue. All other clauses look fine to me. Most of them appear in more or less the same form in other accepted licences. So with a few clarifications from Disney, the licence could be compatable with the DFSG except potentially for choice of venue. IANAL, INADD. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GFDL'ed documents with Front Cover text
Hi, Frank said: 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 [...] What should the developers do in order to make it DFSG-free [...] This implies that a document with no invariant sections, but with one-sentence front- and back-cover sections does not meet the DFSG? Is that Debian's position? For example, GMP has Front-Cover Text A GNU Manual and Back-Cover Text You have freedom to copy and modify this GNU Manual, like GNU software and no invariant sections. Must I really throw this document out of Debian (BTS 335403)? Regards, -Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GFDL'ed documents with Front Cover text
Steve M. Robbins wrote: Frank said: 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 [...] What should the developers do in order to make it DFSG-free [...] This implies that a document with no invariant sections, but with one-sentence front- and back-cover sections does not meet the DFSG? Is that Debian's position? Yes, by the project-wide GR such a document does not meet the DFSG: This means that works that don't include any Invariant Sections, Cover Texts, Acknowledgements, and Dedications (or that do, but permission to remove them is explicitly granted), are suitable for the main component of our distribution. Steve M. Robbins wrote: For example, GMP has Front-Cover Text A GNU Manual and Back-Cover Text You have freedom to copy and modify this GNU Manual, like GNU software and no invariant sections. Must I really throw this document out of Debian (BTS 335403)? Yes. You could package it separately in non-free, however. - Josh Triplett signature.asc Description: OpenPGP digital signature
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: GFDL'ed documents with Front Cover text
Steve M. Robbins [EMAIL PROTECTED] This implies that a document with no invariant sections, but with one-sentence front- and back-cover sections does not meet the DFSG? Is that Debian's position? Debian's position is: : that works that don't include any Invariant Sections, Cover Texts, : Acknowledgements, and Dedications (or that do, but permission to remove : them is explicitly granted), are suitable for the main component of : our distribution. -- http://www.debian.org/vote/2006/vote_001#amendmenttexta Otherwise, I think they aren't suitable for main, as before. For example, GMP has Front-Cover Text A GNU Manual and Back-Cover Text You have freedom to copy and modify this GNU Manual, like GNU software and no invariant sections. Must I really throw this document out of Debian (BTS 335403)? Including that document in Debian is a bug. If upstream won't fix the bug, I can't see how you can, sadly. -- 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: Results for Debian's Position on the GFDL
Raul Miller [EMAIL PROTECTED] It's not clear to me that the GFDL prohibits DRM where a parallel distribution mechanism is guaranteed to be available. The copying to the DRM-controlled media seems expressly prohibited. If free parallel distribution is guaranteed to be available, relevant, and convenient, it's not clear to me how any technical measures could be said to be controlling the copying or reading of the material. The troublesome clause of the FDL says of the copies not of the material. Please try to use the licence, not random translations. If the licence is worded incorrectly, that is still a problem that needs fixing. Anyways, what field of use is it that specifically concerns itself with limiting other people's rights to make copies of software? Use on DRM-only devices. Isn't a licence which effectively says you may not use this on $CLASS_OF_DEVICES failing DFSG? -- 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: better licence for fosdem, debconf, .., videos...
Francesco Poli [EMAIL PROTECTED] On the other hand, kernel-image-2.6.8-2-386.deb by the Debian kernel team, based on the Linux kernel by Linus Torvalds and others seems to be accurate credit, doesn't it? It's an arguably accurate description, but strikes me as an arguably misleading credit. [...] I agree with that advice. Some licensors have drunk CC deeply and will not move, so I suggest that CC-sco is a possible compromise route until a fixed CC 3.x is finally published. Please do not tell me that we must compromise our principles while waiting for things to get magically fixed. Depends what principle. I do not suggest compromising on the DFSG, but I do suggest compromising over exactly which licence to use to as the basis for meeting the DFSG. I'm already deeply disappointed by the Debian project for taking such decision with GR-2006-001... :-((( I think it remains to be seen which decision the project took. The position statement issued was vague at best, contradictory at worst, and has caused ripples which I think will provoke another vote. Any fools who ranked Further Discussion insincerely low and produced a bad compromise will get what they least wanted: further discussion and more voting as some DDs to try to still this chaos produced by imposing order. http://mjr.towers.org.uk/blog/2006/fdl#rankfdhigh -- 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: FYI: Savannah seems to reject GPLv2 only projects
Francesco Poli [EMAIL PROTECTED] On Wed, 22 Mar 2006 11:28:03 + MJ Ray wrote: Long term, hosting it yourself under a distributed RCS and using something like DOAP to keep project metadata seems the best bet. If others would like to help document the tools and methods, please let me know and we can make it a proof-of-concept project, hack support into existing hosts and that sort of thing. I had a bit of an attempt with coopX some years ago, but it was too early and didn't take off. I'm not sure I understand what you mean. When you say distributed RCS, are thinking about distributed versioning systems such as Bazaar[1] or GNU Arch? or Darcs or Monotone or ... Personally, I've avoided Bazaar, but they all give ways for developers to collaborate easily. Even mailing diffs beats waiting for some repository in a far-away land to synchronise with your machine and the poor permission structure of some services. If you have collaborators, ask them what they need. If you don't yet, leave the way open to users of other systems by producing tarballs and patches regularly. Doesn't they need at least one networked machine to make patchsets (or the like) available to the public? Yes. Some can upload to any old web or ftp space (tla can, for example), so you don't need the networked machine to run the software. It can be really dumb if you want, like an ISP's free space. Hope that helps, -- 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: Results for Debian's Position on the GFDL
On 3/25/06, MJ Ray [EMAIL PROTECTED] wrote: Raul Miller [EMAIL PROTECTED] It's not clear to me that the GFDL prohibits DRM where a parallel distribution mechanism is guaranteed to be available. The copying to the DRM-controlled media seems expressly prohibited. Only if these copies are are made available to people whose use would be controlled by the DRM. If you want to make copies on DRM-controlled media, that's fine. But you're not controlling your own access to the media this way. If you make the copies available to someone else, though, you should make sure that you're not imposing controls. If free parallel distribution is guaranteed to be available, relevant, and convenient, it's not clear to me how any technical measures could be said to be controlling the copying or reading of the material. The troublesome clause of the FDL says of the copies not of the material. Please try to use the licence, not random translations. If the licence is worded incorrectly, that is still a problem that needs fixing. You're nitpicking. the material is a phrase which refers to the content of the copies. Also, that's just a part of the sentence. Please don't ignore the rest of the sentence, which says what it is significant in the context of those copies. Anyways, what field of use is it that specifically concerns itself with limiting other people's rights to make copies of software? Use on DRM-only devices. Isn't a licence which effectively says you may not use this on $CLASS_OF_DEVICES failing DFSG? That's not what it says. It says you are not allowed to use $CLASS_OF_DEVICES in ways that (obstruct or control) the (reading or further copying) of the copies you (make or distribute). It's probably worth noting that the word or here is not the logical or used in hardware and software design, but is instead the english word where two modes of expression are meant to describe the same concept. I recognize that by using the computer design or concept you can stretch the meaning of this sentence into something ludicrous (like the idea that your own exercise of free will constitutes control in the sense meant by the above sentence), but I haven't seen any solid reasoning that says that these ludicrous interpretations are valid. -- Raul
