Subject: Re: One copyright issue or Two?

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 09 Jan 2006 19:49:35 +0100

--On fredag, desember 09, 2005 18:06:51 +0100 Simon Josefsson 
<[email-masked]> wrote:

>> Allowing the normative text to be freely modified, however, is IMO
>> unnecessary, and as of yet no one has provided a valid argument as to
>> why such permissions should be given by the IETF outside of
>> tightly-controlled situations, or how it would negatively impact the
>> open source community to not do so, particularly if verbatim quotes were
>> allowed.
>
> If quotes (or tables, or ASN.1 schemas, etc) from RFCs are added to
> free software projects, the quote (or tables, etc) must be modifiable
> in order for the resulting combined work to be distributable under a
> free license.  This argument has been given for many months, and
> nobody has challenged it.
>
> If quotes from a RFC cannot be modified, it is not possible to quote
> RFCs in free software.

Simon,

being deliberately provocative:

Does the GPL require an explicit permission to lie?

A "quote" consists of two things:

- The actual quoted text
- The statement that it is a quote (and possibly where it is from)

There are a number of conventions (such as ellipsis) that are commonly used 
to indicate a modified quote, but I believe that it is quite unreasonable 
to say that GPL software needs the right to make modifications to a quote 
*while continuing to pretend that it's a quote*.

This is, I believe, one reason why we have so much trouble communicating: 
We are failing to distinguish between the case of text *taken* from an RFC 
(or other IETF contribution) and text *based on* an RFC. I think we need to 
distinguish between those things *every single time*.

I (personally) would be reasonably happy to see a regime applied to text I 
authored where "derived works", defined as "anything that doesn't claim to 
be a direct quote", is an OK usage, no matter how it is modified. (Others 
have different opinions.) But I'd be very unhappy with a regime where 
someone can claim that I have given permission to people to claim that I 
wrote words that I did not write.

                           Harald

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

---

From: Don Armstrong <[email-masked]>
Date: Mon, 9 Jan 2006 11:29:58 -0800

On Mon, 09 Jan 2006, Harald Tveit Alvestrand wrote:
> >If quotes from a RFC cannot be modified, it is not possible to
> >quote RFCs in free software.
>
> There are a number of conventions (such as ellipsis) that are
> commonly used to indicate a modified quote, but I believe that it is
> quite unreasonable to say that GPL software needs the right to make
> modifications to a quote *while continuing to pretend that it's a
> quote*.

It's quite appropriate to require indication that a change was made
along the lines of GPL §2a[1], but restricting the changes that can be
made is incompatible with the GPL in most cases.[2] (Local laws which
restrict the types of modifications, such as moral rights, may still
restrict the type of modification that can be made, of course.)

> I (personally) would be reasonably happy to see a regime applied to
> text I authored where "derived works", defined as "anything that
> doesn't claim to be a direct quote", is an OK usage, no matter how
> it is modified.

Right, I don't think anyone of us who are interested in seeing a Free
Software compatible RFC license are asking for that. So long as there
is some way of turning the RFC into a freely modifiable version by
removing text claiming that it is an actual RFC, that would be
sufficient. [Substitute whatever the WG decides should be able to be
modifiable for RFC above.]

Don Armstrong

1: 2a: a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.[3]

2: 2: "when you distribute the same sections as part of a whole which
is a work based on the Program, the distribution of the whole must be
on the terms of this License, whose permissions for other licensees
extend to the entire whole, and thus to each and every part regardless
of who wrote it."[3]

3: http://www.gnu.org/licenses/gpl.html
-- 
Frankly, if ignoring inane opinions and noisy people and not flaming
them to crisp is bad behaviour, I have not yet achieved a state of
nirvana.
 -- Manoj Srivastava in [email-masked]

http://www.donarmstrong.com              http://rzlab.ucr.edu
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 10 Jan 2006 13:40:14 +0100

> Does the GPL require an explicit permission to lie?

No.

