Re: Copying conditions
scott == scott bradner [EMAIL PROTECTED] writes: If you understand the open source position and disagree with it, then there's probably little more to say. scott If the position is that the open source community can take scott an IETF consensus-based standard, modify it and claim that scott the new version is the real standard then I do disagree - scott I think that standards must be developed and modified in scott open consensus-based processes, not by individuals or scott groups unrelated to the group that developed the standard. The open source community definitely wants to be able to guarantee to its users the ability to take text or code from an IETF standard and use that text or code in derivatives of that standard. Parts of the open source community want to be able to claim that that standard is the real unmodified thing. Other parts of the open source community would be happy changing the name of the work and clearly indicating what it is. Areas where a discussion might be useful would be to explain why the open source community wants to do this etc. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Copying conditions
seems to be a reliable way to ensure that there are multiple understandings of what the standard actually is - I find it hard to understand who that is good for Scott --- From [EMAIL PROTECTED] Sun Oct 10 16:01:46 2004 X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] (scott bradner) Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Copying conditions References: [EMAIL PROTECTED] From: Sam Hartman [EMAIL PROTECTED] Date: Sun, 10 Oct 2004 16:02:02 -0400 In-Reply-To: [EMAIL PROTECTED] (scott bradner's message of Sun, 10 Oct 2004 15:53:02 -0400 (EDT)) User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii scott == scott bradner [EMAIL PROTECTED] writes: If you understand the open source position and disagree with it, then there's probably little more to say. scott If the position is that the open source community can take scott an IETF consensus-based standard, modify it and claim that scott the new version is the real standard then I do disagree - scott I think that standards must be developed and modified in scott open consensus-based processes, not by individuals or scott groups unrelated to the group that developed the standard. The open source community definitely wants to be able to guarantee to its users the ability to take text or code from an IETF standard and use that text or code in derivatives of that standard. Parts of the open source community want to be able to claim that that standard is the real unmodified thing. Other parts of the open source community would be happy changing the name of the work and clearly indicating what it is. Areas where a discussion might be useful would be to explain why the open source community wants to do this etc. --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Copying conditions
scott == scott bradner [EMAIL PROTECTED] writes: scott seems to be a reliable way to ensure that there are scott multiple understandings of what the standard actually is - scott I find it hard to understand who that is good for Do you think that trying to describe a modified version of TCP without taking text from the original RFC is likely to lead to a better situation? Honestly I think the issue of whether derivative works can use text from the original is distinct from whether derivative works can be confused with the original. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Copying conditions
The open source community definitely wants to be able to guarantee to its users the ability to take text or code from an IETF standard and use that text or code in derivatives of that standard. Parts of the open source community want to be able to claim that that standard is the real unmodified thing. Other parts of the open source community would be happy changing the name of the work and clearly indicating what it is. The above paragraph probably also works if you replace The open source community with the name of any large Internet-related software or hardware company, such as Microsoft of Cisco. There is a lot to be gained by embracing and extending existing standards and establishing your own defacto standards that are supersets of the originals. But, those defacto standards tend to be detrimental to one of the primary goals of the IETF: interoperablity. Areas where a discussion might be useful would be to explain why the open source community wants to do this etc. While it might be interesting to gain this insight into the motivations open source community, I don't know that it would be pertinent to the issue at hand. A better question to answer would be: Why would allowing the publication of modified or extended IETF standards (by the open source community or others) be good for the Internet? Margaret ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Copying conditions
small quotes are fine (under fair use) but significant excerpts are not (under normal copyright law and under the copyright notices on IETF RFCs) Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Copying conditions
-BEGIN PGP SIGNED MESSAGE- Sam == Sam Hartman [EMAIL PROTECTED] writes: Sam Some questions I'd suggest you consider: Sam * Have the IETF's current IPR practices actually limited any Sam company's ability to embrace and extend Internet standards? That's a biased question. You use the word company As such, you imply a whole set of things that do not work out correctly in the open source world. - -- ] Elmo went to the wrong fundraiser - The Simpson | firewalls [ ] Michael Richardson,Xelerance Corporation, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic(Just another Debian GNU/Linux using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQWmopYqHRg3pndX9AQHOdAP+OwNgTv092bkd+CCkXHjtBj84D/84a0Z8 ntaHpYxESPOzC6rcrWGbA+AjyIoicGfkJGt6ou46uRU45pSeTB71QmgdSSE/7Wj4 7xKTAp3UYKuv+rSz7SR4GHjmCy009pHWq3GkFL8juwZNfUT6HfM/fx9XUc4vdSiE zDDkzZPsXy8= =+D7S -END PGP SIGNATURE- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Copying conditions
[EMAIL PROTECTED] (scott bradner) writes: there seems to be an assertion of evil intent here that is not the case What gave you that idea? IMHO, let's leave intent for some other discussion, and focus on the license. After having read the discussion for the past few days, I still see no useful text in RFC 3667 that permit me to do the things I mentioned earlier, if the RFC 3667 license would be used. Repeated here for simplicity: For IDN, I want to be able to extract the tables from RFC 3454 and use them in my implementation. For Kerberos, I want to be able to use the ASN.1 schema in my implementation, and copy the terminology section into my manual. For SASL, I want to incorporate portions of the introduction section from the RFC into my manual, to make sure some terminology is explained correctly. For GSS-API, I want to be able to copy the C header file with function prototypes into my implementation. The text that has been referenced is in section 7 of RFC 3667, Exposition of Why These Procedures Are the Way They Are: e. the right to let third parties extract some logical parts, for example MIB modules I don't believe I can use this text in a legal argument to motivate why I'm copying parts from a RFC. First, the text appear to be from a discussion about the license, not the actual license. Secondly, the qualifier some in extract some logical parts is worrying. Without further details, some might mean anything, including preventing exactly those parts I need. Thirdly, if you read the license, it seem (to me) clear that it doesn't imply the right granted in (e). 3/ the IETF is quite interested in letting people create manuals etc - there is no intent to limit the ability for a 3rd party to reproduce RFCs or parts of RFCs in manuals What I'm arguing for, then, is that the license should reflect the intent. I do not see any problem for the open source community unless that community wants to create a new version of TCP and take parts of existing IETF RFCs to include in its description of their revised TCP I don't speak for the open source community, but I believe it should be possible to do exactly that. Naturally, I would have no right to claim that my version would be IETF's TCP, or that my version is the real version. However, I need to have the right to create derivative work from RFCs. To perhaps give a better example of why I need this right, let's take the first item above: IDN. After the IDN specification has been published, some problems in Unicode NFKC has been discovered that may have security consequences. If someone wanted to offer their users an improved IDN library, they could take my library and modify it. However, they could not describe how the new product work, by taking the existing RFC and add a few paragraphs that solve the problem. Instead, the RFC license, from my current understand at least, would force them to write a complete new specification. I don't believe that is acceptable. Fortunately, in this case, IDN was published under the old RFC 2026 license, which I maintain would permit this use. Finally, derivative works need not only be about revised specifications. It may simply be copying tables from a specification into an implementation. Thanks, Simon ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Copying conditions
Iljitsch van Beijnum wrote: However, this is not to say that having anyone who feels like it modify RFCs and republish them is a good idea. Treating natural language text as source code is a spectacularly bad idea. But then, anyone who has ever tried submitting changes to the collected works of Shakespeare already knew that. Many people have taken the works of Shakespeare and modified them. Several successful movies, musicals, etc. come to mind. Treating natural language text as source code is only a bad idea in that the compiler won't like it. What the free software community would like is a license that would allow it to take the text an RFC and use that text for writing software, other standards (or non-standards), etc. We don't have any need --- or I hope want --- to mis-represent the modified versions as standards of the IETF. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Copying conditions
Harald Tveit Alvestrand [EMAIL PROTECTED] writes: h. --On 7. oktober 2004 13:12 +0200 Simon Josefsson [EMAIL PROTECTED] wrote: As far as I can tell, those rights are only granted to the ISOC and the IETF, not third parties. Solely for the purpose of using the term in RFC 3667, the IETF is defined as: a. IETF: In the context of this document, the IETF includes all individuals who participate in meetings, working groups, mailing lists, functions and other activities which are organized or initiated by ISOC, the IESG or the IAB under the general designation of the Internet Engineering Task Force or IETF, but solely to the extent of such participation. So this means that Simon Josefsson is allowed to exercise the rights Scott quoted and incorporate the executable pieces into running code, but the guy on the next desk, who isn't on any IETF mailing list, is not, even though they work on the same project, for the same employer, under the same laws. If he joins an IETF list (any IETF list), he's allowed to. I don't believe I, nor he, would be able to represent the IETF in a court, as the legal owner for a work, merely because I (he) participate in some mailing list. As far as I can tell, that would ultimately be required if you were to defend the rights to your work. If, instead, third parties where granted rights to create a derivative work from RFCs, both I and he could represent such a third party. Btw, I don't believe I'm a member of any IETF mailing list, although I do participate in them. Hint: gmane.org. Thanks, Simon ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Copying conditions
Simon sez: For IDN, I want to be able to extract the tables from RFC 3454 and use them in my implementation. For Kerberos, I want to be able to use the ASN.1 schema in my implementation, and copy the terminology section into my manual. For SASL, I want to incorporate portions of the introduction section from the RFC into my manual, to make sure some terminology is explained correctly. For GSS-API, I want to be able to copy the C header file with function prototypes into my implementation. just so there is no misunderstanding - the intent of RFC 3668 was to permit such extractions and there was (and is) no desire to restrict such extractions I, as editor, state publicly that I think that RFC 3667 permits such extractions, we (or maybe I) may have not made that clear enough in RFC 3667, but I think that RFC 3667 supports these uses - some people on this list appear to disagree but I don't see much reason to continue to argue about it because I see little reason for someone to think that they would be attacked for making such extractions. I can not conceive of a situation where the IETF (or ISOC) would ever attempt to say that someone cannot do such extractions. I suppose if someone really pissed off a document author that author might try to pull such a ploy - if that were to happen I expect that the question of extractions would be very much of a sideshow in the legal battle - for what it's worth I hereby offer to testify pro bono (but expenses would need to be covered :-) ) to say that we intended that such extractions were permitted. Note that this question is different from the other one in this thread about someone taking text from an IETF RFC with the intent to created a modified version of the RFC. Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Shuffle those deck chairs!
Eric == Eric S Raymond [EMAIL PROTECTED] writes: Eric You've had two direct warnings about this -- the ASF and Eric Debian open letters. They interpreted IETF's passivity on Eric the Sender-ID patent issue as damage and routed around it. Eric If the IETF doesn't get its act together, that *will* happen Eric again. The open-source community and its allies will have Eric no choice but to increasingly route around IETF, and IETF Eric will become increasingly irrelevant. I'm a bit confused here. As I understand things, Debian and ASF provided input to an IETF consensus call. They asked us not to approve a standard that depended on certain IPR. Based on that input and other input received by the working group, the chairs decided that they did not have consensus to advance a standard based on this IPR. I.E. The IETF did exactly what Debian and ASF asked us to do. That seems like a reasonable outcome under our process. It also seems directly consistent with what Debian and ASF asked the IETF to do. Could you help me understand your concern? --Sam ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
