Re: GFDL - status?
On Sun, 13 Jul 2003, MJ Ray wrote: Steve Langasek [EMAIL PROTECTED] wrote: Is my license which requires you to buy a jar of pickle relish every time you run the program a free software license? The act of running the program is not restricted by a copyright licence, so would that even be a valid licence? Acts of usage are restricted by many software licenses. I'm not aware of one that has been successfully defended, as they're primarily used against competitors, not users, but it's definetly possible. Obviously, such a license would be non-free though. [At least, I hope it's obvious.] Don Armstrong -- Of course, there are ceases where only a rare individual will have the vision to perceive a system which governs many people's lives; a system which had never before even been recognized as a system; then such people often devote their lives to convincing other people that the system really is there and that it aught to be exited from. -- Douglas R. Hofstadter _Gödel Escher Bach. Eternal Golden Braid_ http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu pgpgQORsm0kFG.pgp Description: PGP signature
GFDL and man pages
I am working on a package (csound) that has no manpages or documentation of any sort (include --help) in the source archive. There is, however, a detailed reference manual[1] with the GFDL license that includes command-line program documentation[2,3]. There are no invariant or cover sections, but there is an Acknowledgements section. Am I safe to make manpages from this reference manual? Would that be a derivative work? What attribution do I need to include and where (in the manpages themselves, or in the copyright file, etc.)? Thanks, Hans 1. http://kevindumpscore.com/docs/csound-manual/ 2. http://kevindumpscore.com/docs/csound-manual/commandtop.html 3. http://kevindumpscore.com/docs/csound-manual/utilitytop.html -- Hans Fugal | De gustibus non disputandum est. http://hans.fugal.net/ | Debian, vim, mutt, ruby, text, gpg http://gdmxml.fugal.net/ | WindowMaker, gaim, UTF-8, RISC, JS Bach - GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460 pgpqm873yeP9U.pgp Description: PGP signature
Re: Bug#200411: www.debian.org: confusing description of non-US sections
On Mon, Jul 07, 2003 at 09:59:34PM -0700, Matt Kraai wrote: On Tue, Jul 08, 2003 at 02:24:25PM +1000, Ben Finney wrote: The packages page at http://www.debian.org/distrib/packages currently says: = Non-US/Main and Non-US/Non-Free These packages cannot be exported from the USA, they are mostly encryption software packages, or software that is encumbered by patent issues. Most of them are free, but some are non-free. = The point about encryption software is out of date since we can get any crypto software exported from the USA these days. The last sentence is needlessly vague. The thread http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00029.html documents the exact rationale for these sections. The following patch incorporates its conclusions into the packages page. I'd appreciate it if the readers of debian-legal would double-check it. What I saw in that thread was Wichert saying that things in non-US needed to be there because of patents, and Steve Langasek saying that that those things needed to be in non-US/non-free. That's not what I see below. -dtemNon-US/Main/em and emNon-US/Non-Free/em/dt - ddThese packages cannot be exported from the USA, they are mostly - encryption software packages, or software that is encumbered by - patent issues. Most of them are free, but some are non-free./dd +dtemNon-US/Main/em/em/dt + ddPackages in this area are free themselves but cannot be + stored on a server in the USA because they are encumbered by + patent issues./dd Things in main or non-US/main should not be patent encumbered. non-US/main is designed so that packages can be imported into the US, but not exported. If it would not fit the DFSG for any reason, including being patent-encumbered in the US or other places, then it does not belong in non-US/main. +dtemNon-US/Non-Free/em/dt + ddPackages in this area do not necessarily cost money, but + have some onerous license condition restricting use or + redistribution of the software. They cannot be exported from + the USA because they are encryption software packages or they + cannot be stored on a server in the USA because are encumbered + by patent issues./dd Things that belong in non-US, but are patent-encumbered or otherwise fail to meet the DFSG for any reason belong in non-US/non-free. This includes things that would be eligible for the crypto-in-main transition were they free, but in fact are not. For example, IDEA code belongs here. One final nitpick: please properly capitalize non-US, non-free, and main. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpUPkuGEhY7M.pgp Description: PGP signature
Re: GFDL and man pages
On Tue, 2003-07-15 at 12:02, Walter Landry wrote: This is a summary of what you have to do. The detailed requirements are in section 4 of the GFDL. Note that this all has to be _in_ the manpage. This may or may not make the manpage useless. You also have to include the Transparent version of the manpage, which is presumably whatever format you used to create it in. And some people wonder why I hate the GFDL. If you have treelang-3.3 installed try info treelang to see how unfriendly relevant information lookup can become. If one simply spaces through the info documentation one presses space 47 times on an 80x25 terminal before reaching Getting Started. Regards, Adam
Re: GFDL and man pages
snipped explanation of why GFDL is not good for manpages In other words, you're better off writing your own manpage from scratch. It's probably OK to look at the manual to help figure out what various options do, as long as you then put the manual away and write the manpage entirely in your own words. That's just looking up facts. Including *text* from the manual would create a derivative work. You might also want to consider asking upstream to dual-license their manual under the same terms as their program. (If they did that, people could create --help text from the manual and put it in the program, so this might help convince them to do it.) -- Nathanael Nerode neroden at gcc.gnu.org http://home.twcny.rr.com/nerode/neroden/fdl.html
