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

From: Simon Josefsson <[email-masked]>
Date: Fri, 14 Oct 2005 01:29:47 +0200

Hi all.  The draft below document my proposal to fix two of the
problems in BCP78.

After I submitted that document, Branden Robinson of the Debian
project (which are supporters of my effort) proposed to change the
license text slightly, into:

   The Contributor grants third parties the right to copy and
   distribute the Contribution, with or without modification, in any
   medium, without royalty, provided that the copyright notice and
   this notice are preserved, and that any claims of endorsement or
   official status by the IETF or ISOC are removed.

The final reservation make it even more clear that my goal is not to
take existing RFCs and make small modifications and publish them to
create confusion in the market.  I believe preventing that problem is
best done by standard trademark laws, as others have already explained
here.  However, adding that text does not present a problem for me.

That change, perhaps together with some of this WG's suggestions, will
be incorporated into -01.

Thanks,
Simon

[email-masked] writes:

> 	Title		: RFC 3978 Update
> 	Author(s)	: S. Josefsson
> 	Filename	: draft-josefsson-ipr-rules-update-00.txt
> 	Pages		: 7
> 	Date		: 2005-10-13
> 	
>    Two problems with BCP78 are identified, and a proposal to solve them
>    is proposed.  The first problem is that rights to Contributions (to
>    copy, distribute, etc) are not granted to third parties.  The second
>    problem is that the rights that were supposedly intended to be
>    granted to third parties are too limited for some uses of
>    Contributions.  The uses include incorporating portions of
>    Contributions into online help, reference manuals, source code
>    comments or even into source code itself.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-josefsson-ipr-rules-update-00.txt

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

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 13 Oct 2005 19:56:48 -0400

>    official status by the IETF or ISOC are removed.

that text effectively removes the right to distribute unmodified copies.

we definitely don't want that.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 14 Oct 2005 10:13:57 +0200

> we definitely don't want that.

Thanks for catching that, it was unintentional.

Florian Weimer pointed out that the above license is a copyleft
license, e.g., that modified version must retain the same copying
conditions.  I don't believe we want that either, because
incorporating parts of RFCs into closed source should be permitted
too.

I have updated the license to address those two concerns, the new
license reads:

        The Contributor grants third parties the right to
	copy and distribute the Contribution, with or without
	modification, in any medium, without royalty.  If the
	Contribution is modified, any claims of endorsement or
	official status by the IETF or ISOC must be removed.

I'm interested in hearing more feedback from this WG.

Thanks,
Simon

---

From: Ted Hardie <[email-masked]>
Date: Fri, 14 Oct 2005 07:46:49 -0700

>I'm interested in hearing more feedback from this WG.

I don't think the IETF normally uses the term "Contribution"
(though it is common in other SDOs), and I wonder if there
is any reason not to say "The author of this text grants third
parties the right to copy and distribute this text, with or without
modification, in any medium, without royalty."  That makes
crystal clear that we're talking about the text and not the
underlying algorithms or processes (for which other IPR
declarations may have been made).  If "text" as a term of
art in law does not include figures, then we'd have to say
"text and figures", which makes it a bit clunkier, but still
clearer to me than "Contribution".

I also note that the Contributor has no rights to say anything
about claims of endorsement by the IETF or ISOC.   So
you may need to start your second sentence in a way that
notes that we're now talking about someone else's rights.
How about "The IETF requests that any citation or excerpt of
unmodified text reference the RFC or other document 
from which the text is derived. If the text is modified in any
way other than translation, any claim of endorsement by the
IETF or status within its document series must be removed."

That would make the full license:

The author of this text grants third parties the right to copy and
distribute this text, with or without modification, in any medium,
without royalty.  The IETF requests that any citation or excerpt of
unmodified text reference the RFC or other document from
which the text is derived. If the text is modified in any way other
than translation, any claim of endorsement by the IETF or status
within its document series must be removed.

				regards,
					Ted Hardie

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 14 Oct 2005 18:23:05 +0200

> I don't think the IETF normally uses the term "Contribution"

The term Contribution is defined in RFC 3978, and the license text in
section 3.3, apply to Contributions.  Read the first paragraph of
section 3.3 in RFC 3978 to see what I mean.

> clearer to me than "Contribution".

Since "Contribution" is intended to be defined in RFC 3978, I think it
is better to use that word rather than some other term that we would
have to define as well.

> IETF or status within its document series must be removed."

Good point.  I like this.

> within its document series must be removed.

This looks pretty good to me, but I'll have to forward it to others.

Btw, what does "or other document" refer to?  Can't we remove that
part?  I don't see when it would be applicable.

Thanks,
Simon

---

From: Ted Hardie <[email-masked]>
Date: Fri, 14 Oct 2005 09:38:43 -0700

>section 3.3 in RFC 3978 to see what I mean.

I understand it's in  3978, but I don't think most IETFers use
that terminology.  If using the four-letter "text" does the
same job, I would personally prefer it;  it seems more likely to
be generally understood (both inside the IETF and outside it).

>part?  I don't see when it would be applicable.

I think it is useful to leave it in, in case an effort like NEWTRK decides
that the IETF needs some other document type in the future (like
a stable snapshot).  This would clarify that this applies to those as
well, and saves us having to craft yet another update in that case.

			regards,
				Ted

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 17 Oct 2005 13:40:24 +0200

> be generally understood (both inside the IETF and outside it).

I suspect larger modifications of RFC 3978 would be needed to use
"text" instead of "Contributions" in this paragraph.  Using "text"
when strictly defined terms (i.e., "Contributions") are used in the
surrounding sections and paragraphs doesn't give the impression of a
consistent document.

I'm trying to minimize the amount of changes to RFC 3978 that is
required to satisfy my concerns.  That makes it easier to review my
proposal too.  If the WG consensus is to change "Contributions" to
"text" throughout RFC 3978, that would be fine.

> well, and saves us having to craft yet another update in that case.

I understand and agree, thanks for explaining.  Perhaps even replace
"RFC or other document" with "document"?

I have updated the web page and the forth-coming -01 to use the
following legal text:

        The Contributor grants third parties the right to
	copy and distribute the Contribution, with or without
	modification, in any medium, without royalty.  The IETF
	requests that any citation or excerpt of unmodified text
	reference the RFC or other document from which the text is
	derived. If the text is modified in any way other than
	translation, any claim of endorsement by the IETF or status
	within its document series must be removed.

Thanks,
Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Oct 2005 15:09:02 +0200

Ted,

> be generally understood (both inside the IETF and outside it).

I don't think it does the job, legally, and this document would
need to be legally watertight, or it would be useless. The defined
term in 3978 would need to be used, IMHO.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Oct 2005 15:22:34 +0200

My understanding of the intention of the WG while clarifying
the RFC 2026 rules is that we wished to retain the notion that,
as far as possible, we prevent third parties from *changing*
IETF specifications without explicit agreement from the IETF.
That is why the ISOC copyright was adopted in the first place.

My understanding is that this intention means that we cannot
grant blanket permission "to copy and distribute the Contribution,
with or without modification...". It's the "with" that causes
the problem. This permission would allow a third party to
republish an IETF specification with two bytes reversed,
destroying interoperability. Removing "any claims of endorsement
or official status by the IETF or ISOC" does not fix this.

