Re: Non-free IETF RFC/I-Ds in source packages
On Wed, 11 Oct 2006 18:04:22 +0200 Simon Josefsson wrote: > Gervase Markham <[EMAIL PROTECTED]> writes: > > > Simon Josefsson wrote: > >> http://wiki.debian.org/NonFreeIETFDocuments > > > > A useful thing to add to that page would be simple instructions on > > how those authoring IETF documents could make them available under a > > DFSG-free licence (presumably in parallel to the IETF one) - perhaps > > some sample boilerplate text to include. > > Good idea! > > I've added two new sections to the wiki page: > > 1. Template for license to include in RFCs. [1] > > 2. Template for e-mail to request additional rights from RFC > authors. [2] Simon, I would like to thank you for your effort in this struggle against non-free IETF documents in Debian (main). I really appreciate the time that you're dedicating to improving Debian from this point of view! :) Good job! [...] > If you prefer another widely recognized free license instead, such > as the revised BSD license, the GPL, the MIT/X11 license, that > is also fine. I think it would be better if you explicitly gave reference URLs for the cited licenses. Moreover, it seems that a good URL for the X11 license is not easy to find (there used to be a copy at http://www.x.org/Downloads_terms.html, but it disappeared; there used to be another copy at http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/licenses/X11?rev=1.1.1.1, but it had vanished too, last time I checked). And some people claim that there is no single "X11" license, since many slightly different variants have been used for parts of XFree86 and Xorg... Consequently, I would rather suggest the Expat/MIT license, which is clearer and less ambiguous. The reference to the 3-clause BSD license should also made clearer. These considerations lead to the following proposed rephrasing: | If you prefer another widely recognized free license instead, the | following ones are also fine: | * the 3-clause BSD license |http://www.gnu.org/licenses/info/BSD_3Clause.html | * the GNU GPL version 2 |http://www.fsf.org/licensing/licenses/gpl.txt | * the Expat/MIT license |http://www.jclark.com/xml/copying.txt -- But it is also tradition that times *must* and always do change, my friend. -- from _Coming to America_ . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgptUarDPkoEs.pgp Description: PGP signature
Re: Non-free IETF RFC/I-Ds in source packages
Gervase Markham <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> http://wiki.debian.org/NonFreeIETFDocuments > > A useful thing to add to that page would be simple instructions on how > those authoring IETF documents could make them available under a > DFSG-free licence (presumably in parallel to the IETF one) - perhaps > some sample boilerplate text to include. Good idea! I've added two new sections to the wiki page: 1. Template for license to include in RFCs. [1] 2. Template for e-mail to request additional rights from RFC authors. [2] The text is just in draft form, so please review it. Possibly, we could use something simpler in [2], or even in [1] too. /Simon [1]: x. Copying conditions The author(s) agree to grant third parties the irrevocable right to copy, use and distribute the work, with or without modification, in any medium, without royalty, provided that, unless separate permission is granted, redistributed modified works do not contain misleading author, version, name of work, or endorsement information. [2]: Subject: Requesting additional rights to RFC Dear Author, The Debian GNU/Linux distribution wishes to incorporate the IETF RFC as part of its distribution, and to allow users to develop, modify and evolve the document. Because the authors of contributions to the IETF standards retain most intellectual property rights with respect to such contributions under IETF policies in effect during the development of RFC , and because you are an author of said document, the Debian community hereby requests that you kindly agree to release your contributions in RFC under the license below, for inclusion in Debian. I agree to grant third parties the irrevocable right to copy, use and distribute the work, with or without modification, in any medium, without royalty, provided that, unless separate permission is granted, redistributed modified works: (a) do not contain misleading author, version, name of work, or endorsement information, and (b) do not claim endorsement of the modified work by the Contributor, or any organization the Contributor belongs to, the Internet Engineering Task Force (IETF), Internet Research Task Force (IRTF), Internet Engineering Steering Group (IESG), Internet Architecture Board (IAB), Internet Assigned Numbers Authority (IANA), Internet Society (ISOC), Request For Comments (RFC) Editor, or any combination or variation of such terms (including without limitation the IETF "4 diamonds" logo), or any terms that are confusingly similar thereto, and (c) remove any claims of status as an Internet Standard, including without limitation removing the RFC boilerplate. The IETF suggests that any citation or excerpt of unmodified text reference the RFC or other document from which the text is derived. To indicate that you agree to these terms, please reply to this e-mail and quote the license above and indicate that you agree to this. If you prefer another widely recognized free license instead, such as the revised BSD license, the GPL, the MIT/X11 license, that is also fine. Sincerely yours, Simon Josefsson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why TPM+Parallel Distribution is non-free
MJ Ray wrote: Since when has CC-By been a copyleft anyway? CC-By is a separate issue and whether it is or is not a "copyleft" isn't relevant. The terms in question ARE DFSG free, as they exist in CCPL3.0, for By and By-SA. FWIW, Mia Garlick notes that, unlike copyright, TPMs are not limited by "fair use" or "fair dealing". Thus TPMs have the capacity to render a work even less free than "all rights reserved". The platform monopoly issue creates a problem for the original work, as well as derivatives, so it is still a problem for CC-By licensors. More importantly, from my PoV, the provision *is* DFSG free, so it doesn't matter. > Not only is this untrue, but it is in fact reversed. Allowing TPM > distribution allows a platform-owner to obstruct redistribution of > the work. It is true. Also, allowing TPM distribution while prohibiting a platform-owner to obstruct redistribution of the work would not allow a platform-owner to obstruct redistribution of the work. Now, who's using the confusing phrasing? ;-) TPM is such an obstruction. Hence "allowing TPM distribution while prohibiting a platform-owner from obstructing redistribution of the work" is contradictory. >> the restrictions of a licence that permits parallel distribution >> need not be non-copyleft; > > The anti-TPM clause is part of the copyleft. It is essential to > preserve the freedom of the work, hence it is essential to > copyleft. However, blanket anti-TPM is not the only way to preserve that freedom and arguing about copyleft does little to argue for why it's in CC-By. There is no "blanket anti-TPM". There is a requirement that distribution not occur in TPM'd form. All free licenses have some kind of distribution requirement. Many (including the GPL) make requirements about the form of distribution of derivatives (e.g. "you must include the license"). I've already pointed out that it is technically possible to design a TPM that triggers on the presence of GPL license statements, thus rendering the GPL non-free by your argument. But of course, that's only because your argument is wrong: both the GPL and the CC-By-SA are free because the user has the freedom to remove these obstructions in order to use the work. BTW, this is NOT a new freedom of the CC-By-SA, as you keep suggesting. The wording has been improved, but CC-By-SA 2.5 provided this freedom as well (and it may go back further). Mia Garlick addresses this point in #6 of her "responses" document: http://lists.ibiblio.org/pipermail/cc-licenses/attachments/20060908/da9db6a3/attachment-0001.pdf >> 1. one particular problem with TPMs overruling all other >> arguments; > > It's not so much "one particular problem" as it is "THE problem". Really? Fantastic! So prohibit "THE problem" instead of carpet-bombing whole fields of endeavour. The only "field of endeavour" being restricted is the same one that ALL free licenses restrict: namely, the process of distribution. As with ALL free licenses, requirements are set on the form and methods of distribution. > The entire purpose of TPMs is to preserve monopolies. I thought the entire purpose of copyright was to grant monopolies, even if that's not what we use it for today. I wonder whether TPMs will be subject to such legal judo in future. No clue what you're getting at here, MJR. We both know that TPMs were invented because their users thought that copyrights were too difficult to enforce by legal means. They have since used them to extend their monopolies beyond what copyright allows. That's why TPM is fundamentally antithetical to free culture and software. > To be precise, of course, the CCPL makes it quite clear that it is > solely restriction of the end user that is not allowed. So how does it not allow parallel distribution? Because parallel distribution, by which I take you to mean "allowing TPM-locked distribution so long as an unlocked version is available" does not alleviate the restriction to the end-users freedom that the TPM-locked version applies. It's a "band-aid for a corpse", a solution that doesn't solve. What you are trying to do seems all backwards to me -- trying to allow a particular kind of restriction of end-user freedoms, and then trying to patch it up afterwards by adding lots of fiddly clauses to the license. >> Attacking d[A] for all A is impossible, as there will always be >> some A whose creator allows d[A]. > > That is still possible with the existing wording. It is possible that d[A] still exists for some A, which means that attacking d[A] for all A is impossible: agreed? This is silly. There will always be works committed to the public domain, or licensed under BSD, or whatever. So what? We're interested in the fate of a particular work under a particular license. In that context, there is no question of the problem you're suggesting. > In fact, it's possible that Dave may pay Sam for the right
Re: conquer relicensing
"Arnoud Engelfriet" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Michael Poole wrote: Arnoud Engelfriet writes: > However I didn't see a signature in the text file. > Only the guy's name. At least in the US, the relevant law (why I mentioned "affirmative acts") is what make click-through agreements binding -- the act of clicking is the user's electronic "signature". My thought is that his writing out of that paragraph would also suffice to show affirmative assent. I'm not sure. The statute calls for "signed by the owner", but not to show assent to an agreement. It's a one-sided statement that has to serve as evidence that the copyright has transferred. I can see how typing in my name could be construed as evidence of my acceptance of your offer. But if a statute explicitly calls for "signed", wouldn't something like a proper PGP signature be called for? I believe the only real requirement is that the "mark" was made with the intention of acting like a signature. The patent office makes use of this law for e-filing, with the signature being any text between two slashed placed in a special text box (IIRC). The problem is that sometimes it is unclear if a mark was intended to be a signature. This problem even exists in the analog world. A name written on a document by the owner of that name may be an autograph and not a signature. If the wiritng was located on a signature line, then it is presumably a signature, but in other cases it can be hard to tell. Even when something is clearly a signature (like a PGP signature) it can still be unclear as to the meaning of the signature. Does the signature mean "I agree" (as in acceptance of a contract), does it mean "I have seen this", does it mean "I wrote this", does it mean "I endorse this"? Does it mean more than one of those? I think you can see the problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why TPM+Parallel Distribution is non-free
Don Armstrong wrote: On Tue, 10 Oct 2006, Terry Hancock wrote: > Prohibiting TPM *distribution* is fine under DFSG. No, it's not. Prohibiting TPM distribution is quite clearly a restriction on a field of endeavor. Since distribution is always a use, then *any* distribution requirement is a use restriction in the broadest sense of the term. Thus, by this logic, GPL, LGPL, and even BSD are "restrictions on a field of endeavor". I claim this is absurd, given that these licenses are foundational examples of "DFSG freedom". So I reject the idea that limitations on form of distribution are automatically limitations on use. The user has the freedom to apply TPM to a work in order to use it. AFAIK, that's all he needs. If a TPM tool for the platform exists and the encryption key exists, then he has no problem. After this, I have to ask, which terms are you arguing *are* DFSG free? 1) TPM-distribution is allowed, so long as there is a parallel distribution of an equal or better version of the work without TPM, and there is a publically available key and encryption tool for converting the non-TPM work to TPM in order to play on the platform OR 2) TPM-distribution is allowed under all circumstances, so long as there is a parallel distribution of an equal or better version of the work ? My reply is necessarily different depending on which you are arguing for: If it's #1, then there is only one practical concern, which is where the application of TPM occurs. In that case, I would argue that it needs to happen at the end-user, because that's the only way to truly prove both that the non-TPM work is "equal or better" than the TPM work, AND it's the only way to prove that the keys and encryption tools are available. And when I say "available", I mean at least zero-cost, and preferably free as well. The one real complaint I've seen against this scenario is based on the idea that having the end user apply TPM is too *expensive* because the key-application tool or key costs money. In my opinion, this situation is non-free to begin with, and should be rejected. This retains the platform owner's monopoly control over who is allowed to make derivatives of works. If it's #2, then you are explicitly requiring permission for the "DRM Dave" scenario of a platform monopoly being imposed on all derivative works. In this scenario, the platform owner essentially hijacks the author's work and sell it to a captive audience. He denies that audience the freedom that the license is explicitly there to protect. I think we can be pretty clear that CC isn't going to accept that and I certainly hope that the Debian project will show the same commitment to freedom (an ironic situation, IMHO). > This is exactly what the Aug 9 draft of CCPL3.0 says: > > """ You may not impose any technological measures on the Work that > restrict the ability of a recipient of the Work from You to > exercise their rights granted under the License """ The critical aspect here is that parallel distribution does not cause the rights of a recipient of the work to be restricted; they retain all abilities that they had originally and gain additional ones (namely, being able to run the work on a TPM-inflicted device.) No. They already have that freedom in CCPL3.0. Problem solved. Only the distributor has to think about the license terms as they exist (the quote above is strictly from the requirements to *distribute*). > The requirement is needed to ensure that copyleft preserves the > freedoms granted by the content's author. No, they're not. They're a lazy means of hacking in a small bit of copyleft protection into licenses by outlawing legitimate uses. Provide an example of a *use* that is restricted (there are none). Only improper distribution, specifically designed to obstruct end-user freedoms (i.e. TPM) is prohibited. > Any attempt via licensing to deal properly with TPM and or DRM must necessarily address the need for free software works to be capable of running on such a device when the end user desires it. Yes. And that's been dealt with. There are two choices: You either 1) allow parallel distribution 2) require distribution of keys or information needed to deploy modified versions to the device. CCPL3.0 chooses #2. The end user loads the TPM'd content onto the device, applying the TPM at that point. This is a practical and complete way of *enforcing* the requirement that keys (and any other information or tools needed) is available to the user. Whether or choosing to do 2) has the pratical effect of not allowing the use on TPM devices is a separate issue; it in itself does not outlaw their use or distribution. [It just minimizes their effectiveness.] Fine. Still good with CCPL3.0. If you're seriously interested in discussing how to do copylefted TPM and DRM properly, I strongly suggest reading my position statement from committee D on the
Re: Why TPM+Parallel Distribution is non-free
Terry Hancock <[EMAIL PROTECTED]> wrote: > MJ Ray wrote: > > Terry Hancock <[EMAIL PROTECTED]> wrote: > > > The case has been made that CCPL3.0 is DFSG-non-free because it > > > does not allow the distribution of content in TPM'd format[0]. I > > > assert that not only is this argument false, it is actually > > > reversed: allowing TPM distribution, even with parallel > > > distribution of non-TPM versions of the same content actually > > > permits a violation of the DFSG, [...] > > > > I agree that Terry Hancock asserts allowing TPM-parallel licences is > > "a violation of the DFSG" but does not support that with any > > evidence. > > No. I said it permits a violation. Apologies for misreading that. Please try to keep phrases simple, to help people with language troubles. Why is it a problem to permit violation of the DFSG? Some licences that follow the DFSG also permit other violations, but works which actually violate them are not welcome. > What a platform owner may do, is > take an otherwise free+copyleft work and release it under non-free > terms. He may do so in a way that obstructs competition from > free+copyleft works. It is essentially the removal of the copyleft on > the work. Since when has CC-By been a copyleft anyway? [...] > Prohibiting TPM *distribution* is fine under DFSG. [...] No, prohibiting *all* TPM distribution is still not fine. > > I think it is not > > because it hinders free redistribution and discriminates against use > > of some platforms. > > Not only is this untrue, but it is in fact reversed. Allowing TPM > distribution allows a platform-owner to obstruct redistribution of the work. It is true. Also, allowing TPM distribution while prohibiting a platform-owner to obstruct redistribution of the work would not allow a platform-owner to obstruct redistribution of the work. > > > Debian's determination that parallel distribution of non-TPM files > > > alongside TPM files will solve this problem is based on the FALSE > > > idea that binary/source distribution is analogous to TPM/non-TPM > > > distribution. > > > > Problems I see with this argument so far: > > > 1. AFAICT, parallel > > distribution was first suggested as a TPM-countermeasure [in 2003 at > > least] long before the binary/source analogue was first used in > > explanation [in 2005] so how can it be based on it?; > > Oh give me a break. Like they weren't thinking of that in 2003. [...] Prove it. Claiming telepathy is not credible. I was active on this list in 2003 and I'm pretty sure I wasn't thinking of it then. > > 2. the > > restrictions of a licence that permits parallel distribution need not > > be non-copyleft; > > The anti-TPM clause is part of the copyleft. It is essential to > preserve the freedom of the work, hence it is essential to copyleft. However, blanket anti-TPM is not the only way to preserve that freedom and arguing about copyleft does little to argue for why it's in CC-By. > Saying that a work distributed for platform A is "free" because you can > play derivatives on platform B, even though you can't play them on A, is > just double-speak. Obviously, a real copyleft insists that you can > modify a work and play it back on the platform the work was designed for > (that you can do so on other platforms is also required). I don't see why you not having the tools to target platform A stops the work being considered as free software. Free software licences don't stop you targetting platform A - CC 3.0draft would. What is the definition of "real copyleft"? Is it different from the "fake" copyleft described in http://www.gnu.org/licenses/licenses.html which apparently doesn't insist you can do that? [...] > > 1. one particular problem with TPMs overruling all other arguments; > > It's not so much "one particular problem" as it is "THE problem". Really? Fantastic! So prohibit "THE problem" instead of carpet-bombing whole fields of endeavour. > The entire purpose of TPMs is to preserve monopolies. I thought the entire purpose of copyright was to grant monopolies, even if that's not what we use it for today. I wonder whether TPMs will be subject to such legal judo in future. > This case merely > exposes how parallel distribution is inadequate to preserve end-user > freedoms. The case looks at it backwards: we need terms which are *adequate* to *ensure* end-user freedoms. In the example, the freedom is restricted by monopoly control of d[], not the licence of any A. [...] > > > A system which applies encryption, but is not enforced under law is > > > NOT a "TPM" in the legal sense of the word, and is therefore not > > > "being used to restrict" a work (legally). > > > > Adding the adverb "legally" does not change the meaning of words on > > its own. Are there any cases showing any technological measure used > > to restrict anyone as being not enforced under law now? > > It's only a "TPM" if it is being used to protect. That is a matter o
Re: compatibility of bsd and gpl
Markus Laire <[EMAIL PROTECTED]> > I don't see there anything which says anything like BSD[2] clause 3: > : Neither the name of the nor the names of its contributors > : may be used to endorse or promote products derived from this software > : without specific prior written permission. > > Is there a good reason why this isn't considered an additional restriction? Personally, I think it's because it's a null clause everywhere. Using the names of legal persons to promote derived works requires permission. Unlike some "supertrademark" (some CC licences) and anti-agency (APSL? CDDL?) clauses, the modBSD one allows other uses of the names and other permissions to exist. -- 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]
