headers
Black_David | 1 Nov 2005 01:07

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

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
(Continue reading)

Permalink | Reply | 1 comment |
headers
John C Klensin | 1 Nov 2005 02:13

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


--On Monday, 31 October, 2005 19:07 -0500 Black_David <at> emc.com
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.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Simon Josefsson | 1 Nov 2005 11:46

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

Your story of how restrictive copying condition rules cause problem
was quite interesting.  Just a small remark:

Black_David <at> emc.com writes:

> This particular situation is final because we cannot change the
> rules retroactively

The copying conditions has been changed retroactively already.  When I
asked the RFC Editor about the copying conditions on RFC 1510, they
answered that the rules in RFC 2026 apply retroactively.  See below.

If that retroactive change was done correctly, I don't see why it
cannot be done again.  If it was done incorrectly, it should be
reverted.  In any case, I believe we should clarify what the copying
condition on the early RFCs are.

Thanks,
Simon

P.S.  The content of the URL below can now be found at:
<ftp://ftp.rfc-editor.org/in-notes/rfc-editor/copyright.23Jan01.txt>.

From: RFC Editor <rfc-editor <at> rfc-editor.org>
Subject: Re: Copyright and copying conditions for RFC 1510?
To: Simon Josefsson <jas <at> extundo.com>
Cc: RFC Editor <rfc-editor <at> rfc-editor.org>
Date: Mon, 16 Dec 2002 11:07:28 -0800

Simon,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Black_David | 1 Nov 2005 15:35

Lawyers and text reuse

John Klensin writes:

> > - 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.