> There are a number of conventions (such as ellipsis) that are commonly
> used to indicate a modified quote, but I believe that it is quite
> unreasonable to say that GPL software needs the right to make

Of course.  Claiming that anything is something when it isn't is
fraud.

This seem to have little to do with the license discussion as far as I
can see, our assumption is that people follow licenses and rules.

> This is, I believe, one reason why we have so much trouble
> communicating: We are failing to distinguish between the case of text
> *taken* from an RFC (or other IETF contribution) and text *based on*
> an RFC. I think we need to distinguish between those things *every
> single time*.

This terminology isn't clear to me.

I'm guessing by "taken" you mean copied verbatim together with a
reference, and by "based on" you mean copied verbatim, with or without
reference, but (eventually) later modified.  Right?

> doesn't claim to be a direct quote", is an OK usage, no matter how it
> is modified. (Others have different opinions.)

If that were the encoded IETF license, I think it would solve all of
my concerns.  The devil is in the detail though.  At least we seem to
agree on this principle.

> But I'd be very unhappy with a regime where someone can claim that I
> have given permission to people to claim that I wrote words that I
> did not write.

Of course.  That would be fraud.

I find it amazing that you even imply that I may be suggesting
something like that.  We are definitely not communicating.

I don't know how to make my position clearer.  Please study the
examples in my draft and decide for yourself whether you believe they
should be permitted or not.  Nowhere is it required to put words in
other peoples mouth.

You could also download some open source products and search for RFC
reference and compare the quotes with the actual RFC text.

Or type "man getaddrinfo" on a Solaris machine and compare the text
with RFC 2133.  I believe such usage should be permitted; it helped
getting getaddrinfo implemented and documented.

Thanks,
Simon

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 10 Jan 2006 14:16:28 +0100

> reference, but (eventually) later modified.  Right?

Yes - with the proviso that the "copied verbatim" should be a small enough 
excerpt that it can't be taken for "the whole thing".

> my concerns.  The devil is in the detail though.  At least we seem to

You and I seem to either agree or be close to agreeing. But we're not the 
only people here...

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Jan 2006 08:56:49 -0500

As far as I can tell, this path is the earlier proposal that folks can take 
and modify RFC text as much as they like, as long as they don't mislead 
folks about what the RFC itself is.

While that is better than allowing folks to create misleading text, I am 
not convinced it is either necessary or useful.
I have concluded that there is a need to permit the inclusion and 
modification of code extracts from the RFCs.
I do not see a strong reason for permitting the inclusion of text extracts 
that can be modified.  Such things are not, by definition, the actual 
operational code.  As another participant in this thread put it, we are not 
in the business of writing documentation for folks.

Yours,
Joel M. Halpern

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 10 Jan 2006 09:48:22 -0500

Hi,

I struggle with this.
> that can be modified. 

While I feel very uncomfortable saying that anybody can copy the text
and change it as they wish for purposes other than translation and
formatting, I do see a strong reason for permitting the modification
of text.

Remember when the IETF was about running code? Well the running code
we need to encourage now will frequently be enhancements to existing
standards. But our standards are often spelled out in text, not code,
and a description of the enhancement will frequently be described in a
modified version of the original text. 

I think part of the issue is the purpose of the modified text. Maybe
we need to permit modifications to text (beyond translation and
formatting) only if the modifications are brought back into the IETF
as part of the standards process. That strikes me as similar to the
GPL intention that you are permitted to  access and modify
GPL-licensed code if you permit others to acess and modify your
modifications. (disclaimer: I don't claim to understand the GPL
details, but I think I understand the intention).

>From a vendor viewpoint, I might give rights to a valuable patented
invention to the IETF standards process, for the purpose of developing
an industry standard, and allow a royalty-free license to use my
invention for the purpose of publishing and implementing and deploying
the industry standard, but I would want to reserve my rights that
would prevent my competitiors from copying my invention from the RFC,
modifying it slightly, and then using it to compete against me.  

