Subject: RE: Comments to WG meeting

From: [email-masked]
Date: Tue, 11 Jul 2006 15:16:15 -0400

Simon,

> I don't understand the questions in the "Proposed Excerpt Policy"
> slide.  If code excerpts are permitted and MUST be modifiable -- which
> BCP78 apparently already intend to say if I understand Jorge correctly
> -- that is sufficient to be included in GPLed code.  No additional
> rights are needed from the author, if I understand the slide
> correctly.

IMHO, that ought to be the case.  On reflection, I disagree with what
I believe was asserted in the meeting - namely that the RFC document
author should control whether code from an RFC can be placed under GPL.
That seems wrong - IETF ought not to aid/abet that sort of behavior
any more than it ought to aid/abet prohibitions on commercial use of
code in an RFC.  Code published in an RFC should be freely usable by
anyone who wants to implement the protocol in the RFC, period - I
base this assertion on the assumption that the code in the RFC is
essential to implementing the protocol in the RFC.

There is a related issue, in that if code goes under a license such as
the GPL and gets modified, it may not be possible to put the modifications
back into the IETF to revise the RFC.  To deal with this, I suggest
instructing the IETF Trust that:
- RFC code excerpts should be free software (e.g., BSD license) that
	can be used for any purpose.
- Modifications to RFC code excerpts should continue to be free 
	software to the extent legally possible.
For open source, I can see how to achieve that - the IETF free software
license for RFC code excerpts would say that if the source code containing
the modified RFC excerpt is publicly redistributed, then the IETF free
software license applies to the modified RFC code excerpt (and only to
that excerpt, as the "derived work") in the redistributed code.  I don't
know what to do for commercial closed source.

> I disagree with "Text excerpts MUST NOT be modified".  We have plenty
> of running code in this area -- the getaddrinfo man page in Solaris
> and excerpts from RFCs in free source code -- which to me suggest that
> we should permit modifications of text excerpts.  People have been
> putting excerpts from RFCs in modifiable texts for years, and doing so
> appear to further the goals of the IETF.  I don't see how the IETF's
> goals are furthered by forbidding this commonly used practice.  There
> are valid concerns with permitting modifications, but I think a better
> balance could be found here.
> 
> I agree with David Blacka (?), and would like to thank him for
> mentioning this, that we should analyze the consequences for the
> examples I gave in Vancouver when there is a new policy.  This also
> relates to Klensin's (?) request that we review the policy in a
> careful paranoid way instead of assuming that whatever we come up with
> is clear and correct.

That was me.  While I'm not sure I agree with all of your examples,
I strongly believe that the consequences for those examples need to
be understood by the WG as part of making the decision.  I need to
go back and look at them in my "copious spare time" ...

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

---

From: "todd glassey" <[email-masked]>
Date: Tue, 11 Jul 2006 12:42:11 -0700

David in order for the Author to do any kind of controlling of the code
rights within the submission the Author as they are named MUST have a legal
power of attorney for the other contributors and their sponsors too. The
IETF's license do not do this today and while some may not feel it an
issue - I believe it to be one.

Todd

---

From: "Bede B. McCall" <[email-masked]>
Date: Tue, 11 Jul 2006 19:46:46 -0400 (EDT)

From: [email-masked]
   Date: Tue, 11 Jul 2006 15:16:15 -0400

   [...]

   IMHO, that ought to be the case.  On reflection, I disagree with
   what I believe was asserted in the meeting - namely that the RFC
   document author should control whether code from an RFC can be
   placed under GPL. That seems wrong - IETF ought not to aid/abet
   that sort of behavior any more than it ought to aid/abet
   prohibitions on commercial use of code in an RFC.  Code published
   in an RFC should be freely usable by anyone who wants to implement
   the protocol in the RFC, period - I base this assertion on the
   assumption that the code in the RFC is essential to implementing
   the protocol in the RFC.