When "reuse" means "reuse without change" I agree, but that wasn't
what was going on here (which may be the proverbial "exception that
proves the rule").  In this case, a significant adaptation was
involved due to fundamental technology differences.  The IETF protocol
involved was (not surprisingly) based on IP abstractions such as IP
addresses that do not exist as fundamental elements in the target
non-IP communication technology.  A cross reference to the IETF
protocol accompanied by an extensive list of things that have to
be changed would have resulted in an all-but-unimplementable mess.

> > 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.  
>
(Continue reading)

Permalink | Reply | 501 comments |
headers
Black_David | 1 Nov 2005 15:45

Retroactive changes

Simon Joseffson writes:

> Your story of how restrictive copying condition rules cause problem
> was quite interesting.  Just a small remark:
> 
> Black_David <at> emc.com writes:
> 
> > This particular situation is final because we cannot change the
> > rules retroactively
> 
> The copying conditions has been changed retroactively already.  When I
> asked the RFC Editor about the copying conditions on RFC 1510, they
> answered that the rules in RFC 2026 apply retroactively.  See below.
> 
> If that retroactive change was done correctly, I don't see why it
> cannot be done again.  If it was done incorrectly, it should be
> reverted.  In any case, I believe we should clarify what the copying
> condition on the early RFCs are.

The RFC Editor is not a lawyer.  Absent a solid opinion from Jorge,
I would be concerned that a retroactive change would not stand up
to legal challenge, and hence should not be relied upon, even if
no such challenge is expected or anticipated.  Jorge?

I agree that clarification of the copying conditions, and a change
to allow the sort of text reuse whose failure I described, would
be good things.

Thanks,
--David
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Josefsson | 1 Nov 2005 15:52

Re: Lawyers and text reuse

Black_David <at> emc.com writes:

> The important point to take away from this is that it is a
> non-open-source, non-copyleft, etc. example in which the
> inability of the IETF to permit text reuse got in the way.

Agreed.  I think that point should be stressed more.  The rights that
the free software community need -- to be able to adapt parts of RFCs
into products -- are the same that closed source companies need too.

Having worked with some closed-source products, I know that excerpts
from RFCs pop up in many places.  RFC 2026 permit such usage, since
these excerpt aid in the implementation of the RFC, so previously
there were no problems.

I wonder if corporate lawyers reading RFC 3978 understand how their
engineers are using RFCs, and whether they understand the difference
in the traditional IETF copying conditions and the new license.

Thanks,
Simon
Permalink | Reply | 501 comments |
headers
Sam Hartman | 1 Nov 2005 21:51
Picon
Favicon

PESCI is not moving


Hi.  THe IESG had a call today to discuss role of pesci in the
plenary.

People generally believed that it is too early to give more than a
brief status report on pesci.  Brian will let people know that he has
organized a design team, they had a draft, there was a BOF.  But we
feel that we'll be in a much better position to present specific
recommendations to the community later.

As such, there is no need to move pesci elsewhere.

I want to stress that this does not imply that pesci is not important
or that community input is not required.  It simply means we're too
early to focus a significant plenary discussion on pesci.  

I'm hoping to convince Brian to describe the process he thinks should
be used to approve pesci documents.  There's a bit of a problem in
that he won't be able the shepherd them.  So, he can make
recommendations about the process but until we pick document shepherds
no one can say anything definitive about the process.

--Sam
Permalink | Reply | 0 comments |
headers
Contreras, Jorge | 1 Nov 2005 23:36

RE: Retroactive changes

Retroactive changes are difficult to do, unless implemented
by a governmental body.  The reason is that people who made 
contributions in the past were entitled to rely on the rules
in effect at the time of their contributions.  It is not likely
that you could enforce a retroactive rule change against someone
who relied on the old rule, unless you obtained his or her
consent to the change.

-----Original Message-----
From: ipr-wg-bounces <at> ietf.org [mailto:ipr-wg-bounces <at> ietf.org]On Behalf
Of Black_David <at> emc.com
Sent: Tuesday, November 01, 2005 9:45 AM
To: ipr-wg <at> ietf.org
Subject: Retroactive changes

Simon Joseffson writes:

> Your story of how restrictive copying condition rules cause problem
> was quite interesting.  Just a small remark:
> 
> Black_David <at> emc.com writes:
> 
> > This particular situation is final because we cannot change the
> > rules retroactively
> 
> The copying conditions has been changed retroactively already.  When I
> asked the RFC Editor about the copying conditions on RFC 1510, they
> answered that the rules in RFC 2026 apply retroactively.  See below.
> 
> If that retroactive change was done correctly, I don't see why it
(Continue reading)

Permalink | Reply | 1 comment |
headers
Simon Josefsson | 2 Nov 2005 11:14

Re: Retroactive changes

Perhaps we should ask the RFC Editor to clarify that on:

http://www.rfc-editor.org/copyright.html

I get the impression from that page that RFC 3978 apply to all RFCs.
If I understand you correctly, that doesn't seem to be the case.

It seems that for all RFC copying conditions that have been used
throughout history, the set of RFCs to which they apply to should be
mentioned together with the copying condition rules.

That complexity highlight the importance of acquiring all rights to
documents, so that the IETF have the rights to change copying
conditions retroactively in the future.

Thanks,
Simon

"Contreras, Jorge" <Jorge.Contreras <at> wilmerhale.com> writes:

> Retroactive changes are difficult to do, unless implemented
> by a governmental body.  The reason is that people who made 
> contributions in the past were entitled to rely on the rules
> in effect at the time of their contributions.  It is not likely
> that you could enforce a retroactive rule change against someone
> who relied on the old rule, unless you obtained his or her
> consent to the change.
>
>
> -----Original Message-----
(Continue reading)

Permalink | Reply | 0 comments |
headers
todd.glassey | 2 Nov 2005 15:24
Picon
Favicon

RE: Retroactive changes

Jorge - 
 -------------- Original message ----------------------
From: "Contreras, Jorge" <Jorge.Contreras <at> wilmerhale.com>
> Retroactive changes are difficult to do, unless implemented
> by a governmental body.  

You mean by having those already issued standards or RFC's reclassified by the order of a court becuase of
some failing in the IETF process such that they all were not given the same level of care or entitlement
within the IETF process, right??? 

But this also would open the IETF and all involved to litigation and in my opionion - litigation based on
claims with real merit. So geee Jorge - I agree with you!

> The reason is that people who made 
> contributions in the past were entitled to rely on the rules
> in effect at the time of their contributions.  

Which brings us back to whether the relationship between the Submitter of IP's to the IETF is in fact a party
to a contract spelled out in the terms and conditions that the various iunsundry and convulted RFC's lay out???

> It is not likely
> that you could enforce a retroactive rule change against someone
> who relied on the old rule, unless you obtained his or her
> consent to the change.

There is way more to this than this simple and ludicrous self-evident statement - the fact that the IETF
might try in my opinion DOES create a cause of action to sue the IPR-WG, its Chair, and the IETF Chair and the
ISOC itself.

Anyone want to bet on how far this one would make it in the US Federal Courts?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane