Bug#294559: Public domain licensing
Dear knowledge source, As can be seen in #294559 I hope to become a debian developer. In the same bug report one can see that the package I'd like to start with is netbiff. According to it's web page the license is: License All code contained in netbiff is released into the public domain. Until I got asked me to double check with you I thought no problems existed including software with public domained source code in debian. It have been claimed that PD is a vague definition and the way GNU defines freedom, PD is only almost free because future versions might not be free. But that only applies do derived works, right? My understanding is that once released under the public domain, the public's right to that release can't be revoked? Have I gotten that entirely wrong? Will the upstream developer have to add a copyright claim to the PD license too to make it legal? I could try convince the Author to change to another license if there are serious problems with having PD software in debian. However I would prefer not to since I consider it to be the Author's right to choose what license to release his work under and respecting the wishes of others are important to me. -- /Martin signature.asc Description: Digital signature
Re: Bug#294559: Public domain licensing
On Thu, Feb 10, 2005 at 03:12:32PM +0100, Martin Samuelsson wrote: It have been claimed that PD is a vague definition and the way GNU defines freedom, PD is only almost free because future versions might not be free. But that only applies do derived works, right? My understanding is that once released under the public domain, the public's right to that release can't be revoked? Have I gotten that entirely wrong? I've never heard of this. Public domain works are free. One theoretical problem with public domain software: not all jurisdictions, as far as I vaguely understand, actually have a notion of releasing your work into the public domain. A problem some authors have (and probably should have!) is that simply saying released into the public domain isn't disclaiming warranty, so the author might be inviting legal trouble onto himself. For both of these reasons, I usually recommend that people who want to permissively free a work use the MIT license, or the 2-clause BSD license, which are well-established, simple licenses that allow pretty much anything. However, I've never heard any serious claim that works released into the public domain aren't free, and I've never heard of revoking a work from the public domain (if you could do that, it was never in the public domain to begin with). -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: I-D ACTION:draft-bradner-rfc-extracts-00.txt]
On Fri, Feb 11, 2005 at 09:48:52AM +0100, Stephane Bortzmeyer wrote: Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [-- This text/plain attachment is not included, --] [-- and the indicated access-type anon-ftp is unsupported --] Err. Better to include the actual text, and not a link (especially not a link that not even Mutt can grok). -- Glenn Maynard Network Working GroupS. Bradner Internet-Draft Harvard University Editor February 2005 Extracting RFCs draft-bradner-rfc-extracts-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 7, 2005. Abstract Many people have expressed a desire to extract material from IETF RFCs for use in documentation, text books, on-line help systems, and for similar uses. In addition, some IETF RFCs contain MIBs and other types of program code that could be compiled. This document proposes an update to RFC 3667 and 3668 to explicitly permit extracting material for a wide range of uses. RFC 2026 limited the rights the IETF requires of document authors and editors. RFC 2026, and its successors, do not require that the authors permit the creation of derivative works based on their contribution outside of the IETF process. Some people have expressed a desire for the IETF to obtain such permission to enable people outside of the IETF to create derivative works, for example, within Bradner [Page 1] Internet-DraftRFC Extracts February 2005 an open source environment. This document tries to spell out the issues surrounding this desire in order to stimulate discussion within the IETF community about possibly updating RFC 3667 and RFC 3668 to request such rights from RFC authors. Copyright Notice Copyright (C) The Internet Society. (2005) 1. Introduction Section 3.3(a)(E) of RFC 3667 [RFC 3667] requires that the author(s) of IETF contributions grant the IETF the right to make and use certain types of extracts of the contributions for purposes not limited to the IETF standards process. When I wrote that section I intended that to mean that anyone could make such extracts but the wording I used limited the permission to the IETF. This document tries to fix the words to match my intent. Historically RFCs have been assumed to be fair game to anyone who wanted to use text and ideas from an RFC in their own work. The RFC publication process did not explicitly request that RFC authors surrender the right for the creation of such derivative works but no limits to do so were noted in RFCs. Starting with RFC 1602 [RFC 1602] the IETF stared requesting that RFC authors agree to grant specific rights to the IETF regarding the text and ideas in RFCs. These requests were made more explicit in RFC 2026 [RFC 2026] and clarified in RFC 3667. Currently, as defined in RFC 3667, authors must grant to the IETF the right for derivative works to be created within the IETF standards process but the IETF does not request the right for people not working within the IETF standards process to make derivative works. The author(s) may do that on their own if they want but its not part of the rights the IETF requires the author grant as part of RFC publication process. Note that the RFC Editor requires that authors grant the right for anyone to make derivative works as a requirement for the publication of a non-IETF RFC. Note also that authors may explicitly add text to their submission that prohibits the creation of derivative works at all. (See
Re: [EMAIL PROTECTED]: I-D ACTION:draft-bradner-rfc-extracts-00.txt]
3.2.1. Confusion over what constitutes the standard It would clearly be confusing if someone could take an IETF standard such as RFC 3270 (MPLS Support of Differentiated Services), change a few key words and republish it, maybe in a textbook, as the definitive standards for MPLS Support of Differentiated Services. Debian, at least, has no problem with a license requiring that a modified standard not be misrepresented as the original. It is not confusing in any way for me to take RFC 3270, change a few key words, and republish it, as long as I don't call it RFC 3270. Further, nothing prevents me from writing up my own bogus standard and calling it RFC 3270 (MPLS Support of Differentiated Services); since it's not a derivative work of the other RFC 3270, its copyright license is irrelevant. (I believe the only possible protection against this is trademarks.) The fact that he's even presenting this tired old argument means that either nobody is competently presenting the arguments for freeing of standards documents, or the arguments aren't being heard ... IETF working groups undertake a great deal of effort to develop a common understanding of the underlying architectural assumptions of the standards they develop. Modifications or extensions to a standard done without an understanding of those architectural assumptions may easily introduce significant operational or security issues. The best place to extend a standard is in the working group Preventing modifications to the standards document does nothing to prevent this. You can still say use RFC 1234, with the following modifications ..., and just as easily cause trouble. This is not a reason for standards documents to be non-free. 3.2.2. Cooperation between standards organizations This essentially says we want to prevent competition by making our standards non-free, which is a central theme of non-free licenses. I do not buy the argument that the open source community requires the ability to make capricious changes in standards. Here, he seems to misunderstand the notion of required freedoms. We don't require the ability to modify the standard in order to implement it. We require the ability to modify the standard before considering it a free document, just as we require the ability to modify a program before considering it a free program. Of course, Debian's notion of freedom has less weight here, because the IETF probably doesn't really care whether Debian distributes the RFCs. The open source community does not have this ability with the output of other standards organizations, I do not see justification to say that its OK to do so for Internet technology. It seems to be The standards of other organizations are also non-free; this merely says they're non-free, so we should be, too. Sorry, Stephane, but all of this sounds more like a blunt refusal than progress. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Use of the Debian name for websites
On Thu, 10 Feb 2005 21:43:49 -0500, Glenn Maynard [EMAIL PROTECTED] wrote: This isn't avoiding it at all; the DFSG was not renamed to the Debian Free Stuff Guidelines. It merely makes it clear that documentation is included in software, at least as far as the SC is concerned. I don't think the GR's numerous removals or substitutions of the word software support this argument. You can change your vocabulary if you want, but I certainly don't like the idea of giving way to the people trying to change the language to suit their claims that freedom isn't important for documentation. Good for you, but how is this relevant to what I wrote? I claimed no such thing, and my own change of vocabulary is idential to that which has already been approved in the portions I quoted from the GR. -- Andrew Saunders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: I-D ACTION:draft-bradner-rfc-extracts-00.txt]
Glenn Maynard [EMAIL PROTECTED] wrote: The fact that he's even presenting this tired old argument means that either nobody is competently presenting the arguments for freeing of standards documents, or the arguments aren't being heard ... Thank you for writing a rebuttal, Glenn. I agree with your points, but I'm unable to write my own full reply because I must now go run my blood through a heat exchanger to stop it boiling. This laughable IETF draft not only refuses to grant any permission to modify but misrepresents most of the arguments for and against that grant! For example, it claims that some open source community wants unrestricted permission to modify, but doesn't give a reference for the claims. A quick look at the mail archive referenced elsewhere finds people claiming the exact opposite. EONCRACK? I thank Scott Bradner for providing such an excellent example why IETF should not be the only way to develop RFC-based standards and why we should have *no faith* in claims they represent people like us in the United Nations Working Group on Internet Governance, to which they were appointed by distortion and slight of hand. -- MJR/slef http://people.debian.org/~mjr/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firefox/Thunderbird trademarks: a proposal
Michael K. Edwards [EMAIL PROTECTED] wrote: [...] The Mozilla team seems to be committed to supporting the Debian packagers in building both mozilla-firefox and iceweasel-browser packages from the same source base. Isn't this precaution enough? We know the Mozilla Foundation licensing delegate is committed to it: can Gerv (or someone else, hey ho) tell us the opinions of the wider Mozilla team, please? When will iceweasel/FireWeb (or whatever white label browser) be buildable from stock sources? Final call is the maintainer's in my opinion. They know most about how responsive upstream is to bug reports. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Use of the Debian name for websites
On 11 Feb 2005 01:15:42 GMT MJ Ray wrote: The FSF have a vague definition of what they consider free *documentation* and the main difference with free software is I don't believe that it is essential for people to have permission to modify all sorts of articles and books. http://gnu.hands.com/philosophy/free-doc.html Yes, and no reason at all is provided to explain *why* this permission should be considered as not essential. More precisely, no reason to explain *why* this permission should be considered less important than the permission to modify programs... :-( Unfortunately, that even applies to articles which are permanently attached to FSF's free documentation manuals. And this makes things to get even worse... :-( Making a DFDG will need at least one GR Without counting that we then would need one different set of guidelines for each of the following: music, images, animations, novels, poems, insert_your_favorite_arbitrary_category, ... and it would need to be weaker than the DFSG if it's going to accommodate the FSF position, Yes, and I've not yet seen *any* convincing argument that documentation should get weaker freedom criteria than programs! Actually I have neither seen a good argument that documentation and programs should have *different* freedom criteria... As a consequence, we should IMHO stick to DFSG for all works. which means the border needs to be tightly controlled so as not to permit non-free software. There's not been anyone yet who's come up with a reliable quick test to seperate software and documentation (not surprising, as I think they're overlapping sets), I agree that programs and documentation are overlapping sets and the boundary is rather blurry. The same applies to other categories of works... so each case would want consensus built and that's a scary amount of work, especially to support some other group's totally arbitrary and inconsistent position. Arbitrary and inconsistent is a good description, sadly... -- 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 pgpaheU1PMvSY.pgp Description: PGP signature
Re: Use of the Debian name for websites
On Fri, Feb 11, 2005 at 10:58:46AM +, Andrew Saunders wrote: On Thu, 10 Feb 2005 21:43:49 -0500, Glenn Maynard [EMAIL PROTECTED] wrote: This isn't avoiding it at all; the DFSG was not renamed to the Debian Free Stuff Guidelines. It merely makes it clear that documentation is included in software, at least as far as the SC is concerned. I don't think the GR's numerous removals or substitutions of the word software support this argument. I removed or substituted it precisely to stop this fucking stupid argument about the definition of software. Kindly stop perpetuating it anyway. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Use of the Debian name for websites
Josh King wrote: Hi, I searched Google and the archives for this, but never found a solid answer. I, along with a few others, would like to start a website using the Debian name in the domain (we're using DotDebian.org as a working name for right now). The goal/intent of the site is to provide new user friendly forums, how-to's etc. This will focus mainly on users who have been using one of the Debian based distros (i.e. Knoppix, MEPIS, etc.) and want to migrate their systems over to Debian GNU/Linux itself. We plan to post a disclaimer stating that we are not endorsed nor affiliated with Debian or SPI. All content on the site will be licensed under the applicable Debian or GNU accepted licenses, meaning all original content of any kind generated or developed by or for the site will be free as in beer and freedom. If this is acceptable use, do we need any type of official permission from Debian, or may we simply go ahead with the plan as laid out? Also, is it acceptable to use the Open Use logo as part of any graphics on the site? Thanks in advance. Josh FWIW, the idea is being scrapped anyway in favor of supporting the existing sites. Thanks. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
