Re: RFC about copyrights and right package section for W3C docs.
David Starner [EMAIL PROTECTED] writes: IPv6 and C99 didn't change IPv4 or C89, did they? Indeed, gcc 3.0 didn't automatically delete all copies of gcc 2.95 either, and MS-Windows 95 was not impacted by '98. Does that imply that these software packages are eternally fixed and never revised? I don't see the distinction. Are icons metadata? The name almost certainly is . . . but we made a special exception for name changes in the DFSG. Icons are not metadata. The author is metadata, as is the publisher, and when something was published. You can't take package X from main, change /usr/share/doc/X/copyright, and redistribute it (except for packages in the public domain). But that's fraud. We can't do that for legal and ethical reasons. That has nothing to do with removing some rant that the original author wrote. Have you actual examples of rants that are protected by FDL invariant sections to point at, or do you make this up while you go along? Now I'll make something up ... suppose I place the following short chapter under a don't remove this, you may add to it clause: * Acknowledgements Robert Bihlmeyer wants to thank Gnomovision for their support. They basically paid him to do nothing so he could write the Frobster3000 manual. Do you consider this DFSG-free? Is removing this less unethical than removing my name altogether? Now, down to earth. /usr/share/doc/info/copyright says: All manuals Copyright (C) 1988, 1990-1993, 1995-2001 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with the Front-Cover texts being ``A GNU Manual'', and with the Back-Cover Texts as in (a) below. A copy of the license is included in the section entitled ``GNU Free Documentation License'' in the Emacs manual. (a) The FSF's Back-Cover Text is: ``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.'' It's in main. Do you consider that non-free? From my viewpoint, its like BSD/advertising. Not pretty, but free. I don't see where metadata is specified in the DFSG, It isn't. But the DFSG don't state that every bit of a package must be modifiable, either. I take it that every functional part must be modifyable at least. except a specific exception for name changes. Actually (4) grants more exceptions. Finally, applying the Debian Free *Software* Guidelines may be a bit off, altogether. -- Robbe signature.ng Description: PGP signature
Re: RFC about copyrights and right package section for W3C docs.
[please cc me] David Starner [EMAIL PROTECTED] writes: If there's an exception for non-topical chapters, then why not for standards? Because these are completely different things, see below. A non-topical chapter is more likely to get out of date than a standard, which by design is intended to be eternally fixed. Clarification: the FDL restricts non-modification to quite specific sections, non-topicality is only one necessity. From the horses mouth: A ``Secondary Section'' is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. You can probably see now how information in these secondary sections does not get obsolete (only maybe uninteresting). The notion that standards do not get out of date can't be meant seriously in a world of SQL92, IPv6, C89, etc. etc. In any case, the DFSG offers exceptions for neither, so the non-modification clause in the GNU FDL is not _okay_ with the DFSG. By the strict reading of the DFSG, if it is to apply to documentation and RFC's, modificiation must be allowed. No. Modification to the content must be allowed ... certainly not modification to the metadata. You can't take package X from main, change /usr/share/doc/X/copyright, and redistribute it (except for packages in the public domain). Whether something is really metadata is a matter of interpretation, and may depend on the specific case. Personally, I think all those people/organisations that want to protect the sancticity of their standard should just require derivative works to bear different names (or versions). -- Robbe signature.ng Description: PGP signature
Re: RFC about copyrights and right package section for W3C docs.
[cc and reply-to more appropriate list] Richard Atterer [EMAIL PROTECTED] writes: On Sat, Sep 15, 2001 at 10:42:59AM +0200, Robert Bihlmeyer wrote: [doc-html-w3] That package is in non-free. IIRC the issue is that you can't modify the standards. Which is somewhat understandable, but still relegates them to non-free. Hm, but the Internet RFCs are in main and they don't allow unlimited modification, either: [...] So, should the RFCs go in non-free as well? Probably. See bug#92810, which probably needs more attention. AIUI, the GNU Open Publication License also allows authors to restrict the right of making modifications to parts of the documentation. Is that non-free, too??? There is no such thing. If you meant the GNU Free Documentation License, that one allows non-modification clauses only for non-topical chapters. So I think it is ok with DFSG. The documentation of the info and texinfo packages are placed under GNU FDL, and both are in main. Probably affects other packages as well. There's also the Open Publication License (not from GNU) which I am less familiar with. -- Robbe signature.ng Description: PGP signature
Re: lame (again!)
Marcelo E. Magallon [EMAIL PROTECTED] writes: Viral [EMAIL PROTECTED] writes: I would like clarify the reason for lame not being included in the debian archives, not even non-US. http://www.debian.org/devel/wnpp/unable-to-package IIRC your questions are addressed there. A few questions that are not covered in the linked discussion, nor in the postings to debian-legal that I digged up. What is (or can be) prevented by a patent? - Spreading information about an algorithm? - Writing code that implements an algorithm? - Distributing/publishing same code? - Using the code? Is there a difference between distributing source vs. binaries as regards patents? In this specific case, Fraunhofer IIS seems to focus on binaries, for some reason. (BladeENC is still distributed in source form, but no longer pre-compiled, see URL:http://bladeenc.mp3.no/skeleton/news.html) In how far is the mp3 patent different than the IDEA patent (or the RSA patent a until a few months ago)? We distributed and still distribute source/binaries implementing both of these technologies. Debian does not seem to care about /all/ patents (we probably couldn't distribute any software otherwise), only those that are actively enforced. But lame has been distributed (first as a patch, then as complete source) for considerable time, without major legal hassles, AFAIK. sourceforge (not exactly an off-shore, small-fish site) provided the lame CVS since 1999. Couldn't that be seen as evidence that distributing lame (at least in source form) is ok. Another minor point is that they claim to cover mp3 *de*coding in their patents as well. If Thomson gets its way, you'd have to pay a fee for every decoder, only those distributed free-of-charge over the net are exempted (URL:http://www.mp3licensing.com/royalty/swdec.html) Unless we dismiss this claim as bogus, freeamp, mpg321, and friends must go to non-free at least. -- Robbe signature.ng Description: PGP signature
Netscape/Fortify/Crypto (was: Bug#67331: potato bugs)
[cutting down on CCs and CCing debian-legal instead - the thread should probably continue there] Ethan Benson [EMAIL PROTECTED] writes: no there is still weak and strong encryption versions of netscape, you still must go though a click through page stating that you are not downloading from Iraq or other `terrorist' nation. the debian packages are simply using the weak export binaries instead of the strong crypto version. so you either need fortify (not available) or you have to download and install netscape manually (eschew the .debs). This is a bad situation: Fortify will not support newer Netscapes because the strong-crypto versions are available for download. But Debian still distributes the weak versions. I think the project needs to come to a conclusion how we can distribute crypto-software under the new export-regulations. For example, anybody outside the US could download the strong Navigator and (N)MU it into non-US. Would she breach her agreement with Netscape by accepting the fact that non-us.debian.org can be freely accessed from Iraq et al? Would that make her a possible subject of prosecution in the US? By state authorities, or would Netscape have to sue? What about adopting a fortify-like strategy? A developer outside of the US would download the weak and strong programs and generate from that a package that patched the weak version into the strong variant. Fortify didn't get sued, AFAIK, even when the regulations were more strict. Some consent about what is acceptable would be very desirable. -- Robbe signature.ng Description: PGP signature
Re: CD images and US export laws
Frederik Vanrenterghem [EMAIL PROTECTED] writes: I don't get the problem. Wasn't this law recently changed, resulting in free export of encryption software? AFAIK you still have to jump through some hoops before you can consider exporting legal. I think it would be a nice thing for the legal team to figure out some of the questions: - If upstream has got the permission to distribute their software world-wide (except evil empires), can simply Debian freely redistribute it? + If yes, and when source is available, may Debian also distribute changed versions? - If upstream has not yet got permission (and perhaps is unwilling to ever get one), can Debian apply for permission? + Has the permission to be renewed for updated upstream versions, or updated Debian versions? As I understand it getting permission may be as simple as telling the Department of something the URL where it is distributed, and the Deparment not complaining. Is that true? debian-legal: What's your thoughts on this? Perhaps woody may do away with non-US entirely... -- Robbe