I'll second this: it frees the IETF from responsibility for future
use of code examples found in RFCs, and allows authors to retain
their rights.  If an author of some code in an RFC wants to extend
usage rights for "any and all" purposes (e.g., placing code in the
public domain) then s/he is free to do so via a statement in the
RFC.  I note that future uses of such code *could* mean inclusion in a
GPL'ed software package, but that's not going to encumber material
published by the IETF with the author's release.

   There is a related issue, in that if code goes under a license such
   as the GPL and gets modified, it may not be possible to put the
   modifications back into the IETF to revise the RFC.  To deal with
   this, I suggest instructing the IETF Trust that:
   - RFC code excerpts should be free software (e.g., BSD license) that
	   can be used for any purpose.
   - Modifications to RFC code excerpts should continue to be free 
	   software to the extent legally possible.
   For open source, I can see how to achieve that - the IETF free
   software license for RFC code excerpts would say that if the source
   code containing the modified RFC excerpt is publicly redistributed,
   then the IETF free software license applies to the modified RFC
   code excerpt (and only to that excerpt, as the "derived work") in
   the redistributed code.  I don't know what to do for commercial
   closed source.

I think releasing code "for implementation only" as the default
IETF condition should address the potential problems of GPL'ed code.
Again, if a software author also wants to release the code under a
GPL, I believe s/he would be free to do so separately without
entangling the IETF, provided the GPL for the code is not embedded in
the RFC.

A precondition for allowing code examples to appear in an RFC *must*
be that the code is not encumbered in such a way that the IETF cannot
publish it with at least a "for implementation only" kind of license.
An author who proposes to publish a RFC containing proprietary or
encumbered code (including encumbrance via a GPL) should not be
permitted to do so.

The trick is to ensure that the IETF cannot be held liable for
publishing encumbered code that an author knowingly lied about or
unknowingly obtained from a third party who has legitimate restrictive
rights.  This calls for wome form of due diligence.  One possible way
around the problem might be to create a rule similar to the one used
by the WWW Consortium, where disclosure of an encumbrance is mandated
if "personally known" to someone directly involved in the standards
making process.  The primary effect of this kind of rule is to place
responsibility for due diligence in the hands of working group
participants and their peers without mandating any expensive corporate
IPR portfolio searches.

   [...]

--Bede

---

From: Don Armstrong <[email-masked]>
Date: Tue, 11 Jul 2006 17:03:03 -0700

On Tue, 11 Jul 2006, [email-masked] wrote:
> then the IETF free software license applies to the modified RFC code
> excerpt (and only to that excerpt, as the "derived work") in the
> redistributed code.

This has the unfortunate side effect of likely making it GPL (and
other copyleft license) incompatible unless it was very carefully
worded,[1] since it would appear to form some sort of a copyleft.

Would it be enough if outbound was MIT/Expat licensed with a strong
suggestion to contribute changes back to the standards process? This
would enable people to use the code in any implementation, and also
remind everyone that they should participate in the standards process.

> be understood by the WG as part of making the decision. I need to go
> back and look at them in my "copious spare time" ...

I agree. While it's quite likely that the process will result in
something that I'm not completely happy with,[2] it would be really
sad if a decision was reached without understanding exactly the
results of that decision.

Don Armstrong

1: I really suggest avoiding getting into a situtation where IETF is
writing software licenses to the greatest extent possible... as those
who have analyzed many licenses know, it's very, very difficult to get
right.

2: Indeed, I'd be surprised if anyone here is completely happy with
whatever this group decides.
-- 
She was alot like starbucks.
IE, generic and expensive.
 -- hugh macleod http://www.gapingvoid.com/batch3.htm

http://www.donarmstrong.com              http://rzlab.ucr.edu

---

From: "todd glassey" <[email-masked]>
Date: Tue, 11 Jul 2006 17:28:47 -0700

Don, Harald, Jorge  & Rosen... You say the noise factor is high - How about
some silence and an idea that might solve all the problems...  Not that
Harald listens to me, but did you folks ever think that it might be an
easier licensing fit if true Open Source submissions and true GPL
submissions were acceptable and could be propagated through the IETF's
standards process to the End Licensee's with those same rights on them.

Isn't that what everyone wanted? Cool - so the solution I am proposing is
not the licensing of the Standard but the reference ports of it... A subtle
and very powerful difference. So then apply that extra licensing to the
actual stack implementations used to qualify for the protocol. In fact it
might make sense to only license those and for the IETF to always retain
control of the standard itself.

Didn't RSA do this for years? ...

GPL and OSI Ports
--------------------
Look at it this way - the GPL license would be against the particular
implementation of the test-stacks. That would allow anyone to use that
particular code model to produce their own GPL based products. Another stack
could be engineered and submitted as a prototype but use the OSI model, and
a third could be a totally proprietary implementation...

Now add the third one - the proprietary port
----------------------------------------------
Seriously - before you blow this Idea off - think it through - it would work
pretty cool. Don't make one standard make three reference ports in the
IETF's process *(Open Source, GPL, and Proprietary). No one said you
couldn't and since the IETF's value is that its standards process guarantees
interoperability... this is a freaking no brainer - if you folks can get
over that it came from me.

I am actually pretty excited about this - how it works is simple - The IETF
always retains control of the Standards, its the Reference ports
implementing the Standard that are licensed GPL and OSI and Proprietary...
Way cool.

Front-end process changes a tad
---------------------------------
IMHO this WOULD change some of the front end process in that the submitter
would have to choose the type of licensing model for the standard they
wanted and the IETF could easily issue a Standard TRIPLE. A Standard who's
IP was implemented under proprietary models, another implementation of the
same code or protocol under a GNU model and the other to meet Larry Rosen's
OSI Models.

Any push back (other than it came from me?)

Todd

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 13 Jul 2006 09:40:39 +0200

[email-masked] writes:

> IMHO, that ought to be the case.

Agreed.

> On reflection, I disagree with what I believe was asserted in the
> meeting - namely that the RFC document author should control whether
> code from an RFC can be placed under GPL.

Yes, that seems incompatible with permitting modifications of code
portion, which Jorge said already is permitted by RFC 3978.

> essential to implementing the protocol in the RFC.

Right.

> back into the IETF to revise the RFC.

The same holds if code goes into a closed source implementation, such
as Windows or Sun.  I don't think that is a problem.  That usage of
RFCs should be OK, and would reflect reality that the Internet is run
by both closed source and free software.  Having everyone be able to
take portions of RFCs and incorporate them into their products
furthers the goals of the IETF.

> To deal with this, I suggest

It is difficult to judge this without knowing what the "IETF free
software license" would say.

> go back and look at them in my "copious spare time" ...

Yes -- explaining for each example what the consequence would be seem
to be a good sanity test of new rules.  Thanks for bringing it up.

And I agree, you don't have to agree that a particular example should
be permitted, as long as you agree that the actual practical result
for that example matches what you believe the WG intends to do.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 13 Jul 2006 09:48:41 +0200

> IETF condition should address the potential problems of GPL'ed code.

We've already talked about a limited-use license, but, as far as I can
see, such a license cannot be GPL compatible.  I think that
disqualifies that approach.

> publish it with at least a "for implementation only" kind of license.

Note that we already have several examples of RFCs with problematic
licenses, see:

http://www.ietf.org/internet-drafts/draft-josefsson-ipr-notices-00.txt

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 13 Jul 2006 09:55:43 +0200

> remind everyone that they should participate in the standards process.

This is a very good idea.

I believe we should ignore the code vs text rathole, which people
outside of the IETF have spent many cycles on without results, and
write a simple, permissive, license that covers entire RFC documents.

The license that I proposed to use in
draft-josefsson-ipr-rules-update-04.txt is reproduced below.  Many
people contributed to this design.  I believe it solves all the
concerns raised with permitting modifications of RFC (i.e., fake
RFCs).

/Simon

       c.  The Contributor grants third parties the irrevocable
           right to copy, use and distribute the Contribution, 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.