So I think my conclusion is that
> that can be modified
(beyond translation and formatting) outside the standards process
without getting permission to make such modifications from the authors
or assignees of the IPR.

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Tuesday, January 10, 2006 8:57 AM
> To: [email-masked]
> Subject: Re: One copyright issue or Two?
> 
it

---

From: Don Armstrong <[email-masked]>
Date: Tue, 10 Jan 2006 09:15:41 -0800

On Tue, 10 Jan 2006, David B Harrington wrote:
> Maybe we need to permit modifications to text (beyond translation
> and formatting) only if the modifications are brought back into the
> IETF as part of the standards process.

It would be reasonable if the license required modifications that were
distributed to be capable of being incorporated in further IETF
specifications, so long as there wasn't a requirement to inform the
IETF of modifications that are kept in private.

> invention to the IETF standards process, for the purpose of
> developing an industry standard, and allow a royalty-free license to
> use my invention for the purpose of publishing and implementing and
> deploying the industry standard, but I would want to reserve my
> rights that would prevent my competitiors from copying my invention
> from the RFC, modifying it slightly, and then using it to compete
> against me.

You'd have to use a software patent or similar[1] to do the above, not
a copyright license; no copyright license can keep a competitor from
developing an implementation of your standard which doesn't include
your copyrighted material, and then using it to embrace and extend
you.

Don Armstrong
 
1: I'm not particularly happy about having that happen either, but
that's a separate issue which isn't particularly on topic here. ;-)
-- 
I never until now realized that the primary job of any emoticon is to
say "excuse me, that didn't make any sense." ;-P
 -- Cory Doctorow

---

From: "Lawrence Rosen" <[email-masked]>
Date: Tue, 10 Jan 2006 09:25:26 -0800

Joel Halpern wrote:
> I do not see a strong reason for permitting the inclusion of 
> text extracts that can be modified.  

What is the strong reason for prohibiting it?

> As another 
> participant in this thread put it, we are not in the business 
> of writing documentation for folks.

Several here have suggested that RFC text can sometimes make great
documentation. I appreciate that it is not your business to write
documentation for others, but I don't understand why you would actively seek
to prevent others from improving their business by using what already exists
in IETF RFCs as a basis for their documentation.

/Larry

Lawrence Rosen
Rosenlaw & Einschlag, technology law offices (www.rosenlaw.com)
Stanford University School of Law, Lecturer in Law
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242  *  fax: 707-485-1243
Author of "Open Source Licensing: Software Freedom and 
   Intellectual Property Law" (Prentice Hall 2004) 
   [Available also at www.rosenlaw.com/oslbook.htm]

> Sent: Tuesday, January 10, 2006 5:57 AM
> To: [email-masked]
> As far as I can tell, this path is the earlier proposal that 
> folks can take and modify RFC text as much as they like, as 
> long as they don't mislead folks about what the RFC itself is.
> 
> While that is better than allowing folks to create misleading 
> text, I am not convinced it is either necessary or useful.
> I have concluded that there is a need to permit the inclusion 
> and modification of code extracts from the RFCs.
> I do not see a strong reason for permitting the inclusion of 
> text extracts that can be modified.  Such things are not, by 
> definition, the actual operational code.  As another 
> participant in this thread put it, we are not in the business 
> of writing documentation for folks.
> 
> Yours,
> Joel M. Halpern
> 
> >If that were the encoded IETF license, I think it would 
> solve all of my 
> >concerns.  The devil is in the detail though.  At least we seem to 
> >agree on this principle.
> >
> >You and I seem to either agree or be close to agreeing. But 
> we're not 
> >the only people here...
> 
>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 11 Jan 2006 00:45:44 +0100

> What is the strong reason for prohibiting it?

one note about "prohibition":

I haven't seen any scenario (except John Klensin's "least-preferred" one of 
defining all standards work as work-for-hire, and perhaps not even there) 
where the author(s) would actually lose the right he has today to permit 
reproduction, excerpting or derived works.