Im my view we can't make this fundamental change without a
very clear IETF consensus.
(It would, formally, require an update to this WG's charter).

    Brian

---

From: Matthew Garrett <[email-masked]>
Date: Mon, 17 Oct 2005 14:40:28 +0100

> or official status by the IETF or ISOC" does not fix this.

It is, of course, already possible for me to produce something that 
looks like RFC 2821, that has "RFC 2821" printed at the top of it and 
which is entirely incompatible with the real RFC 2821. Copyright has 
nothing to do with that.

The only way to protect IETF standards is to ensure that there's some 
sort of "gold mark" that people will recognise. That's the job of 
trademark law, not copyright law.
-- 
Matthew Garrett | [email-masked]

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 17 Oct 2005 16:15:47 +0200

> or official status by the IETF or ISOC" does not fix this.

What would it take to fix that?  Permitting the usage you suggest is
not my goal.  I believe we can find text that would meet my objective
and at the same time take care of your concern here.

It seems as if you are dismissing my proposal by claiming that it does
something harmful, when I have no desire to permit that harmful act.

As others have already pointed out, copyright terms cannot prevent
non-interoperable protocol descriptions.

> (It would, formally, require an update to this WG's charter).

I disagree with that view.  I believe the old license terms, in RFC
2026 section 10.4 (C), gave me the rights to RFC documents that I
need.  The WG charter reads:

  If there consensus of the working group for a different IPR policy
  than the one described in RFC 2026, the working group will seek to
  amend its charter to make it clear that it is changing the status
  quo.

The WG has not been re-chartered to change copying permissions of
RFCs, at least not from what I can tell from the WG charter.

Changing copying permissions of RFCs was done without updating the WG
charter, by publishing RFC 3978.  Presumably that change was done
unintentional.  According to the charter:

  2. Identify issues with current IPR practice that need to be addressed

Thus, the WG is chartered to identify problems with the current IPR
practices and to fix them.

Thanks,
Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Oct 2005 16:42:31 +0200

> and at the same time take care of your concern here.

I'd be really interested to see such text.

> something harmful, when I have no desire to permit that harmful act.

I'm not dismissing it; I chose my words carefully to point out
a difficulty with your words.
> non-interoperable protocol descriptions.

Of course not, but they can make it much harder work to write them.

> need.

          ...this document itself may
          not be modified in any way, such as by removing the copyright
          notice or references to the Internet Society or other Internet
          organizations, except as needed for the  purpose of developing
          Internet standards...

Where does that allow you to "to copy and distribute the Contribution,
with or without modification..."? I just don't see it.

>  The WG charter reads:

Correct.

> unintentional.

As above - I don't believe there is a change due to 3978. I believe
that you are proposing a change.

>  According to the charter:
> 

To identify them, yes. To fix them, no. But that isn't really important.
If we get consensus for a change, we will get consensus to update
the charter. Let's concentrate on whether a change is wanted.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Oct 2005 16:45:53 +0200

Matthew,

> which is entirely incompatible with the real RFC 2821. Copyright has 

If you plagiarize and change the text of 2821 in so doing,
copyright has everything to do with it. If you write a new spec
from scratch, you're correct.

> trademark law, not copyright law.

And it's not today's topic.

    Brian

---

From: Matthew Garrett <[email-masked]>
Date: Mon, 17 Oct 2005 15:53:35 +0100

> And it's not today's topic.

But it's the only way to achieve what you desire. A liberal copyright 
license reduces the energy required to produce incompatible versions of 
standards, but doesn't make it impossible. If you actually want to solve 
that problem properly, you have to invoke trademark law. That's an 
entirely orthogonal concept to how liberal the copyright license is.

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 17 Oct 2005 10:55:40 -0400

> which is entirely incompatible with the real RFC 2821. Copyright has 

It might, or might not.

If the fake RFC includes a substantial chunk of the text of a real RFC,
perhaps with a change of a MUST NOT to a MUST, I'd think that copyright
would also apply..

If we have the opportunity to use defense in depth, we should.

						- Bill

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 17 Oct 2005 10:58:01 -0400

On Mon, 2005-10-17 at 10:53, Matthew Garrett wrote:

> standards, but doesn't make it impossible.

raising the energy required to produce incompatible versions seems like
a worthy goal to me.

						- Bill

---

From: Matthew Garrett <[email-masked]>
Date: Mon, 17 Oct 2005 16:03:24 +0100

> raising the energy required to produce incompatible versions seems like

What are you actually trying to prevent here? If I (as an individual) 
produce an incompatible version, nobody is ever going to use it. If I 
(as a large corporation with a commercial interest in splintering the 
standard) want to produce an incompatible version, they're going to have 
the resources to do it no matter how hard you make it.

Unless you make it impossible, which is what a trademark license would 
do.
-- 
Matthew Garrett | [email-masked]

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 17 Oct 2005 17:10:41 +0200

> with or without modification..."? I just don't see it.

The initial portion of the terms read:

         This document and translations of it may be copied and
         furnished to others, and derivative works that comment on or
                                  ----------------
         otherwise explain it or assist in its implmentation may be
         prepared, copied, published and distributed, in whole or in
         part, without restriction of any kind, provided that the above
               -------------------------------
         copyright notice and this paragraph are included on all such
         copies and derivative works.

My interpretation is that I can create derivative works and freely
modify them.  I believe my derivative works would fall in the category
"comment on".  Further, I cannot see what kind of derivative works
would not fall into that category.

Retaining the copyright notice and the paragraph is not a problem.

> that you are proposing a change.

My goal is to at least get the same rights that I believe were granted
by RFC 2026.  In that process, it may be useful to clarify the
intention, so that there is no confusion over the interpretation.

Thanks,
Simon

---

From: [email-masked] (Scott Bradner)
Date: Mon, 17 Oct 2005 11:20:09 -0400 (EDT)

> intention, so that there is no confusion over the interpretation.

what rights do you think are in RFC 2026 and are not in the combination
of RFC 3978 and the ID I just posted?

to be clear - there has never been any intent to remove any rights that
were in 2026 and the latest version of the ID tries to make sure that
is the case

But if you feel that teh latest ID does not do that please say
specifically what you think is missing. 

Scott

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 17 Oct 2005 17:33:53 +0200

> of RFC 3978 and the ID I just posted?

The right to produce derivative works that may be modified.

> were in 2026 and the latest version of the ID tries to make sure that

Ok.  Knowing the intention helps.

I don't think your latest document give me the same rights as RFC 2026
did: It doesn't grant third parties unrestricted rights to "derivative
works", not even conditioned on that the derivative work "comment on"
the original docment or "assist in its implementation".

Of course, this is just my own interpretation.

Thanks,
Simon

---

From: [email-masked] (Scott Bradner)
Date: Mon, 17 Oct 2005 11:35:15 -0400 (EDT)

> The right to produce derivative works that may be modified.

that right is not in RFC 2026

Scott

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 17 Oct 2005 17:57:16 +0200

> that right is not in RFC 2026

I believe it is.  The RFC 2026 license text says:

The only condition here appear to be that the derivative work must
"comment on or otherwise explain it or assist in its implmentation".

I don't think this discussion of what RFC 2026 says or doesn't say is
particularly relevant to the concerns that I have presented.

Thanks,
Simon

---

From: [email-masked] (Scott Bradner)
Date: Mon, 17 Oct 2005 12:04:35 -0400 (EDT)

> I believe it is.

then we disagree 

as the editor of 2026 I can assure you that it was specifically not 
the intention of RFC 2026 to permit the creation of derivative works (other
than translations) outside of the IETF standards process - nor do I
think that 2026 gives such permisison

see secton 10.3.1 - the right to make derivative works is granted
to the IETF not to third parties

Scott

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 17 Oct 2005 18:16:55 +0200

> to the IETF not to third parties

That section is not part of the license.  Again, it seems to be that
explanatory text is not aligned with what the actual legal license
terms says.

The license text I quoted says that derivative works may be created,
under some conditions that the derivative works "comment on" the
protocol.

Can you explain what you believe the actual license text below refer
to, when it talks about derivative works?  If I understood how you
interpret that clause, perhaps I could understand how we differ in
interpretation.

Thanks,
Simon

---

From: [email-masked] (Scott Bradner)
Date: Mon, 17 Oct 2005 12:51:06 -0400 (EDT)

I've asked Jorge to comment (since he, unlike me, is a real lawyer) 
but I think that "comment on or otherwise explain" means just that - 
it does not mean creating a new document with, using Brian's 
example, two bytes reversed in a data field.

Scott

---

From: Ted Hardie <[email-masked]>
Date: Mon, 17 Oct 2005 10:36:41 -0700

>example, two bytes reversed in a data field.

Part of the point I was trying to make earlier is that you can indicate
where you diverge from an RFC within the existing rights:

"RFC XXXX specifies that this is  value of type FOO; in this implementation,
I have treated it as of type BAR instead, since that allows OS native-calls
and speeds protocol processing.  I believe this introduces no on-the-wire
problems with other implementations".  This is commentary, and it allows
someone reading it know what departures your implementation made from
which  RFC.  Even if you wrote "RFC XXXX has a bug, and treats this value as
of type FOO, which will not work; I have treated it is as type BAR",
there is no question that you are commenting on the RFC, rather than
modifying its specification.

Can you explain why this type of commentary will not serve? 

			regards,
					Ted

---

From: [email-masked] (Scott Bradner)
Date: Mon, 17 Oct 2005 13:42:57 -0400 (EDT)

Ted,
	I did not think the question in the thread was 'what commentary
would serve' - I thought it was 'what rights does 2026 give to 2rd
parties' - at least that was the question I was ansering

Scott

----
>From [email-masked]  Mon Oct 17 13:37:03 2005
Date: Mon, 17 Oct 2005 10:36:41 -0700
To: [email-masked] (Scott Bradner), [email-masked]
From: Ted Hardie <[email-masked]>
Subject: Re: draft-josefsson-ipr-rules-update-00
Cc: [email-masked], [email-masked]

			regards,
					Ted

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 17 Oct 2005 21:51:51 -0400

And indeed, I think that there is an even more basic issue.
When people can modify the text of the RFCs, they are likely to do 
so.  Doing so in apparently innocuous ways can actually produce subtle 
incompatiblities.  (There are reasons we often spend a lot of time on some 
of the descriptions.)
Keeping a prohibition against modification helps prevent accidental 
non-interoperable descriptions.
Which is probably more important than preventing deliberately inconsistent 
versions.

Yours,
Joel

---

From: Branden Robinson <[email-masked]>
Date: Wed, 19 Oct 2005 12:14:08 -0500

> we definitely don't want that.

That's not true.  The wording above is very similiar to the MIT/X11
license[1], and I know of no one in the software community who has ever
interpreted it as you have.

The Contributor grants third parties the right to copy and distribute, with
or without modification.

Therefore the right to distribute copies without modification must be
granted.

Am I misundertanding you?

-- 
G. Branden Robinson            |
Free Software Developer        |           Ab abusu ad usum non valet
[email-masked]          |           consequentia.
http://deadbeast.net/~branden/ |
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Branden Robinson <[email-masked]>
Date: Wed, 19 Oct 2005 12:19:21 -0500

> incorporating parts of RFCs into closed source should be permitted

I don't believe Florian Weimer is correct about your original wording being
a copyleft.

Review the terms of the MIT/X11 license[1] and the BSD license[2], both of
which require preservation of license text.

What makes the GNU GPL[3] a copyleft, by constrast, is its forbiddance of the
additional of further restrictions; see §6.

> 	official status by the IETF or ISOC must be removed.

Your change seems harmless, but I do want to dispel the belief that it was
necessary.  Otherwise I fear confusion about traditional non-copyleft
licenses will spread.

[1] http://www.x.org/Downloads_terms.html
[2] http://www.freebsd.org/copyright/license.html
[3] http://www.gnu.org/copyleft/gpl.html

-- 
G. Branden Robinson            |      Computer security is like an onion:
Free Software Developer        |      the more you dig in, the more you
[email-masked]          |      want to cry.
http://deadbeast.net/~branden/ |      -- Cory Altheide
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg