Subject: RE: draft-josefsson-ipr-rules-update-00

From: "Contreras, Jorge" <[email-masked]>
Date: Mon, 17 Oct 2005 18:26:27 -0400

>In my manuals and source code, I am excerpting from RFCs.  The size of
>the material I borrow is more than what is permitted by copyright law.
>So I need a license to be able to use that material.  Even trivial
>modifications, like removing page breaks, is not permitted in RFC
>3978, from what I can tell.

You are right, but Section 2.1 of Scott Bradner's I-D allows that.
Is there a need for more?

_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Oct 2005 00:52:47 +0200

> Is there a need for more?

The combined license you refer to would read:

   a. To the extent that a Contribution or any portion thereof is
      protected by copyright and other rights of authorship, the
      Contributor, and each named co-Contributor, and the organization
      he or she represents or is sponsored by (if any) grant a
      perpetual, irrevocable, non-exclusive, royalty-free, world-wide
      right and license to the ISOC and the IETF under all intellectual
      property rights in the Contribution:
...
 (E)  to extract, copy, publish, display, distribute and incorporate
      into other works, for any purpose (and not limited to use within
      the IETF Standards Process), and to grant third parties
      sublicenses to do the same, any portion of the Contribution
      without modification (other than non-substantive modifications
      such as translation into languages other than English or
      compilation of source code statements into executable code), and
      further provided that the notices required by Sections 5.4 or 5.6
      below, as applicable, are included

That does not grant me the right to make trivial modifications to
Contributions, as far as I can see.

The text grants the ISOC/IETF the right to grant sub-licenses (that
permit modifications) to third parties.

That is definitely not the same thing, as I understand that these
sub-licenses will not be granted without hassle.

Thanks,
Simon

---

From: Ted Hardie <[email-masked]>
Date: Mon, 17 Oct 2005 16:30:33 -0700

>Contributions, as far as I can see.

I assume the line-break issue can be handled under "non-substantive"
modifications.  What, then is "trivial"?  Is there any form of "trivial"
that is "substantive"?
			regards,
					Ted

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Oct 2005 01:35:33 +0200

> modifications.  What, then is "trivial"?  Is there any form of "trivial"

That license does not grant any rights to third parties, so whether
line breaks are substantive or not is irrelevant.  Even if line breaks
are non-substantive (which I'd agree to), I don't have the right to
make that change.

The license above only grant a right to the IETF/ISOC to grant further
sub-licenses to others.  This isn't likely to happen on a wide basis,
so effectively that clause (without modification) doesn't apply here.

Regards,
Simon

---

From: Ted Hardie <[email-masked]>
Date: Mon, 17 Oct 2005 16:47:58 -0700

>are non-substantive (which I'd agree to), I don't have the right to

Okay, but would you mind actually answering the question?  What
forms of modifications do you see as "trivial"?  Are there any
that are "substantive"?

Whether the license above grants you this or not, the right to
make "trivial" modifications is part of what you want.  I'd
like to understand what that entails.	

			regards,
				Ted

---

From: "todd glassey" <[email-masked]>
Date: Mon, 17 Oct 2005 17:21:40 -0700

----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: "Ted Hardie" <[email-masked]>
Cc: "Contreras, Jorge" <[email-masked]>; <[email-masked]>;
"Scott Bradner" <[email-masked]>; <[email-masked]>
Sent: Monday, October 17, 2005 4:35 PM
Subject: Re: draft-josefsson-ipr-rules-update-00

> >>The combined license you refer to would read:

Btw - Does this mean they have to grant this to the IETF in order to
participate?

> >>      property rights in the Contribution:

Yow - so how many instances of affadavits does this take to substantiate?
Lets see - three people working on a project and all are employed by
different employers, that implies at minimum three and more likely six
seperate sets of releases right???

Also the phrase "All intellectual property rights" is ambiguous and needs to
be very carefully and thoroughly defined.

> >>      compilation of source code statements into executable code)

OK so how about a scenario where a document like a ISO standard is partially
referenced? - the stakeholders in this case would be ISO and its efforts
right? So how then can someone sign that away to the IETF? Or in PKIX's case
it cannot scede rights to x.509 defs to the ISOC, becuase the x.509
consortia already holds them. So how does this work?

> >.       , and

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Oct 2005 12:43:54 +0200

> like to understand what that entails.	

A list of modifications forbidden by RFC 3978 that I want to be able
to do:

* Typographical changes.  Compare the table at:
  http://josefsson.org/gss/manual/gss.html#Context_002dLevel-Routines
  with the table in section 2 of RFC 2744.  I have added punctuation
  because the RFC uses inconsistent punctuation, and I have removed
  the "section" column because that column refer to RFC internal
  section numbers.

* Modify ASN.1 schemas to make minor adjustments.  Compare the ASN.1
  schema I use for Kerberos 5 in Shishi:
  http://josefsson.org/cgi-bin/viewcvs.cgi/shishi/lib/kerberos5.asn1?rev=1.8&view=auto
  with the ASN.1 schema in RFC 4120.  I had to change 'INTEGER
  (0..429467295)' into 'INTEGER' because my ASN.1 library do not
  handle bignums.  This doesn't result in any change of protocol
  behavior, of course.  Other Kerberos 5 implementation need the same
  right.  I looked at both MIT Kerberos 5 and Heimdal, and they both
  ship modified ASN.1 schemas.  In fact, they have modified the
  schemas considerably more than I have.

* Remove non-applicable portions of introductory sections, when
  incorporating them into my manual.  Compare section 3 of RFC 2222
  <with http://josefsson.org/gsasl/manual/gsasl.html#SASL-Overview>.
  I have removed some forward references, such as a sentence:

   SASL mechanism names must be registered with the IANA.  Procedures
   for registering new SASL mechanisms are given in the section
   "Registration procedures".

  Having that specific sentence in my manual isn't useful for the
  reader, but the rest of that text is very useful.

* Extract portions of RFCs into source code comment, after removing
  line breaks and other material.  See:
  http://josefsson.org/cgi-bin/viewcvs.cgi/gsasl/lib/digest-md5/validate.c?rev=1.8&view=auto
  Most of the comments are taken from the RFC, to document which
  MUST/SHOULD requirements are translated into 'if' tests.

* Use tables with Unicode code points from RFCs, e.g., compare RFC
  3454 with how my Libidn is incorporated in GNU Libc:
  http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/libidn/rfc3454.c?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=glibc
  The tables are modified heavily, typographically, from the RFC.

* Extract function comments into source code, and be able to improve
  them over time.  E.g., compare RFC 2744 with:
  http://josefsson.org/cgi-bin/viewcvs.cgi/gss/lib/context.c?rev=1.31&view=auto
  That file contain comments derived from the RFC, but sometimes I
  have improved on the function description with more information that
  the end-user may find helpful.

Of course, this is not an exclusive list.

I hope this helps,
Simon