"Joel M. Halpern" <joel@xxxxxxxxxxxxxxxx> writes: > Simon, you are mixing several issues in your note, including strictly > legal issues and personal preferences. I bring up only one issue here: Can implementers extract and use the ASN.1 module for their implementations legally? > Firstly, it is clear that you (and every other implementor using this > document) needs the ability to extract and use the ASN.1 include in > the document. That is already provided for in BCP 78. The text he > included is exactly the text that BCP 78 tells him to include to do > that. So there is no problem there. I explained in my note that BCP 78 does _not_ provide for that. If you disagree with that, I think you need to show where BCP 78 gives third parties the right to extract and use the ASN.1 module. > Secondly, there is the agreement that implementors, in practice need > the right to modify the code. > BCP 78 in section 3.3 E grants the IETF Trust the rights to make such > code changes, even for use outside the IETF Standards Process. This > appears to mean that the IETF Trust can grant the rights that are > needed. Steven does not need to make any changes to achieve that. Sure. My point is that the implementers are not granted these rights. What rights the IETF Trust are granted seems irrelevant. > Then, you go further and ask him to grant modification rights to all > of the text, not just the code / ASN.1 components. While you have a > clearly stated preference for that grant, it is unfair and > inappropriate of you to assert that the need for that is inherent in > the problem you raise of implementor modification. If you read my note again, and especially the last paragraph, you will see that I quoted the text from RFC 3492 and then said that he might want to restrict the additional rights that are granted to only the ASN.1 module. I think it is unfair to accuse me of asserting that adding exactly that text is required. There are many ways to solve this problem, and I clearly said so. > So, in summary, while I agree that you need the right to modify the > ASN.1, I don't think there is anything that can or should be done in > the document to address that. The document already has the > boilerplate components intended to permit that. No. The boilerplate present does not give me as third party the right to extract and use the ASN.1 module. > If some extra text is needed to ensure modifiablity of the code, it > should be the code, and not "this entire document or any portion of > it." That is up to the each author to decide, of course. Thanks, Simon > Yours, > Joel M. Halpern > > At 05:21 AM 1/13/2007, Simon Josefsson wrote: >>Hi! These documents contains normative ASN.1 modules which, if I >>understand the documents correctly, is typically included in >>implementations of this standard. Is that correct? >> >>The modules contain this notice: >> >> -- Copyright (C) The IETF Trust (2006). This version of >> -- this ASN.1 module is part of RFC XXXX; see the RFC itself >> -- for full legal notices. >> >>The legal notices used by the IETF doesn't grant third parties >>(including implementers of your standard) the right to include >>portions of documents in their implementations. The rights granted by >>RFC 3978/4748 in section 3.3, including the right to extract code >>portions from documents, are only granted to "IETF Trust and the >>IETF", and there is no other license to indicate that any similar >>rights are granted to third parties. >> >>This raises problems for some implementers, because they can't >>implement your standard if they use the ASN.1 module. The alternative >>for them, to re-specify the ASN.1 module from the text (if that is at >>all possible), is bad for interoperability. If you want to enable >>smooth implementation of your standard by everyone (which I hope!), >>here is how to solve it: >> >>There are several solutions to this problem. A simple solution that >>has been used successfully in several documents (RFC 3492, RFC 4398 >>and a few others) is to add, after the above notice, the following >>notice: >> >> -- Regarding this entire document or any portion of it (including >> -- the pseudocode and C code), the author makes no guarantees and >> -- is not responsible for any damage resulting from its use. The >> -- author grants irrevocable permission to anyone to use, modify, >> -- and distribute it in any way that does not diminish the rights >> -- of anyone else to use, modify, and distribute it, provided that >> -- redistributed derivative works do not contain misleading author >> -- or version information. Derivative works need not be licensed >> -- under similar terms. >> >>Note that should be added to all places where the notice about IETF >>Trust and legal notices are added. >> >>This notice would give third parties the necessary rights they need to >>be able to use the normative ASN.1 module from your documents. >> >>Btw, you'd might want to modify the text slightly, so that "pseudocode >>and C code" becomes "ASN.1 module". If you don't want to grant the >>rights to the entire document, grant them only for the ASN.1 module. >> >>Best regards, and thanks in advance, >>Simon >> >>The IESG <iesg-secretary@xxxxxxxx> writes: >> >> > The IESG has received a request from an individual submitter to consider >> > the following documents: >> > >> > - 'Abstract Syntax Notation X (ASN.X) Representation of Encoding >> > Instructions for the XML Encoding Rules (XER) ' >> > <draft-legg-xed-asd-xerei-03.txt> as a Proposed Standard >> > - 'Encoding Instructions for the Robust XML Encoding Rules (RXER) ' >> > <draft-legg-xed-rxer-ei-04.txt> as a Proposed Standard >> > - 'Abstract Syntax Notation X (ASN.X) Representation of Encoding >> > Instructions for the Generic String Encoding Rules (GSER) ' >> > <draft-legg-xed-asd-gserei-03.txt> as a Proposed Standard >> > - 'Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One >> > (ASN.1) ' >> > <draft-legg-xed-rxer-07.txt> as a Proposed Standard >> > - 'Abstract Syntax Notation X (ASN.X) ' >> > <draft-legg-xed-asd-07.txt> as a Proposed Standard >> > >> > The IESG plans to make a decision in the next few weeks, and solicits >> > final comments on this action. Please send substantive comments to the >> > ietf@xxxxxxxx mailing lists by 2007-02-14. Exceptionally, >> > comments may be sent to iesg@xxxxxxxx instead. In either case, please >> > retain the beginning of the Subject line to allow automated sorting. >> > >> > The file can be obtained via >> > http://www.ietf.org/internet-drafts/draft-legg-xed-asd-xerei-03.txt >> > http://www.ietf.org/internet-drafts/draft-legg-xed-rxer-ei-04.txt >> > http://www.ietf.org/internet-drafts/draft-legg-xed-asd-gserei-03.txt >> > http://www.ietf.org/internet-drafts/draft-legg-xed-rxer-07.txt >> > http://www.ietf.org/internet-drafts/draft-legg-xed-asd-07.txt >> > >> > >> > IESG discussion can be tracked via >> > >> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10739&rfc_flag=0 >> >>_______________________________________________ >>Ietf mailing list >>Ietf@xxxxxxxx >>https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf