Subject: Legal Provisions Relating to IETF Documents

From: "Ed Juskevicius" <[email-masked]>
Date: Thu, 3 Jul 2008 20:52:22 -0400

Greetings!  The purpose of this message is:

1) To advise you that the IETF Trustees are working to develop
   a policy for granting rights in IETF documents as required
   by draft-ietf-ipr-outbound-rights-06.txt
2) To invite your review and comment on a draft version of the
   policy, and
3) To announce that the Trustees have requested the IPR WG
   convene during IETF 72 to take comments on the draft policy,
   face to face, in Dublin; the IPR WG meeting is scheduled
   to meet starting at 13h00 local time on Thursday, July 31st.

The draft policy is available for your review in .doc, .pdf, and
.txt formats at: http://trustee.ietf.org/policyandprocedures.html. 
	
Policy areas covered by this draft document are as follows:

 1. Licenses to IETF Documents within the Standards Process
 2. Licenses to IETF Documents outside the Standards Process
 3. Licenses that are *not* granted
 4. License to Code Components
 5. Pre-Existing Documents
 6. License Limitations
 7. Text (i.e., "boilerplate") to be included in IETF Documents
	 
Please note that several portions of the text in the draft policy
are enclosed in <special> brackets. This is to signify text where
your thoughts and suggestions are particularly invited.
	 
The IETF Trustees would like to be in a position to formally adopt
a policy soon after the publication of RFC[ipr-outbound-rights] 
and RFC[ipr-inbound-rights].
	
Your input will be appreciated. Please use the IPR WG mailing list 
for all discussion and comments on this draft.
	 
Best Regards, and Thanks in advance, 

Ed Juskevicius      Ray Pelletier
Chair               Trustee
IETF Trust          IETF Administrative Director
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipr-wg

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 4 Jul 2008 04:56:20 +0200

Ed Juskevicius wrote:

> invite your review and comment on a draft version of the policy

| For ease of reference, Code Components in IETF RFCs may be 
| designated by <LABEL>. 

The <LABEL> is apparently about this -outbound recommendation:

 "define a textual representation to be included in an IETF
  contribution to indicate that a portion of the document is
  considered by the authors (and later the working group, and
  upon approval the IETF) to be code, and to be subject to
  the permissions granted to use code."

Should that get a qualifier such as "where it is not obvious",
and some kind of "end" indicator ?  In mails I sometimes use

~~~ cut ~~~
text
~~~ end ~~~

to indicate snippets, in drafts I got away with indentation.

> review in .doc, .pdf, and .txt formats

At some point in time the boilerplates have to be integrated
in various tools, for that task it would help to have the TXT
version use line length 69, as in an Internet Draft.

> Please note that several portions of the text in the draft
> policy are enclosed in <special> brackets. This is to
> signify text where your thoughts and suggestions are
> particularly invited.

Apart from <LABEL> I see only <listed authors> (twice).  If 
that expands into "Copyright 200x IETF Trust and the authors"
it is fine.  Putting the actual names of all co-authors (up
to five on the front page) into the boilerplate could be 
difficult.  The page footer uses "Name, et al." for multiple
authors, or "Name & Name" for two authors, but that's a case
where counting columns determines what works.

IMO saying <listed authors> as you have it, and then let the
RFC-editor and xml2rfc folks figure out how to implement it
might be good enough.  Maybe ask them if you're not sure.

 Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 07 Jul 2008 10:42:41 +1200

Hi,

> (y)  all IETF legends, legal notices and indications of 
> authorship contained in the original IETF RFC must also be 
> included where more than <one half> of an IETF RFC is 
> reproduced in a single document or series of related 
> documents.

A half seems like rather a high limit; a short RFC can be
almost 50% boilerplate anyway. I realise we need an objective
rule, so can I suggest "one fifth"?

> For ease of reference, Code Components in IETF RFCs may be 
> designated by <LABEL>.

How about ...may be enclosed between the marks "<CODE BEGIN>"
and "<CODE END>" ?

> a. General Notice for Internet-Drafts. The following text 
> must appear <at the beginning> of each Internet-Draft:

and

> c. Copyright and License Notice. The following notice must be
> contained at the beginning of each IETF Document (including
> RFCs and Internet-Drafts):

"At the beginning" is not good enough for automated checkers.
I suggest "on the first page" in both cases.

    Brian

---

From: John C Klensin <[email-masked]>
Date: Sun, 06 Jul 2008 19:21:40 -0400

--On Monday, 07 July, 2008 10:42 +1200 Brian E Carpenter
<[email-masked]> wrote:

>...

I would suggest that we would be better served by a little
vagueness here, e.g.,
	
	 ... where a significant excerpt, but certainly no more
	than one-fifth..."

That deliberately doesn't state a simple numerical rule, but
tries to establish the principle that we really expect the
boilerplate to be reproduced in anything but a trivial excerpt.
And if something abusive happens with a shorter excerpt, it
gives us the option of getting a judge to decide.

I assume that the Trust's counsel can come up with better
wording.

  john

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 6 Jul 2008 18:38:28 -0700

But the content of the non-boilerplate portions of the RFC are what 
represent its core value. That and the vetting framework around it. So 
content wise, RFC's are really boilerplate, dialog/description and the core 
IP itself.

That said it is appropriate to build a standard demarcation way for modeling 
all psuedocode whether that's through XML, ASN.1 or whatever...

Todd

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: "Ed Juskevicius" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, July 06, 2008 3:42 PM
Subject: Re: Legal Provisions Relating to IETF Documents

> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.138 / Virus Database: 270.4.5/1537 - Release Date: 7/6/2008 
> 5:26 AM
>
>
>

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 07 Jul 2008 12:52:35 +0200

> .txt formats at: http://trustee.ietf.org/policyandprocedures.html. 

Hi!  Thanks for publishing this for review.  Here are my comments.

Comment #1:

Regarding section 2:

   ii. to copy, publish, display and distribute unmodified portions of
       IETF RFCs and translations thereof, provided that:

     (x) each such portion is clearly attributed to IETF and identifies
         the RFC from which it is taken,

     (y) all IETF legends, legal notices and indications of authorship
         contained in the original IETF RFC must also be included where
         more than <one half> of an IETF RFC is reproduced in a single
         document or series of related documents.

There is an inconsistency with this text compared to the license for
code components: Consider if the portion of the document extracted is
code.  Being bound to the above restrictions goes beyond what the BSD
license requires.  This complicates license-compatibility review, as the
license on the derived code will be BSD-license plus the above two
clauses.  The combination of these clauses is not a license that has
been reviewed for compatibility with other free software licenses.
Creating yet another free software license is typically regarded as a
bad idea.

Fortunately, I believe the intention is that the license for code should
be the modified BSD license and ONLY the modified BSD license.  In other
words, the above license terms are not intended to apply to portions
that is code.  Is my understanding correct?

If so, I suggest to add to section 3 something that captures this
intention.  For example:

       To clarify, the entire license for Code Components is the above
       license, and if you use the above license for a Code Component,
       the license terms in section 2 does not apply to that material.

Comment #2:

Regarding the same text quoted in #1, and as commented by others,
"<one-half>" seems arbitrary and may be problematic for short documents.

I believe that what is legally relevant is the _absolute_ amount of
copyrightable quoted text, not the _relative_ amount.  Thus, consider a
absolute limit rather than a relative limit.

Generally, I think John Klensin's suggestion to make the text a bit
vague is a good idea so I would support that if you don't want to find
an absolute limit.

Comment #3

I suggest to add 'pseudo code' to the list of 'Code Components' in
section 3.a.

Comment #4:

Quoting from your proposal in section 3:

A simple way to solve this would be to use <CODE BEGIN> and <CODE END>,
as suggested by Brian.  I support that suggestion.

However, I believe it is important to ALSO allow a textual way to
describe what is intended to be a Code Component.  This simplify reading
of documents and avoids ugly markups which can become excessive.
Consider a document that contains:

  Appendix A.
    This sections in this Appendix contains a pseudo code implementation
    of the twenty parts of the FOOBAR algorithm.  Each part is intended to
    be treated as a Code Component as described by
    [IETF-Trust-Legal-Provisions].
  Appendix A.1.
    ...
  Appendix A.2
    ...
  Appendix A.20

This reads much better than having to use <CODE BEGIN>..<CODE END>
inside each and every appendix.

Compare Appendix A of RFC 1510 for a real example.

Thus, I suggest to change the above sentence to:

     For ease of reference, portions that are intended to be Code
     Components in IETF RFCs may be placed after a <CODE BEGIN> marker
     and before a <CODE END> marker.  Alternatively, text in the
     document that refer to this rule can be added to denote which
     portions are intended to be regarded as code components.

Comment #5:

Quoting section 3:

       b.  License. Code Components are hereby licensed to each person
       who wishes to receive such a license on the terms of the “BSD
       License”, as follows:

The license quoted isn't the original "BSD License".  The original BSD
license contained an advertisement clause:

  3. All advertising materials mentioning features or use of this software
     must display the following acknowledgement:
       This product includes software developed by the University of
       California, Berkeley and its contributors.

That clause causes license compatibility problems, so I'm happy that you
have removed it.

You also modified other parts of the license, such as replacing
references to the author with references to the IETF Trust and
contributors.  Btw, the word "contributor" is defined in the IETF
documents, but that is not the definition used in the BSD license.

To avoid confusion, it would be better to reflect this in the
description of the license.   I suggest to write "Modified BSD License"
instead of "BSD License".

Comment #6:

Regarding section 5:

   b.  Supersedure. The terms of any license granted under this
   document may be superseded by a written agreement between the IETF
   Trust and the licensee that specifically references and supersedes
   the relevant provisions of this document, except that the IETF Trust
   shall in no event be authorized to grant rights with respect to any
   Contribution in excess of those which it has been granted by the
   Contributor.

This clause seems problematic for code: I don't want to excerpt code
from an RFC under a BSD license and later find out that the license has
been superseded by the GPL.

I suspect the intention behind this clause is that _additional_ rights
could be granted by the IETF Trust to some parties.  Is that correct?

A simple way to solve this would be add another exception: that you
can't negotiate away rights already granted through this document.
Thus, change the text to:

   b.  Supersedure. The terms of any license granted under this
   document may be superseded by a written agreement between the IETF
   Trust and the licensee that specifically references and supersedes
   the relevant provisions of this document.  There are two exceptions:

     i) the IETF Trust shall in no event be authorized to grant rights
     with respect to any Contribution in excess of those which it has
     been granted by the Contributor,

     ii) the new terms cannot grant less rights that are granted through
     this document.

I'm sure you can express this suggestion better with legal help.

Thanks,
Simon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 07 Jul 2008 10:06:16 -0400

Commenting only on one small point where I disagree with Simon.

...
> I suggest to add 'pseudo code' to the list of 'Code Components' in
I would disagree.
pseudo-code is not code.
It can not be compiled.
A working group that really wants it treated as code, can use the 
marking mechanism.  But, by default, pseudo-code is really just fancy 
English.
More to the point, this exact question was discussed by the working 
group, and the working group concluded that pseudo-code did not belong 
in that list.

...

Yours,
Joel M. Halpern

---

From: "Ed Juskevicius" <[email-masked]>
Date: Mon, 7 Jul 2008 10:16:54 -0400

Brian, good feedback. 

Thank You.

Regards,

Ed  J. 

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Sunday, July 06, 2008 6:43 PM
To: Juskevicius, Ed (CAR:1A12)
Cc: [email-masked]
Subject: Re: Legal Provisions Relating to IETF Documents

Hi,

and

    Brian

---

From: "Ed Juskevicius" <[email-masked]>
Date: Mon, 7 Jul 2008 10:18:29 -0400

John wrote:

> I assume that the Trust's counsel can come up with
> Better wording.

Yes, I am sure Jorge can (and will) do that.

Thanks,

Ed

-----Original Message-----
From: John C Klensin [mailto:[email-masked]] 
Sent: Sunday, July 06, 2008 7:22 PM
To: Brian E Carpenter; Juskevicius, Ed (CAR:1A12)
Cc: [email-masked]
Subject: Re: Legal Provisions Relating to IETF Documents

	

  john

---

From: "Ed Juskevicius" <[email-masked]>
Date: Mon, 7 Jul 2008 10:26:54 -0400

Very comprehensive feedback.  Thank You.

I'll ask Jorge to respond to your comment #1.

I agree with you and John with respect to comment #2.

I recall the wg's discussion about pseudo code (in comment #3,
per Joel's message), so I would suggest it *not* be added in
section 3.a. 

I like your comments 4, 5, and 6 too.

Best Regards,

Ed  J.

-----Original Message-----
From: Simon Josefsson [mailto:[email-masked]] 
Sent: Monday, July 07, 2008 6:53 AM
To: Juskevicius, Ed (CAR:1A12)
Cc: [email-masked]
Subject: Re: Legal Provisions Relating to IETF Documents

"Ed Juskevicius" <[email-masked]> writes:

> The draft policy is available for your review in .doc, .pdf, and .txt 
> formats at: http://trustee.ietf.org/policyandprocedures.html.

Comment #1:

Regarding section 2:

Comment #2:

Comment #3

Comment #4:

  Appendix A.
    This sections in this Appendix contains a pseudo code implementation
    of the twenty parts of the FOOBAR algorithm.  Each part is intended
to
    be treated as a Code Component as described by
    [IETF-Trust-Legal-Provisions].
  Appendix A.1.
    ...
  Appendix A.2
    ...
  Appendix A.20

Comment #5:

Quoting section 3:

       b.  License. Code Components are hereby licensed to each person
       who wishes to receive such a license on the terms of the "BSD
       License", as follows:

  3. All advertising materials mentioning features or use of this
software
     must display the following acknowledgement:
       This product includes software developed by the University of
       California, Berkeley and its contributors.

Comment #6:

Regarding section 5:

Thanks,
Simon

---

From: "Ed Juskevicius" <[email-masked]>
Date: Mon, 7 Jul 2008 10:32:31 -0400

Todd: Thank you for your comments on this.

Everyone: I'm a bit surprised that no one has wondered how we will
actually measure the percentage of an RFC that may be reproduced (be it
50% or 20%).  How shall we determine this?  Count the ASCII characters
in the reproduced text, and compare it to the original RFC, or do a word
count, or a page count?

Any suggestions?

Regards,

Ed

-----Original Message-----
From: TS Glassey [mailto:[email-masked]] 
Sent: Sunday, July 06, 2008 9:38 PM
To: Brian E Carpenter; Juskevicius, Ed (CAR:1A12)
Cc: [email-masked]
Subject: Re: Legal Provisions Relating to IETF Documents

But the content of the non-boilerplate portions of the RFC are what
represent its core value. That and the vetting framework around it. So
content wise, RFC's are really boilerplate, dialog/description and the
core IP itself.

That said it is appropriate to build a standard demarcation way for
modeling all psuedocode whether that's through XML, ASN.1 or whatever...

Todd

---

From: "Endre Jarraux Walls" <[email-masked]>
Date: Mon, 7 Jul 2008 11:15:17 -0400

Ed,

Would it make sense to say that only the abstract or summary of an RFC may
be produced instead of percentage or count?

Endre Jarraux Walls
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ed Juskevicius
Sent: Monday, July 07, 2008 10:33 AM
To: TS Glassey; Brian E Carpenter; John C Klensin
Cc: [email-masked]
Subject: RE: Legal Provisions Relating to IETF Documents

Any suggestions?

Regards,

Ed

-----Original Message-----
From: TS Glassey [mailto:[email-masked]] 
Sent: Sunday, July 06, 2008 9:38 PM
To: Brian E Carpenter; Juskevicius, Ed (CAR:1A12)
Cc: [email-masked]
Subject: Re: Legal Provisions Relating to IETF Documents

Todd

---

From: "Ed Juskevicius" <[email-masked]>
Date: Mon, 7 Jul 2008 11:20:46 -0400

That would be an elegant solution, but unfortunately we can't use it.

There are many cases where people have a need to cut and paste some text
from the body of a document.  Thus we need a mechanism to allow
legitimate uses of reproduced text without imposing a lot of
bureaucratic overhead on people (e.g. requiring them to formally request
permission every time they need to do so).

Regards, and Thanks for the comment.

Ed  

-----Original Message-----
From: Endre Jarraux Walls [mailto:[email-masked]] 
Sent: Monday, July 07, 2008 11:15 AM
To: Juskevicius, Ed (CAR:1A12)
Cc: [email-masked]
Subject: RE: Legal Provisions Relating to IETF Documents

Ed,

Would it make sense to say that only the abstract or summary of an RFC
may be produced instead of percentage or count?

Endre Jarraux Walls
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ed Juskevicius
Sent: Monday, July 07, 2008 10:33 AM
To: TS Glassey; Brian E Carpenter; John C Klensin
Cc: [email-masked]
Subject: RE: Legal Provisions Relating to IETF Documents

Any suggestions?

Regards,

Ed

-----Original Message-----
From: TS Glassey [mailto:[email-masked]]
Sent: Sunday, July 06, 2008 9:38 PM
To: Brian E Carpenter; Juskevicius, Ed (CAR:1A12)
Cc: [email-masked]
Subject: Re: Legal Provisions Relating to IETF Documents

Todd

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "Ed Juskevicius" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, July 06, 2008 3:42 PM
Subject: Re: Legal Provisions Relating to IETF Documents

>> contained in the original IETF RFC must also be included where more 
>> than <one half> of an IETF RFC is reproduced in a single document or 
>> series of related documents.
>
>
> A half seems like rather a high limit; a short RFC can be almost 50% 
> boilerplate anyway. I realise we need an objective rule, so can I 
> suggest "one fifth"?
>
>> For ease of reference, Code Components in IETF RFCs may be designated

>> by <LABEL>.
>> a. General Notice for Internet-Drafts. The following text must appear

>> <at the beginning> of each Internet-Draft:
>
> and
>
>> contained at the beginning of each IETF Document (including RFCs and 
>> Internet-Drafts):
>
>

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 7 Jul 2008 11:33:30 -0400

> permission every time they need to do so).

I would make it explicit as a "in any case" - using John Klensin's  
text as a starting point :

(y)  all IETF legends, legal notices and indications of
authorship contained in the original IETF RFC must also be
included where a significant excerpt is quoted verbatim
in a single document or series of related documents. In any
case the IETF legends, legal notices and indications of
authorship must be included if more than one fifth of the ASCII  
characters in the
IETF RFC are quoted in the new document or series of documents.

-----

By the way, should it say here that this does not apply if the quoted  
text is used
in an Internet-Draft ? I know some RFC's quote heavily from earlier  
ones, especially
"bis" documents.

Regards
Marshall

>>> designated

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Jul 2008 11:38:50 -0400

--On Monday, 07 July, 2008 10:32 -0400 Ed Juskevicius
<[email-masked]> wrote:

> Everyone: I'm a bit surprised that no one has wondered how we
> will actually measure the percentage of an RFC that may be
> reproduced (be it 50% or 20%).  How shall we determine this?
> Count the ASCII characters in the reproduced text, and compare
> it to the original RFC, or do a word count, or a page count?
> 
> Any suggestions?

This was one of the reasons I suggested that some deliberate
vagueness might be A Good Thing. 

If you adopt the vague formulation, then it puts people on
notice that trying to engage in hair-splitting about how to
count may get them in trouble.  If you don't, you will end up
needing rules, not only about how to count, but about what
counts (some or all of the boilerplate? headers and footers
including the blank lines and form feeds?).  I think the problem
is better dodged than to engage in hair-splitting of our own.