We're talking about *increasing* the rights available; I don't think it's a 
goal of the WG (or a goal of the IETF) to decrease currently available 
rights.

                  Harald

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Jan 2006 18:58:56 -0500

While we can not currently (and should not try to) restrict the authors 
ability to reuse the text, that is very different from the question of the 
IETF giving the world the right to take and change the text of the standard.

the point of the RFC is that it represents the rough consensus.  We often 
go to a lot of trouble to find the words and meaning that everyone can live 
with.
Letting folks incorporate those words verbatim into other things is 
acceptable, and in some cases desirable.
Letting folks incorporate the code fragments (MIB definitions, XML schemas, 
sometimes XML documents, ASN.1, ABNF, ...) unmodified is clearly necessary 
to promote interoperability.
Having folks modify those code fragments is unfortunate.  I have however 
been convinced that we need to permit that in order to permit the necessary 
incorporation of the code in products.

Incorporating text into those products is not necessary for 
interoperability.  Changes to that text tends to harm interoperability.  It 
is not, as I see it, in the IETFs interest to permit such changes.  If it 
were necessary for some external reason (as appears to apply to the code 
components) then we would do what we usually do when presented with 
conflicting goals.  We would look for a suitable balance.

Yours,
Joel M. halpern

At 06:45 PM 1/10/2006, Harald Tveit Alvestrand wrote:

>I haven't seen any scenario (except John Klensin's "least-preferred" one 
>of defining all standards work as work-for-hire, and perhaps not even 
>there) where the author(s) would actually lose the right he has today to 
>permit reproduction, excerpting or derived works.
>
>We're talking about *increasing* the rights available; I don't think it's 
>a goal of the WG (or a goal of the IETF) to decrease currently available 
>rights.
>
>                  Harald
>
>
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 10 Jan 2006 16:59:09 -0800

At 6:58 PM -0500 1/10/06, Joel M. Halpern wrote:
>While we can not currently (and should not try to) restrict the authors ability to reuse the text, that is very different from the question of the IETF giving the world the right to take and change the text of the standard.
>
>the point of the RFC is that it represents the rough consensus.  We often go to a lot of trouble to find the words and meaning that everyone can live with.
>Letting folks incorporate those words verbatim into other things is acceptable, and in some cases desirable.
>Letting folks incorporate the code fragments (MIB definitions, XML schemas, sometimes XML documents, ASN.1, ABNF, ...) unmodified is clearly necessary to promote interoperability.
>Having folks modify those code fragments is unfortunate.  I have however been convinced that we need to permit that in order to permit the necessary incorporation of the code in products.
>
>Incorporating text into those products is not necessary for interoperability.  Changes to that text tends to harm interoperability.  It is not, as I see it, in the IETFs interest to permit such changes.  If it were necessary for some external reason (as appears to apply to the code components) then we would do what we usually do when presented with conflicting goals.  We would look for a suitable balance.
>
>Yours,
>Joel M. halpern
>

I agree with almost everything Joel has said, and I think it's a good summary of
the concerns.  The only caveat I would add is that I don't think having folks
modify code fragments is always unfortunate; there are cases where it is necessary
for interoperability with specific code bases or adaptions to specific environments.
There are other cases where it represents a fork away from the standard
and interoperability.  Those are unfortunate when the main goal is interoperability.

>From a practical perspective, I don't know of a way to set up a license that captures
the subtle aspects of that--something that allowed code re-use or adaption only when
the result was better interoperability. I know we could create a limit that said
only when full interoperability was achieved, but that would limit reuse in
ways that leave out adaptation to specific environments.  Perhaps the field
of use mechanism has something here that will work.  But fundamentally,
I agree that we are looking for a suitable balance.  From my perspective,
I think interoperability has to weigh very heavily in our considerations,
and that we have to think carefully about what else belongs on the scales.
			regards,
				Ted Hardie

---

From: "Lawrence Rosen" <[email-masked]>
Date: Tue, 10 Jan 2006 17:01:11 -0800

Harald wrote:
> I haven't seen any scenario (except John Klensin's 
> "least-preferred" one of defining all standards work as 
> work-for-hire, and perhaps not even there) where the 
> author(s) would actually lose the right he has today to 

There is nothing that anyone has ever suggested here that would deprive an
author of an IETF RFC of any of his prior rights to license his works under
any terms--except exclusive terms. Giving away non-exclusive licenses to
copyrights or patents is like allowing others to drink from a cup that never
empties. 

Some worry that giving away broad non-exclusive licenses through IETF will
potentially reduce the value of the copyrights or patent rights that remain.
It's possibly true, but I personally consider that one of the necessary
costs of doing business through IETF. 

We're not talking about TAKING any rights away from anyone. We're talking
about GIVING rights to readers of IETF RFCs, which requires that authors of
those RFCs GIVE licenses to IETF. 

> We're talking about *increasing* the rights available; I 
> don't think it's a goal of the WG (or a goal of the IETF) to 
> decrease currently available rights.

I appreciate that. But under copyright law, nobody can copy, modify,
distribute, etc., WITHOUT a license. If IETF doesn't EXPRESSLY ALLOW
licensees of the RFCs to do those things, that is the same as a PROHIBITION.

In practice, of course, hardly anybody draws these legal distinctions, and
so I expect that most people copy what they need from RFCs without thinking
about it or worrying about copyright lawsuits. When some folks suggest that
IETF policies be revised to grant certain broad, express and non-exclusive
licenses to the public, we're mostly hoping to legitimize and authorize what
has inevitably become common practice. 

Which is why people here should tell us what they think they'd lose,
compared to the current system, if IETF adopted a comprehensive new IPR
policy along the lines of what's being discussed here. So far all I've heard
is "I don't wanna and I don't hafta!"

/Larry

Lawrence Rosen

> From: Harald Tveit Alvestrand [mailto:[email-masked]] 
> Sent: Tuesday, January 10, 2006 3:46 PM
> To: [email-masked]; 'Joel M. Halpern'; [email-masked]
> Subject: RE: One copyright issue or Two?
> 
> 
> 
> >> I do not see a strong reason for permitting the inclusion of text 
> >> extracts that can be modified.
> >
> I haven't seen any scenario (except John Klensin's 
> "least-preferred" one of defining all standards work as 
> work-for-hire, and perhaps not even there) where the 
> author(s) would actually lose the right he has today to 
> We're talking about *increasing* the rights available; I 
> don't think it's a goal of the WG (or a goal of the IETF) to 
> decrease currently available rights.
> 
>                   Harald
>

---

From: "todd glassey" <[email-masked]>
Date: Tue, 10 Jan 2006 17:24:01 -0800

----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
To: "Harald Tveit Alvestrand" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, January 10, 2006 3:58 PM
Subject: RE: One copyright issue or Two?

> the point of the RFC is that it represents the rough consensus.

No, the RFC represents the IESG's approved document as the next stage from
the I-D. The matured RFC, one that is beyond the first pass may represent a
concensus of the people involved in the project, but also does not represent
the concensus of the IETF. The IETF Standard represents that it is a
document that has passed through vetting and has made the number of
obligatory milestones in that it has proper vetting, and at least 2
interoperable ports, and the vote of the IESG as the Industry Luminaries
that agreed it should be elevated into an Approved Standards Process.

> We often

You mean that the various use models sometimes conflict with eachother? and
that the language specific to any one particular IP use license may not work
for another? ... "In my best Fargo Accent" Yah sure, no kidding.

> acceptable, and in some cases desirable.

Not necessarily to everyone. Some people here still want to just submit
their protocol initiative for vetting per the model that was setup and ran
so long as RFC2026. That is to say, they want to publish their materials
without giving it away to the world. They want to participate like thousands
of others have before them, and to vet and develop their protocols in an
IETF Working Group Environment. What they dont want to have to do is to give
the world away when they do it, at least not all of the participants.

I guess the question is how you could withhold that from someone? Anyway -
probably not worth answering.

> to promote interoperability.

for what uses? republishing as a part of some other document? or in
implementing the design itself as code? They are not the same, and
publishing this for someone to aid them in implementing the same protocol
when they dont have derivative rights either, is a legal morass and that's
where we are basically now. The republishing-alone rights are simply not
enough to create a Global Standard IMHO. What the license needs are specific
rights to develop and talk about derivative products from the IETF's
protocol and bcp drafts.

In fact I think its key that they be granted for any RFC effort on the
Standards Track, since the second port will require those rights. That said,
it might make sense to allow that for anyone implementing 'the second' or 'a
second' port of the protocol.

> incorporation of the code in products.

Why? as long as the IETF's TM's are not there, including the term "IETF" -
It seems more to the issue that what you want to prevent is someone
modifying a document and then representing that as the "IETF's official
publication" but the cure there is to prevent anyone from republiishing
anything with the IETF's name or copyright or trademark upon it.

> interoperability.  Changes to that text tends to harm interoperability.

That's because most IETF documents do not include formal test and operaitons
plans or use statement's - the addition of these are the missing pieces that
solidify the design and allow for it's clean implementation.

I think the issue is that most developers here want to work on the frosting,
and the core underlying structure docs are not so much fun... They are
cricitical in real-world development environments as we all know, and if the
IETF wants to increase the value of the IP portfolio that the Trust is
supposed to manage, it should consider encouraging all to complete their
technology contributions and include these missing pieces (sorry about the
soapbox - but this is common sense I think).

>  It

let me here play the devil's advocate and ask - What about how control is
maintained on documents??? What if the IETF has to find a way to retract a
published document? - how would it do that? - What if say some small company
had a protocol they showed to someone who just submitted it to the IETF for
publication... figure this individual was exposed to this new protocol
inside a corporate enviroment under NDA, and is now talking about it
publiclly for what ever reason. The miscreant then submits the draft for
publication and its eagerly accepted and published...

Now the IETF is formally placed on notice by the real IP Owners that their
actions and the continued actions are causing grave harm to the Owning
Entity... So what then would the IETF do? stand there and say "Uh gee we are
sorry about this, but your IP rights are toast and there is nothing you can
do about it, but you might take it up with ISOC or CNRI if you think you can
afford the pain."?

No seriously - this is a totally legimate question as to how is the IETF
ever going to be able to pull a document if it gives permanent rights to it
away.? And as long as we are talking about pulling documents, just changing
whether you have a document on your website does not expire it. I.e pulling
six month old I-D's off the site isnt what expires them, its the policy that
they expire in six months that expires them... That's a key concept that
needs to be worked in here too, that documents should only be referrable
within their lifetime UNLESS they are taken all the way to IETF STANDARDS...

Just my two cents.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 11 Jan 2006 17:05:43 +0100

Harald Tveit Alvestrand <[email-masked]> writes:

> I haven't seen any scenario (except John Klensin's "least-preferred"
> one of defining all standards work as work-for-hire, and perhaps not
> even there) where the author(s) would actually lose the right he has
> today to permit reproduction, excerpting or derived works.
>
> We're talking about *increasing* the rights available; I don't think
> it's a goal of the WG (or a goal of the IETF) to decrease currently
> available rights.

I believe some have interpreted RFC 2026 as giving third parties a
"field of use" right, and consequently believed they could legally
incorporate RFC material in their products.  The use of RFC text in
existing commercial and open source products suggest this.  I'm not
sure it is fair to claim that their interpretation is wrong, I don't
see this WG today agreeing on what RFC 2026 says on this.  The only
thing this WG appear (to me) to agree on is that RFC 2026 is unclear.

If we can't agree on what RFC 2026 means, perhaps we should agree that
RFC 2026 is unclear and we need to develop consensus around what we
really intend from scratch.  If we do that, you can't argue that it is
a problem if one of the proposals increase existing rights, as you
perceive the existing rules.  It is better to argue for/against, a
certain proposal based on what the consequences will be in practice,
and which of those consequences you believe are beneficiary/harmful.

Prohibiting modifiable text extracts would decrease the currently
available rights for those who read RFC 2026 the same way I do.

I suggest that we focus on what people agree on today rather than
comparing proposals with RFC 2026 or RFC 3978.  I agree that we'll end
up in the infamous rat hole if all proposals are weighted against
2026/3978.  Let them be evaluated based on what people can agree on
now.

Thanks,
Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Jan 2006 10:53:24 +0100

Lawrence Rosen wrote:
...
> licensees of the RFCs to do those things, that is the same as a PROHIBITION.

Sorry to come back to an old thread, but I'm just catching up...

Let's be very specific. If an IETF standard says, for example,
"The foobar hash MUST be implemented; all other hash algorithms are OPTIONAL."
and an extract from the RFC is modified to read
"All hash algorithms are OPTIONAL; the foobar hash SHOULD NOT be supported."
then interoperability is directly threatened by the publication of
that distorted extract. Our goal is to prevent that happening, I think.

> has inevitably become common practice. 

Correct. It's not the copying that bothers us. It's the specific interaction
with open source licenses that would break the use of copyright to prohibit
distortions such as the above.

     Brian

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 26 Jan 2006 12:28:19 +0100

> that distorted extract. Our goal is to prevent that happening, I think.

That sounds compelling, but I don't buy it.

What _would_ threaten interoperability would be if anybody used the
modified text thinking it was the original.  It is not the publication
by itself that threaten interoperability.

However, I believe nobody that is going to implement Internet
standards will download a document from Foo Inc's homepage and believe
the document describe anything useful that they need to follow.

Remember that everyone appear to agree that IF we use a permissive
license on IETF documents, it WILL contain restrictions that make sure
nobody claim the IETF, IESG etc authored a modified version.  Such
restrictions, even quite elaborate schemes, is acceptable to the free
software community and compatible with free software licenses, as far
as I know.

The power that IETF has is not in publishing documents, it is the
process behind those documents, and the IETF standing up behind those
documents, that is important to people.  The process is supposed to
make sure that the end product is good, and that it is intended to be
implemented by everyone.  If there are flaws, there is a process to
correct them.  A document downloaded from Foo Inc's homepage doesn't
have the same weight, and will not be implemented by organizations all
over the world.

Further, the IETF cannot enforce interoperability.  The IETF can only
encourage interoperability, by providing good standards and expertise
who answer questions about the standard.  That is how I believe the
IETF should work to "enforce" its standard.  If the IETF enters the
game of trademarking and product certification, corporate tactics and
politics will be more influential than technical correctness, and the
technical expertise will quickly flee elsewhere.

I also claim that _IF_ a modified protocol description starts to gain
popularity, it will be because that it describe a technical
improvement.  This is how IETF protocols have evolved over the years,
but the IETF rules have not permitted circulation of the modified
protocol description.  This slows down standardization of the improved
protocol, and ultimately decreases the quality of the Internet.  When
that happens, people will realize it makes sense to bring back the
work to the IETF, to standardize it, and will do so.  (It has been
suggested that the IETF will not be able to use the derived work in
this situation.  I believe that is irrelevant, if authors are
unwilling to co-operate, it is easy to re-write the protocol
description to avoid the legal problem.)

Thanks,
Simon

---

From: "todd glassey" <[email-masked]>
Date: Thu, 26 Jan 2006 05:15:54 -0800

The problem Larry you have illuminated is the sheer number of uncontrolled
IETF mirrors - which ones are real - which ones are not? - and how would you
know??? - the point is that with the current process where ANYONE can
reproduce an IETF draft or rfc on their website, how would you know whether
its good or not? - the answer is you wouldn't without verifying it with some
official mirror or release point and that makes the value of the mirrors and
those republication rights somewhat closer to nil than this WG would like I
bet..

The problem is that the IETF wants all of the power and none of the process
overhead to managing that IP power... and this is what isnt going to fly. If
the IETF wants to really control and protect those that use its IP's then it
must in all good legal practice adopt what are considered BCP's for the
transfer and maintenance of IP and it aint cheap... I am about to sue
someone in Federal Court (yes we are filing tomorrow) for Patent
Infringement and Frauds, so I can attest to exactly what the level of pain
is.

Just my two cents.

Todd Glassey

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 26 Jan 2006 15:59:46 +0100

"todd glassey" <[email-masked]> writes:

> know???

If you don't trust a mirror or library to provide you with the correct
document, you can get it from www.ietf.org.

If someone starts to distribute modified RFCs claiming to be authored
or sponsored by the IETF, that is fraud and if you are inconvenienced
by it enough I suppose you could sue that someone.  It may not be
worth your time, it is likely easier to download the real document
from www.ietf.org and ignore the modified copy.

This is pretty basic and general matters, and seem little to do with
the IETF copying conditions.  All free software downloaded from the
Internet have similar issues.

> the point is that with the current process where ANYONE can
> reproduce an IETF draft or rfc on their website

Note that the current IETF legal text doesn't give ANYONE the right to
reproduce RFCs.

> how would you know whether its good or not? - the answer is you
> wouldn't without verifying it with some official mirror or release
> point

Exactly.

In theory, RFCs could be PGP signed by the RFC editor, to further
guarantee that it is not modified, although I don't see a major point
in doing that.

> and that makes the value of the mirrors and those republication
> rights somewhat closer to nil than this WG would like I bet..

I disagree.  I use a mirror for RFCs practically every week.  I
understand that they have no obligation to give me the unmodified
document.  However, the risk is small, since there is little incentive
for anyone to modify the document and redistribute it.  And if they
do, I'll find out sooner or later anyway.

Regards,
Simon

---

From: "todd glassey" <[email-masked]>
Date: Thu, 26 Jan 2006 21:07:40 -0800

Simon
----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>; "Brian E Carpenter" <[email-masked]>; >
Sent: Thursday, January 26, 2006 6:59 AM
Subject: Re: One copyright issue or Two?

> document, you can get it from www.ietf.org.

That's the point - if I can get the correct one from the source, why do I
need the local or other library copies? But why do I need a copy... to work
on advancing the standard withint the IETF process. Cool - OK.

> by it enough I suppose you could sue that someone.

Why bother though - isnt the purpose to create a set of vetted IP's and
physical implimentations to meet the criteria for advancement to standards
status?

> It may not be

But the IETF's IP's are not free, and the belong to people - likewise, they
may have all kinds of proprietary inclusions or inclusions that require
special licensing for, and this is up to the IESG and WG Chairs in whether
they agree to take on the Standards Project and absorb the vetting and
process overhead into their pool of initiatives.

> guarantee that it is not modified, although I don't see a major point

Localized authentication is simple, but again the question is why and is
this for use inside or outside of the standards process?

> do, I'll find out sooner or later anyway.

But that is an agreement between you and the mirror and has little to do
with the deal between the mirror and the IETF. Again Simon this comes back
to why people need to reprint IETF documents. If they are reprinting a copy
to study or for use in compiling a response to the original work in whole or
in part, then that loosely constitutes participating in the Standards
Process, as long as the IETF has some formal process through the WG or the
Editors for receiving those comments/republished excerpts and inducting them
into the IETF.

By the way - I hadn't noticed any guidance anywhere in any IETF documents
about the incorporation of commentary in the standards process inside the
IETF's framework, can you point it out to me?

Otherwise, the republication has nothing to do with the IETF's Standards
Advancement Process and is more likely for someone else's purposes...

As I have mentioned several times, it seems to me that issues we are running
into are that this group seems to want to give the publication rights away
for one and all, and outside of the standards process, there is for many
little reason to do that.

T./