Subject: RE: Going too far: draft-josefsson-ipr-rules-update-00 and draft- ietf-ipr-rules-update-01

From: [email-masked]
Date: Mon, 31 Oct 2005 19:07:48 -0500

John,

> Were the IETF to adopt the position that anything that it posts
> as an I-D or publishes as a standard can be used, in any way,
> with or without modification, and for any purpose --which is
> what you appear to want-- I believe that we would see the range
> of participation decrease.  I also believe that would weaken our
> standards as credible interoperability specifications, perhaps
> to the point of uselessness.

I think "gets as an I-D" may be the problem here.  Once something
is published as an RFC, that text (IMHO) has essentially no economic
value from a copyright standpoint, and it's in the IETF's interest
to make RFCs widely available.  Would it be useful to put or allow
a "sunset clause" on the rights granted to the IETF for an I-D,
so that if the I-D expires, the rights grant expires with it?

More to the point, doesn't the current optional restriction in
Section 5.3 of RFC 3978:

    "This document may only be posted in an Internet-Draft."

already accomplish this purpose?  When the I-D expires, it ceases
to exist, and hence any rights transferred to the IETF to enable
its posting should likewise cease to exist, right?  Jorge?

This can't be used for a standards-track draft, but once a draft
has been designated as standards-track, it seems to me that the
authors (and their employers) should be behaving as if the draft
will become an RFC.  In turn, I think Simon's only interested in
RFCs, and primarily standards track RFCs, so I don't see this
as a problem for his goals.

> While the example given in the I-D:
> 
> 		One example of where the IETF might grant such a right
> 		is the case where another standards development
> 		organization (SDO) wants to update or extend an IETF
> 		technology (which would normally be done by the SDO
> 		sending their requirements to the IETF) but the IETF no
> 		longer has a working group focused on the particular
> 		technology and the IETF does not have the interest to
> 		create a new working group.
> 
> seems quite reasonable to me, that need could be captured by
> language authorizing the IETF to permit derivative works to
> facilitate further development of standards directly related to
> IETF work.  That should be fairly clear as to intent and would
> make a judgment about "directly related" appealable, if
> necessary.  By contrast, authorization for any use other than
> exact excerpts (or translations of them) with attribution seems
> to me something that should come from the author (or not), given
> our current authorship model.

Unfortunately, (IMHO) that won't solve the problem because "directly
related" is too restrictive.  I would suggest that for a technology
to be "directly related" to the IETF's work, the technology has to
run over IP or something like MPLS, or at least interoperate with
the IETF protocol.

I have the following unfortunate worked example that may be the
"poster child" for the above proposal:
- A non-IP communication technology needed a security protocol.
- Rather than design their own protocol, the standards body for
	that technology wisely decided to reuse and adapt an existing
	IETF protocol.  This was done with the knowledge and
	encouragement of the IETF Security ADs.
- The "best" way to reuse that protocol was to copy large amounts
	of text in order to reduce the likelihood of a subtle change
	to the protocol courtesy of editorial "cleanup".  OTOH, serious
	text and protocol changes were needed because the other
	technology is not based directly on IP or MPLS, etc.  The goal
	was to avoid changes in text that did not require changes, but
	the result necessarily cannot directly interoperate with the
	original IETF protocol.
- The result was large text extracts with significant modifications,
	a "derivative work" well beyond "fair use", and hence one for
	which copyright permission needed to be obtained.
- Much as the IETF might like to, under both RFC 2026 and RFC 3978,
	the IETF does not have sufficient rights to grant the
	necessary copyright permission.
- The IETF protocol document had a single author/editor who was
	willing to grant any reasonable requested permission, but ...
- That author worked for a company, causing a "work for hire"
	issue that required a signature of a corporate officer in
	order to grant any permission ...
- Obtaining that signature required involvement of the company's
	legal department ...
- That legal department raised a number of legal issues requiring
	involvement of the standards body's lawyer. Apparently moving
	copyright permissions across standards bodies with different
	legal frameworks is a non-trivial legal accomplishment.
- Getting to that accomplishment had the potential to take
	*forever* with no	predictable outcome.

Despite the good intentions of all involved, it was necessary to
throw in the towel at this juncture.  The situation had become
LP-Complete (Legal Process Complete) and there was no confidence
that the lawyers and organizations involved could be managed to
a predictable conclusion in a predictable period of time.  Therefore,
the editor for the security standard for this other communication
technology is rewriting significant portions of IETF RFC text
because that's easier to do than managing the lawyers.  

This particular situation is final because we cannot change the
rules retroactively, but it would be a good thing for IETF to
figure out how to avoid this in the future.  Believe it or not,
going to the IESG to obtain the required permission would be easier
than having the lawyers try to figure it out (I can usually
figure out how to work with engineers) :-(.

FYI,
--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
----------------------------------------------------

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of John C Klensin
> Sent: Monday, October 17, 2005 1:30 PM
> To: Simon Josefsson
> Cc: [email-masked]; Scott Bradner; [email-masked]
> Subject: Going too far: draft-josefsson-ipr-rules-update-00 
> and draft-ietf-ipr-rules-update-01
> 
> I've been trying to stay out of this discussion -- there are
> only so many hours in the day.  However...
> 
> I've spent too much of my life trying to convince companies who
> are very sensitive about their internal thinking about designs,
> and IPR more generally, to participate in standards activities.
> I know it is more extreme than anything you have said, but
> certainly one might say that they, and their attitudes that they
> can keep things proprietary, are wrongheaded and hence they
> don't deserve to participate in standards activities.  However,
> standards become useless if not broadly adopted, and telling a
> significant number of materially-concerned organizations to kiss
> off is as, or more, likely to make standards useless as it is
> to, e.g., promote open source.
> 
> It is often the case that agreement can be reached for a company
> to contribute to standards efforts --and to permit their staff/
> employees to participate-- if the release of rights is held to
> the minimum level possible consistent with getting standards
> produced.   Many companies would prefer to participate in
> standards efforts only if they release IPR exclusively on a
> basis of "if, and only if, this is adopted as part of the
> standard, then we will release it, or even guarantee to license
> it --if it is not adopted, we will reclaim all rights, including
> trade secret claims to the extent possible".  The IETF does not
> permit that, but some standards bodies and consortia do.
> 
> Were the IETF to adopt the position that anything that it posts
> as an I-D or publishes as a standard can be used, in any way,
> with or without modification, and for any purpose --which is
> what you appear to want-- I believe that we would see the range
> of participation decrease.  I also believe that would weaken our
> standards as credible interoperability specifications, perhaps
> to the point of uselessness.  
> 
> We need to find a balance between maximizing participation in
> the standards process and use of the standards, exactly as they
> are specified and written, and other goals and ancillary
> purposes.  I think your proposal is somewhat over the line.
> Indeed, I suspect that the additional provisions of
> draft-ietf-ipr-rules-update-01.txt which gives the IETF, rather
> than the author, the ability to control derivative works outside
> the IETF standards process goes too far.  I think that, if the
> IETF is given any additional rights to authorize uses outside
> its standards process, those actions need to be narrowly
> constrained to be in support of the standards process.
> 
> While the example given in the I-D:
> 
> 		One example of where the IETF might grant such a right
> 		is the case where another standards development
> 		organization (SDO) wants to update or extend an IETF
> 		technology (which would normally be done by the SDO
> 		sending their requirements to the IETF) but the IETF no
> 		longer has a working group focused on the particular
> 		technology and the IETF does not have the interest to
> 		create a new working group.
> 
> seems quite reasonable to me, that need could be captured by
> language authorizing the IETF to permit derivative works to
> facilitate further development of standards directly related to
> IETF work.  That should be fairly clear as to intent and would
> make a judgment about "directly related" appealable, if
> necessary.  By contrast, authorization for any use other than
> exact excerpts (or translations of them) with attribution seems
> to me something that should come from the author (or not), given
> our current authorship model.
> 
> An alternative model, which the IETF and its predecessors have
> never used, is actually used by several other standards bodies.
> That approach requires explicit release of any copyright or
> other rights in anything that might go into a document so that
> the documents themselves do not, formally, have authors other
> than the standards bodies and all participation in creating them
> is treated as a work for hire.   For a whole series of reasons,
> I don't think we want to go there, but I don't want to slide
> down the slippery slope in that direction either.
> 
> I also note that managing rights to derivative works that are
> not directly standards-related has costs in both volunteer and
> staff time.  The notion of decisions on a case-by-case basis
> probably implies (the draft is not clear) IESG or IAOC (better,
> but not much) time to review those cases, potentially blocking
> other work.   I am not enthused about having the IETF (or IASA)
> incur those costs or workflow delays.  Perhaps it would be
> reasonable to _permit_ authors to voluntarily transfer the
> responsibility for authorizing such derivatives to the IETF,
> but, if so, I'd expect IASA to establish a fee structure for
> those who request such permission: the costs should not be
> passed on to the standards-producing community.
> 
>      john
> 
> 
> _______________________________________________
> Ipr-wg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipr-wg
> 

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

---

From: John C Klensin <[email-masked]>
Date: Mon, 31 Oct 2005 20:13:08 -0500

--On Monday, 31 October, 2005 19:07 -0500 [email-masked]
wrote:

> John,
> 
>> Were the IETF to adopt the position that anything that it
>> posts as an I-D or publishes as a standard can be used, in
>> any way, with or without modification, and for any purpose
>> --which is what you appear to want-- I believe that we would
>> see the range of participation decrease.  I also believe that
>> would weaken our standards as credible interoperability
>> specifications, perhaps to the point of uselessness.
> 
> I think "gets as an I-D" may be the problem here.  Once
> something is published as an RFC, that text (IMHO) has
> essentially no economic value from a copyright standpoint, and
> it's in the IETF's interest to make RFCs widely available.

Agreed.  For things published in RFC form, I believe the IETF's
interest is limited to attempting to ensure that excerpts and
modified versions not be represented as the real thing.
However, as an author, I may have a continuing interest in the
use of some of the text, especially explanatory text, for other
purposes.  That interest is one of the reasons why our model has
always been that authors grant the IETF and/or RFC Editor or
their agents the rights needed to effectively use and distribute
the document, and little else.   I also need to retain either
sufficient rights to defend my rights or to expect that the IETF
will protect those rights for me.

> Would it be useful to put or allow a "sunset clause" on the
> rights granted to the IETF for an I-D, so that if the I-D
> expires, the rights grant expires with it?

That is among the thing that many of us believed the original
"expires in six months" provision was intended to accomplish, if
only as a useful side-effect.

As an aside, note that the strong implication in the "IETF
Trust" agreement that one or both of the "Settlors" believe that
they own the collection of I-Ds, expired or not, and have the
right to transfer them to the Trust, may make all of these
arguments moot if the IETF accepts that agreement (or is deemed
to have delegated the decision as to whether or not to accept it
to IAOC, which has done so).

> already accomplish this purpose?  When the I-D expires, it
> ceases to exist, and hence any rights transferred to the IETF
> to enable its posting should likewise cease to exist, right?
> Jorge?
 
> This can't be used for a standards-track draft, but once a
> draft has been designated as standards-track, it seems to me
> that the authors (and their employers) should be behaving as
> if the draft will become an RFC.  In turn, I think Simon's
> only interested in RFCs, and primarily standards track RFCs,
> so I don't see this as a problem for his goals.

Perhaps this isn't an issue for Simon, but there are boundary
conditions in the above that have been the source of much trauma
in the past.  If the way in which the condition was applied was
exactly as you suggest, i.e., that I-Ds could be posted with the
optional restriction you identify and then converted to the more
open form when (or after) it is designated as a standards-track
draft, then there would be no issue as far as I'm concerned.
However, (i) it is not clear that we really know what
"designated as standards-track" means and (ii) we have had some
history of WG Chairs or ADs claiming that a WG cannot consider a
document with that restriction, even to the extent of
determining whether to designate it as standards-track, unless
the restriction is first removed.  Since, in particular, there
may be a legitimate interest in the use of text that appears in
an I-D, even one that eventually evolves into an RFC, but does
not end up appearing in an RFC, for some other purposes, that
may be a key issue.

For those of us who even occasionally deal with academic-style
publications, all of this is intimately related to the question
of whether posting of text in an I-D constitutes prior
publication.

>> facilitate further development of standards directly related
>> to IETF work.  That should be fairly clear as to intent and
>> would make a judgment about "directly related" appealable, if
>> exact excerpts (or translations of them) with attribution
>> seems to me something that should come from the author (or
>> not), given our current authorship model.
> 
> Unfortunately, (IMHO) that won't solve the problem because
> "directly related" is too restrictive.  I would suggest that
> for a technology to be "directly related" to the IETF's work,
> the technology has to run over IP or something like MPLS, or
> at least interoperate with the IETF protocol.

Of course, a narrow interpretation of "directly related to the
IETF's work" would exclude some of the IETF's work, especially
if a "run over IP" definition is applied.  Clearly, if we are
going to start splitting that hair, we are going to need a very
precise instrument.

> - The "best" way to reuse that protocol was to copy large
> amounts of text in order to reduce the likelihood of a subtle
> change to the protocol courtesy of editorial "cleanup".

Frankly, almost never.  The "best" way to reuse a protocol from
another standards body --whether the IETF is the provider, the
reuser, or unrelated-- is by reference.  Only that way is there
any hope that the users of the derived or layered protocol will
become aware of, and have the opportunity to adapt to,
substantive problems or errata that are discovered with the
original protocol.  Even if the references have to be annotated
to exclude some characteristics and add others, incorporation by
reference is almost always better than copying of text.

> OTOH, serious 	text and protocol changes were needed because
> the other technology is not based directly on IP or MPLS,
> etc.  The goal 	was to avoid changes in text that did not
> require changes, but 	the result necessarily cannot directly
> interoperate with the original IETF protocol.
> - The result was large text extracts with significant
> modifications, 	a "derivative work" well beyond "fair use",
> and hence one for which copyright permission needed to be
> obtained.
> - Much as the IETF might like to, under both RFC 2026 and RFC
> 3978, the IETF does not have sufficient rights to grant the

And, IMO as long as the IETF continues on its current path of
leaving all reasonable rights with the author, that IETF should
not have the right to grant permission to use large amounts of
text in a different way and for another purpose entirely, which
is what I think you are describing.
  
> - Obtaining that signature required involvement of the
> company's legal department ...
> - That legal department raised a number of legal issues
> requiring involvement of the standards body's lawyer.

So far, this doesn't bother me at all.

> Apparently moving copyright permissions across standards
> bodies with different legal frameworks is a non-trivial legal
> accomplishment. 
> - Getting to that accomplishment had the
> potential to take *forever* with no predictable outcome.

Sad, isn't it?

> Despite the good intentions of all involved, it was necessary
> to throw in the towel at this juncture.  The situation had
> become LP-Complete (Legal Process Complete) and there was no
> confidence that the lawyers and organizations involved could
> be managed to a predictable conclusion in a predictable period
> of time.  Therefore, the editor for the security standard for
> this other communication technology is rewriting significant
> portions of IETF RFC text because that's easier to do than
> managing the lawyers.  

Ok.
 
> going to the IESG to obtain the required permission would be
> easier than having the lawyers try to figure it out (I can
> usually figure out how to work with engineers) :-(.

Oh, I have no trouble believing that at all.  But, if the
company involved believed that it has contributed part or all of
the technology and the author's time to the production of an
IETF Standard, and we continue on our present path*, then that
organization retains rights vis-a-vis completely different uses.

I don't see a problem with that.  If others do, then I think we
need to seriously consider the alternative, not these confusing
and hair-splitting baby steps.    When I've been the editor of
documents going into X3/ INCITS or ISO processes, I've been
asked to sign formal copyright releases that transfer _all_
rights to those bodies.   The last time I did one with X3, the
document I had to sign explicitly claimed (and I was obligated
to acknowledge) that the whole thing had been a work for hire...
hire by X3, not by my employer at the time.   Were we to do
that, we could still, in principle, grant some reuse rights to
the author, which is more than INCITS or ISO typically do, but
the documents would _belong_ to the IETF or its agent, to the
extent that one needs to read the fine print to determine who
the actual editor(s) were (and sometimes the information is not
there either).

For the record, I am personally opposed to our taking that step
and claiming/ demanding, for the IETF, complete ownership of
anything that is suggested for the standards track or published
as a standards-track RFC (two different possible rules).  But I
am even more opposed to incrementally granting more and more
rights to the IETF (actually, presumably, IAOC and the Trust) to
make reuse decisions that are not directly and obviously related
to the IETF's standards process.

    john