Put differently, those sentences have two purposes:

	* To provide some guidance about what we expect,
	primarily directed to people who are acting in good
	faith and with good intent.
	
	* To provide a basis for going after someone legally
	should the Trust, presumably with the support of the
	community, conclude that a violation is sufficiently
	egregious and damaging to make that worthwhile.

For the first, "significant" and an approximate ceiling should
be plenty.   For the second, nothing we are likely to want to do
(or to be able to do) is likely to be sufficient... things will
sooner or later come down to the courts making a judgment call.
And, if we try to pin things down for the second, we are very
likely to obscure our intent for the much more common (and
usually important) first case.

Again, please discuss this with Jorge.  If he recommends a
different tradeoff, I think we should follow his advice.  But I
would like to hear the reasoning.

   john

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Jul 2008 11:41:57 -0400

--On Monday, 07 July, 2008 11:33 -0400 Marshall Eubanks
<[email-masked]> wrote:

>...
> By the way, should it say here that this does not apply if the
> quoted text is used
> in an Internet-Draft ? I know some RFC's quote heavily from
> earlier ones, especially
> "bis" documents.
>...

Arggh.  Yes.  Those I-Ds, of course, contain boilerplate
regardless of the amount of text quoted, but it may be newer
boilerplate than that which appears in the RFC and is not RFC
boilerplate in any event.  So some qualification would appear to
be needed ... both for I-Ds and for subsequent publication in
the RFC series.

   john

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 07 Jul 2008 17:42:44 +0200

> IETF RFC are quoted in the new document or series of documents.

I think it would help if there was a concrete example of what "all IETF
legends, legal notices and indications of authorship contained in the
original IETF RFC" actually means in practice.

Also, using 'ASCII characters' as a measurement begs for updates when
I-D's go Unicode. ;)

Taking RFC 5202 as example, does the above terms include all or any or
parts of the following quoted texts:

  1)

Network Working Group
Request for Comments: 5202
Category: Experimental

2)

                                                               P. Jokela
                                            Ericsson Research NomadicLab
                                                            R. Moskowitz
                                                                ICSAlabs
                                                             P. Nikander
                                            Ericsson Research NomadicLab

3)

                                                              April 2008

4)

Using the Encapsulating Security Payload (ESP) Transport Format with the
                      Host Identity Protocol (HIP)

5)

Status of This Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

6)

IESG Note

   The following issues describe IESG concerns about this document.  The
   IESG expects that these issues will be addressed when future versions
   of HIP are designed.

   In case of complex Security Policy Databases (SPDs) and the co-
   existence of HIP and security-related protocols such as IKE,
   implementors may encounter conditions that are unspecified in these
   documents.  For example, when the SPD defines an IP address subnet to
   be protected and a HIP host is residing in that IP address area,
   there is a possibility that the communication is encrypted multiple
   times.  Readers are advised to pay special attention when running HIP
   with complex SPD settings.  Future specifications should clearly
   define when multiple encryption is intended, and when it should be
   avoided.

7)

Abstract

   This memo specifies an Encapsulated Security Payload (ESP) based
   mechanism for transmission of user data packets, to be used with the
   Host Identity Protocol (HIP).

8)

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

9)

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

10)

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

11)

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

12)

Jokela, et al.                Experimental                      [Page 1]
^L
RFC 5202        Using the ESP Transport Format with HIP       April 2008

/Simon

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 7 Jul 2008 12:24:15 -0400

> Also, using 'ASCII characters' as a measurement begs for updates when

Indeed. This would also be true if we ever allow PDF or other RFCs  
with embedded images.

My primary point was to set a vague "reasonable" limit and also a hard  
limit that
could be used to go after scofflaws. The count could be bytes, or even  
lines of text,
but in my opinion it should be definite.

> parts of the following quoted texts:

I think that, since the new system will be to take boiler plate out of  
the documents and
include a pointer to a web site containing it, this document could  
include a pointer
to a web site containing what is meant by the above terms.

Regards
Marshall

>                                                               P.  
> Jokela
>                                                            R.  
> Moskowitz
>                                                             P.  
> Nikander
>                                                              April  
> 2008

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 7 Jul 2008 09:24:31 -0700

Joel - why would you say something so blazingly stupid?

----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
To: "Simon Josefsson" <[email-masked]>
Cc: <[email-masked]>; "Ed Juskevicius" <[email-masked]>
Sent: Monday, July 07, 2008 7:06 AM
Subject: Re: Legal Provisions Relating to IETF Documents

>> I suggest to add 'pseudo code' to the list of 'Code Components' in

Yeah - well - I disagree with you Joel...

> It can not be compiled.

Sure it can - ASN.1 Code is pseudocode...  ANY two-pass complier does this 
ALSO by pure definition... they have a Front-End which converts the Language 
Statement's to an intermediary coding model called - "Psuedo code". This is 
machine independant and is eaten by the back-end (the Code Generator) of the 
compiler to create the unlinked executable of the source code. From their 
the Link Editor can resolve any dangling or externals and in doing so make 
the binary output of the compiler executable in that OS Context.

So then the meta or psuedo-code pass is the first pass, and then the 
psuedo-code it produces is then compiled into machine executable code for 
the supported architectures by the Code Generator. Since most two-pass 
compilers allow for discrete hand-done optimization this is claim of yours 
is even more inaccurate since it involves hand tweaking the psuedocode 
itself...

Besides anything that can be patented needs to be representable here in 
standards as well. And the reason is that the IETF's actions do incredible 
damage to IP in making it very difficult to control. Further this opens the 
IETF and those participants involved in electronic frauds as well whether 
you like it or claim this isnt true...

> A working group that really wants it treated as code, can use the marking 
> mechanism.  But, by default, pseudo-code is really just fancy English.
>
> More to the point, this exact question was discussed by the working group, 
> and the working group concluded that pseudo-code did not belong in that 
> list.
>
> ...
>
> Yours,
> Joel M. Halpern
> Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 
> 270.4.5/1537 - Release Date: 7/6/2008 5:26 AM
>
>
>

---

From: Lucy Lynch <[email-masked]>
Date: Mon, 7 Jul 2008 09:39:54 -0700 (PDT)

> Joel - why would you say something so blazingly stupid?

OK, enough.

I find this kind of list behavior completely unacceptable and
respectfully request that either TS Glassey mitigate his
current mode immediately or the list owner take steps to
moderate his participation.

I'm feed up.

- Lucy

> ----- Original Message ----- From: "Joel M. Halpern" <[email-masked]>
> compiler to create the unlinked executable of the source code. From their the 
> Link Editor can resolve any dangling or externals and in doing so make the 
> binary output of the compiler executable in that OS Context.
>
> psuedo-code it produces is then compiled into machine executable code for the 
> supported architectures by the Code Generator. Since most two-pass compilers 
> allow for discrete hand-done optimization this is claim of yours is even more 
> inaccurate since it involves hand tweaking the psuedocode itself...
>
> IETF and those participants involved in electronic frauds as well whether you 
> like it or claim this isnt true...
>
>

---

From: "Lawrence Rosen" <[email-masked]>
Date: Mon, 7 Jul 2008 10:43:59 -0700

> in an Internet-Draft ? I know some RFC's quote heavily from earlier

Percentages are generally unimportant to copyright law and the court cases
regarding the right to copy, to quote, and to prepare derivative works. Nor
do they reflect the actual needs of our users to quote as liberally as
necessary in order to implement and document the IETF RFC specification.

Unless IETF specifications are freely available for copying and
implementation, these rules that you are suggesting are merely confusing
impediments to community sharing. I suggest you justify your percentages on
the basis of your supposed need to protect the other eighty percent of the
words in IETF RFCs.

In other words, +1 to Ed Juskevicius' comment. 
-1 to any limitation on the amount of text that can be copied from RFCs.

/Larry

Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243
Skype: LawrenceRosen

> Of Marshall Eubanks
> Sent: Monday, July 07, 2008 8:34 AM
> To: Ed Juskevicius
> Cc: [email-masked]

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 7 Jul 2008 11:03:11 -0700

Ed
The patent and copyright laws do not allow for this. The IETF's publishing 
desk MAY ONLY publish IP that the IETF has
    1)    Clearly assigned title to, and for which there are not already 
others in the Industry claiming ownership of that IP.
    2)    NO specific IPR statement's claiming ownership of that IP.

Since violating either of these shows a clear "conspiracy to put in place 
and operate a system outside of US IP Laws" such that IP is made essentially 
unprotectable.

By the way - writing a technical work paper about someone elses IP doesn't 
get you around the issues of patent actions and damages that the IETF's 
actions cause. Publishing ANYTHING against IP where an IPR has been filed 
will also open those parties to litigation based on their damaging of that 
IP.

I am betting also that there is and will be ongoing grounds for litigation 
against the IETF until it gets its act together with regard to US IP Law.

Todd Glassey

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 7 Jul 2008 11:50:22 -0700

----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
To: "Ed Juskevicius" <[email-masked]>; "Brian E Carpenter"
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, July 07, 2008 8:38 AM
Subject: RE: Legal Provisions Relating to IETF Documents

> vagueness might be A Good Thing.

Vagueness in legal document's tends to make them unenforceable. They need to 
be specific and very crisp. Also they need to be easily understood by 
someone reading them, meaning that all of the attached document's need to be 
thoroughly enumerated in the document's themselves and not left as external 
references with no way of proving a knowing or informed consent decision was 
made when submitting that IP to the IETF.

> count may get them in trouble.

Not according to the Patent Examiner's or the Attorneys at the US PTO who I
have posed these questions too. Vague formulations mean that the standards
are in and of themselves vague and that they cannot be controlled by IP
Licensing for their use making their value nil for republication.

>  If you don't, you will end up
> including the blank lines and form feeds?).

Funny how the IETF is the only standards body saying "no" to this 
requirement.

>  I think the problem

You mean by intentionally creating a new problem?

> faith and with good intent.

Yes... "Some Guidance" is not enough. There needs to be very specific
guidance about what is and is not expected and what will and will not be
done. Acting in Good Faith is really hard to prove for the IETF since it
regularly and intentionally (the archives prove this again and again) put in
place rules and processes which make it more difficult to enforce IP
Ownership.

> egregious and damaging to make that worthwhile.

That basis already exists.

> would like to hear the reasoning.

I don't think Jorge should sit as the IETF's counsel anymore... he is
involved in submitting work product as a participant here in the IPR WG and
that constrains his conflict of interest relationship with the IETF. I know
that many of you don't want this to be true, but it is IMHO.

> Version: 8.0.138 / Virus Database: 270.4.6/1538 - Release Date: 7/7/2008
> 7:40 AM
>
>
>

---

From: "Contreras, Jorge" <[email-masked]>
Date: Tue, 8 Jul 2008 07:58:23 -0400

> I assume that the Trust's counsel can come up with better

Not necessarily better, but here's an alternative:

"... where any substantial portion of the text of an IETF RFC, 
and in any event where more than one-fifth of such text, is
reproduced..."
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipr-wg

---

From: "Contreras, Jorge" <[email-masked]>
Date: Tue, 8 Jul 2008 08:05:48 -0400

>Simon wrote:

> that is code.  Is my understanding correct?

Correct

>        the license terms in section 2 does not apply to that material.
In Section 2, we can say that the license for excerpts is 
"subject to the special rights with respect to Code Components 
granted under Section 3".

> That clause causes license compatibility problems, so I'm 

We are using the "New and Simplified BSD License" which is published
by opensource.org at:
http://www.opensource.org/licenses/bsd-license.php

> contributors.  

I believe this is what the BSD License means for the user to do.  

> instead of "BSD License".

I don't think this is necessary.  Can you review with the N&S BSD
in mind?
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipr-wg

---

From: "Contreras, Jorge" <[email-masked]>
Date: Tue, 8 Jul 2008 08:08:47 -0400

Correct

>      ii) the new terms cannot grant less rights that are 

I think that your item (ii) is a great idea.  How about the following
tweaks:

"ii) the rights granted shall not be less than those otherwise granted
under this document."
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipr-wg

---

From: "Contreras, Jorge" <[email-masked]>
Date: Tue, 8 Jul 2008 08:10:49 -0400

> in an Internet-Draft ? I know some RFC's quote heavily from earlier  

This discussion only relates to use "outside" the IETF Standards
Process.  Any use in I-Ds is permitted, whether one word or the entire
text.
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipr-wg

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 08 Jul 2008 16:39:23 +0200

> granted under Section 3".

I don't see how that would solve the problem.  Where would you add that
text?  There are several clauses in section 2 that is not about
excerpts.  They could be interpreted as applying beyond the license
given in section 3, if there is no clarification that the section 3
license is all that is relevant for code.

To be precise, the above text would not make it clear that code
components is ONLY licensed under the BSD license in section 3 to me.

If there were text in section 3 that explicitly said that the text in
section 2 does not apply to code components that would simplify license
review of code components derived from RFCs.

If this is not made clear, one may seem to need to evaluate how (at
least) section 2.d, 2.e and 2.f interacts with the BSD license.

> http://www.opensource.org/licenses/bsd-license.php

Thanks for the pointer.  It may be useful to add this link to the
document, for reference.

> I believe this is what the BSD License means for the user to do.  

Normally OWNER is replaced by the copyright holder of the code, which
isn't what is done here.

> I don't think this is necessary.  Can you review with the N&S BSD

The differences to the BSD license given at opensource.org and the one
proposed by the IETF Trust are:

1) The OWNER (i.e., copyright holder) mentions the IETF Trust and the
RFC authors, rather than the name of the copyright holder of the code.
It is common for code authors (and copyright holder) to be different
than the RFC authors.

2) The third clause adds "Internet Society, IETF or IETF Trust" which
goes beyond what is normally part of a BSD license.

3) The license quoted on the URL above says "its contributors" but that
has been modified into "specific contributors" in your version of the
license.

The end result is that the license is a modified BSD license.  That is a
rather common situation with the BSD license, since the license text
refers to various different entities.  Even though the situation is
wide-spread, it is in my opinion sub-optimal.

Compare the text with the "MIT License" as describe on:

http://www.opensource.org/licenses/mit-license.html

That is simpler and avoids referring to anyone but the copyright holder.

Thanks,
Simon

---

From: "TS Glassey" <[email-masked]>
Date: Tue, 8 Jul 2008 07:40:23 -0700

Jorge - My understanding is that I-D's ARE NOT usable outside the IETF's 
process. That no license to develop that IP is conveyed to anyone and that 
an I-D is a solicitation to create a WG or a new RFC, but that in and of 
itself it is not a standards track document in the sense that its IP can be 
used or that it is conveyed to the trust in the same form as the RFC content 
is trying to be here.

Todd Glassey

----- Original Message ----- 
From: "Contreras, Jorge" <[email-masked]>
To: "Marshall Eubanks" <[email-masked]>; "Ed Juskevicius" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 08, 2008 5:10 AM
Subject: RE: Legal Provisions Relating to IETF Documents: Extracts

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 08 Jul 2008 16:43:22 +0200

>> could be granted by the IETF Trust to some parties.  Is that correct?

Thanks for confirmation.

> "ii) the rights granted shall not be less than those otherwise granted

Excellent.

Thanks,
Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Jul 2008 11:21:55 +1200

> and in any event where more than one-fifth of such text, is

Yes, that is about right IMHO.

    Brian

---

From: "Contreras, Jorge" <[email-masked]>
Date: Tue, 8 Jul 2008 19:42:51 -0400

> Jorge - My understanding is that I-D's ARE NOT usable outside 
> the IETF's process. 

Correct

> That no license to develop that IP is conveyed to 
> anyone 

Not true.  A license is granted to IETF Participants to 
use the I-D material in the IETF Standards Process

> and that an I-D is a solicitation to create a WG or a new RFC, but 
> that in and of

---

From: "TS Glassey" <[email-masked]>
Date: Tue, 8 Jul 2008 16:56:11 -0700

Jorge - in response to the NOT TRUE response of yours below.
-----------

Respectfully - Counselor - you are dead wrong here I think. Let me 
explain... The problem is that there is NO IETF Standard Underway  when most 
I-D's are published, and that is the flaw there.

The whole purpose of the I-D is to solicit a WG to accept an effort or to 
start the basis of a RFC. When that RFC itself is published and or a WG 
Formally accepts a filing to create new IP which didn't exist externally and 
allows that to formally become a named project,  that and ONLY THAT formally 
starts that standards effort, otherwise there is no "Standards Track" 
underway when that I-D was filed and that is unarguable.  The logic is 
really easy once you draw the workflow out to see where the flaws are here.

Because of this I-D's are essentially solicitation-document's and not one's 
of technical collaboration inside the IETF generally speaking. There may be 
some minor instances where this turns out to not be true but in 99% of all 
instances I am betting it is true...

Also since there may be external IP issues regarding ownership of materials 
in that I-D - as there was in a number of the I-D's that violated my IPR 
Notice (IPR201), this is even more true, since the IETF cannot possibly 
claim it owns core IP in an I-D when someone else pops up and says - Uh 
that's our patent that is being infringed there, this also mandates that 
I-D's are maintained outside the Standards Process as reference IP.

Todd Glassey

----- Original Message ----- 
From: "Contreras, Jorge" <[email-masked]>
To: "TS Glassey" <[email-masked]>; "Marshall Eubanks" 
<[email-masked]>; "Ed Juskevicius" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 08, 2008 4:42 PM
Subject: RE: Legal Provisions Relating to IETF Documents: Extracts

Correct

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.138 / Virus Database: 270.4.6/1540 - Release Date: 7/8/2008 
6:33 AM

---

From: John C Klensin <[email-masked]>
Date: Tue, 08 Jul 2008 20:33:20 -0400

--On Wednesday, 09 July, 2008 11:21 +1200 Brian E Carpenter
<[email-masked]> wrote:

>> "... where any substantial portion of the text of an IETF
>> RFC,  and in any event where more than one-fifth of such
>> text, is reproduced..."
>> 
> 

WFM
   john

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 8 Jul 2008 20:36:17 -0400

>> Yes, that is about right IMHO.

+1

Marshall

---

From: "Contreras, Jorge" <[email-masked]>
Date: Tue, 15 Jul 2008 22:08:10 -0400

> might be good enough.  Maybe ask them if you're not sure.

Yes, the intent was to say "listed authors" or a variant
thereof, not to list everyone's name in the copyright notice.
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipr-wg

---

From: "TS Glassey" <[email-masked]>
Date: Wed, 16 Jul 2008 07:49:15 -0700

The problem Jorge is that these are NOT literary works, but descriptions of 
specific technology, meaning that per Patent Requirement's all of the 
"Inventor's" need to be listed. This is very important in maintaining IP 
rights moving forward unless the IETF's intent is to prevent the global 
protection of IP's that enter the IETF post BCP78.

If so I assure you that quite a bit of litigation *** WILL *** take place 
over this. Sorry but it is what it is.

Todd Glassey

----- Original Message ----- 
From: "Contreras, Jorge" <[email-masked]>
To: "Frank Ellermann" <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, July 15, 2008 7:08 PM
Subject: RE: Legal Provisions Relating to IETF Documents: authors

> Version: 8.0.138 / Virus Database: 270.4.11/1554 - Release Date: 7/15/2008 
> 6:03 PM
>
>
>