Subject: Re: Copying conditions

From: Simon Josefsson <[email-masked]>
Date: Tue, 04 Jan 2005 20:09:09 +0100

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

> (dropping the IETF list off this thread - it's an IPR list matter, really)
>
> Simon,
>
> suggestion for concrete action:
>
> - Specify a grant of rights in documentation that satisfies the criteria 
> that you want. Document them as an I-D or by other suitable means.
>
> - Put in the next I-D you write a grant, in addition to those grants 
> required under RFC 3667, referencing the specification above. As I read RFC 
> 3667, it is permitted under the IETF's rules to do so.
>
> - Encourage others to do the same, and see if there is uptake.
>
> Running code...

After contemplating this suggestion for a while, I now believe it
doesn't solve anything, nor for me nor for the IETF.

It won't solve my issues, because I didn't write the IDN, GSS-API,
SASL, Kerberos etc specifications.  If the preliminary message from
the FSF lawyers stand, I don't have permission to use text from the
specifications that I need to reasonably implement those standards.

It won't solve IETF's problem, because the IETF will continue to use
one set of legal text officially (RFC 3667) that may not be acceptable
to the free software community.  Saying that the license doesn't say
what it appears to say when someone asks will create confusion.  Free
software developers might not ask IETF to review their work, because
any contributions received would be under a license they cannot use.

If the IETF recognize and care about this issue, it has to do
something about it.

Telling free software implementors, like me, to write and publish our
own specifications, licensed under a permissive license, is one
solution.  This is akin to saying "go away", in my ears.

I don't think that approach will be an advantage for the IETF in the
long run.  My perception is that the free software community has a
tendency to give back to communities that work with them, and ignore
others.  So, speaking as a free software developer that, for some odd
reason, care about the IETF, I wish that the IETF would consider other
solutions.

Thanks,
Simon

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 06 Jan 2005 15:08:13 +0100

--On 4. januar 2005 20:09 +0100 Simon Josefsson <[email-masked]> wrote:

>> required under RFC 3667, referencing the specification above. As I read
>> RFC  3667, it is permitted under the IETF's rules to do so.
>>

Simon,

you missed my point.

If you, who have a completely specific set of requirements on what IPR you 
want stated in your documents, are unable to express those in a document, 
then there is absolutely no hope of the IETF being able to specify terms 
that will satisfy your requirements.

If you are able to specify text that satisfies your requirements, and put 
that text on a contributed IETF document, the IETF can discuss whether or 
not the text you specified satisfies the requirements of the rest of the 
IETF.

Running code. As a FIRST step. I never thought it would be the LAST step.

                   Harald

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 06 Jan 2005 15:39:29 +0100

> that will satisfy your requirements.

See Appendix B:

http://www.ietf.org/internet-drafts/draft-josefsson-rfc2538bis-01.txt

Thanks,
Simon

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 06 Jan 2005 15:53:40 +0100

Thank you!

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 7 Jan 2005 15:12:41 -0800

>http://www.ietf.org/internet-drafts/draft-josefsson-rfc2538bis-01.txt

<bold>IANAL</bold>, but I doubt that putting two conflicting 
copyright statements in one document makes any sense legally.

Instead, would this be better for your document?

----------

Appendix B.  Copying conditions

At the time of this writing, a document with essentially the same 
text as this document is available from <insert URL here>. The 
copyright for that other document reads:

          Copyright (C) 2004, 2005 Simon Josefsson

          Copying and distribution of the work, with or without
          modification, are permitted in any medium without royalty
          provided the copyright notice and this notice are preserved.

----------

I see no problem with this in an RFC, and I don't see it as 
conflicting with the ISOC copyright statement. Thoughts?

--Paul Hoffman, Director
--VPN Consortium

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 08 Jan 2005 00:54:32 +0100

> copyright statements in one document makes any sense legally.

A work may be owned by more than one person?

Generally, I don't understand how ISOC can claim copyright of my work.
I didn't sign any papers agreeing to transfer the copyright.

Is copyright transfer by anything but real signatures legally binding?

Perhaps it is based on the good will, that authors won't challenge
that ISOC own the copyright.

It appears as if moral rights cannot be negotiated away fully [1],
though, so presumably I could object to ISOC's publication of my work.

> Instead, would this be better for your document?

Perhaps if it was altered to only apply to the part of the document
that I wrote.  It is a -bis document, so I didn't write most of it.

Btw, perhaps the original authors should still be mentioned in the
header, even if they did not participate in the -bis document effort?

There is another document:

http://www.ietf.org/internet-drafts/draft-josefsson-openpgp-mailnews-header-00.txt

The authors wrote the entire document, and agreed to the stated
permissive copying conditions.  I believe these two documents
illustrate two different cases, both relevant.

Harald Alvestrand clarified that putting the copying condition in a
document was not the final solution, so I'm not sure I understand why
we are improving the text.  If I read Harald correct this time,
putting the copying condition in a submitted document was a first
step, that would allow the IETF to discuss this matter.  I didn't
think the discussion would be about what text I use.  Rather, I
thought it would be about how similar rights can be granted for all
IETF documents.  Feel free to correct me again.

Thanks,
Simon

[1] Article 6bis of
http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html#P123_20726

---

From: [email-masked] (Scott Bradner)
Date: Sat, 8 Jan 2005 05:04:30 -0500 (EST)

>           Copyright (C) 2004, 2005 Simon Josefsso
> 

multiple, potentially conflicting, copyright statements are a problem and are
currently not permitted

see RFC 3667 section 5.4

Scott

---

From: [email-masked] (Scott Bradner)
Date: Sat, 8 Jan 2005 05:05:33 -0500 (EST)

> I didn't sign any papers agreeing to transfer the copyright.

you agreed to that by making acontribution to teh IETF - that is
what RFC 3667 is all about

Scott

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 08 Jan 2005 14:44:28 +0100

> what RFC 3667 is all about

Thanks.  Are the rights transferred to the IETF/ISOC exclusively?

If not, wouldn't the authors be able to grant different conditions for
the text, outside of the IETF?

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 08 Jan 2005 14:54:56 +0100

> multiple, potentially conflicting, copyright statements are a problem and are

Ouch.  Good reference.

The following is in RFC 3492, so I assume it was acceptable to the
IETF/ISOC.

   Regarding this entire document or any portion of it (including the
   pseudocode and C code), the author makes no guarantees and is not
   responsible for any damage resulting from its use.  The author grants
   irrevocable permission to anyone to use, modify, and distribute it in
   any way that does not diminish the rights of anyone else to use,
   modify, and distribute it, provided that redistributed derivative
   works do not contain misleading author or version information.
   Derivative works need not be licensed under similar terms.

This text seem to give me, and third parties, the rights we need to
use the document freely.

I asked the FSF licensing committee to review this license in November
(no answer yet).  The copyright clerk's preliminary thoughts were that
it was free and compatible with both the GPL and the GFDL, though.

I think I may be satisfied if the IETF/ISOC granted similar rights to
all RFCs.

Thanks,
Simon

---

From: [email-masked] (Scott Bradner)
Date: Sat, 8 Jan 2005 16:08:38 -0500 (EST)

> Thanks.  Are the rights transferred to the IETF/ISOC exclusively?

please take a look at RFC 3667 - this is fully addressed

the only rights the IETF gets are to publish the doc and to produce
derivative works within the IETF - the author(s) retain all other rights

Scott

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 09 Jan 2005 01:18:32 +0100

> please take a look at RFC 3667 - this is fully addressed

Sorry.

> derivative works within the IETF - the author(s) retain all other rights

Good.  So RFC authors are free to publish the essential part of a RFC
under another license.  My impression was that there were multiple
opinions on that issue; it was useful to have this clarified.

Thanks,
Simon

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 08 Jan 2005 19:36:51 -0500

>opinions on that issue; it was useful to have this clarified.

This issue has come up frequently in the past -- Scott's explanation is 
certainly the intent of the language.

		--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Sam Hartman <[email-masked]>
Date: Sat, 08 Jan 2005 20:22:09 -0500

>>>>> "Paul" == Paul Hoffman / VPNC <[email-masked]> writes:

    >> http://www.ietf.org/internet-drafts/draft-josefsson-rfc2538bis-01.txt

    Paul> <bold>IANAL</bold>, but I doubt that putting two conflicting
    Paul> copyright statements in one document makes any sense
    Paul> legally.

Actually dual-licensed software happens all the time; there are a lot
of things licensed under the QPL and GPL or the NPL, MPL and GPL.

Putting two licenses on the same document and allowing someone to pick
one is fine; of course with all things legal there are corner cases,
conflicts, complexities etc.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Sat, 08 Jan 2005 20:50:06 -0500

>>>>> "Scott" == Scott Bradner <[email-masked]> writes:

    >> Generally, I don't understand how ISOC can claim copyright of
    >> my work.  I didn't sign any papers agreeing to transfer the
    >> copyright.

    Scott> you agreed to that by making acontribution to teh IETF -
    Scott> that is what RFC 3667 is all about

I'd like to draw everyone's attention to US copyright law for a bit.
There's something called a copyright transfer.  I'd like to draw your
attention to
http://www.law.cornell.edu/copyright/copyright.act.chapt2.html, which
I believe to be an accurate textual copy of chapter 2 of 17 USC.

In particular I'd like to draw your attention to 17 USC Sect 204, which reads in part:

    Sect. 204. Execution of transfers of copyright ownership

       (a) A transfer of copyright ownership, other than by operation of
          law, is not valid unless an instrument of conveyance, or a note or
             memorandum of the transfer, is in writing and signed by the owner of
                the rights conveyed or such owner's duly authorized agent.

Rfc 3667 has always confused me.  According to section 3.3, I grant a
license to ISOC granting ISOC and the IETF certain rights.

However each internet-draft contains a copyright statement claiming
that ISOC owns the copyright for the draft with all rights reserved.

As far as I can tell this claim is completely false.  I do not believe
I executed a written transfer under 17 USC Sect 204.  It might well be
that such a transfer could be included in a boiler plate of a draft,
but as far as I can tell the boiler plate says I grant the rights in
RFC 3667, not I transfer my copyright.

I'd like to draw your attention to the following quotation from 17 USC
Sect 201:

     A "transfer of copyright ownership" is an assignment, mortgage,
        exclusive license, or any other conveyance, alienation, or
           hypothecation of a copyright or of any of the exclusive rights
              comprised in a copyright, whether or not it is limited in time or
                 place of effect, but not including a nonexclusive license.

How does the non-exclusive license I grant to ISOC   justify the claim in the internet draft that  ISOC owns the copyright?  IN what sense is this true?

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Sat, 08 Jan 2005 21:06:08 -0500

>> provided the copyright notice and this notice are preserved.

    Scott> multiple, potentially conflicting, copyright statements are
    Scott> a problem and are currently not permitted

section 5.4 seems to prohibit copyright notices.  I see nothing there
that prohibits statements of non-exclusive license grants by the
author in addition to the license granted by RFC 3667.

---

From: [email-masked] (Scott Bradner)
Date: Sat, 8 Jan 2005 21:24:10 -0500 (EST)

> under another license.

yes - the *authors* are (i.e. all teh authors have to agree)

Scott

---

From: [email-masked] (Scott Bradner)
Date: Sat, 8 Jan 2005 21:28:08 -0500 (EST)

> that ISOC owns the copyright for the draft with all rights reserved.

the "all rights reserved" was removed under 3667

RFC 3667 is quite clear - the ISOC (IETF) gets *non exclusive* rights to
publish & make new versions  *within the ietf stds process*

all other rights stay with the authors

the ISOC has a copyright on the specific representation that is the RFC

Scott

---

From: [email-masked] (Scott Bradner)
Date: Sat, 8 Jan 2005 21:29:03 -0500 (EST)

> section 5.4 seems to prohibit copyright notices. 
yes - and I was addressing the 2nd copyright notice

----
>From [email-masked]  Sat Jan  8 21:05:00 2005
To: [email-masked] (Scott Bradner)
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked]
Subject: Re: Copying conditions
From: Sam Hartman <[email-masked]>
Date: Sat, 08 Jan 2005 21:06:08 -0500

---

From: "Lawrence Rosen" <[email-masked]>
Date: Sat, 8 Jan 2005 18:44:07 -0800

> yes - the *authors* are (i.e. all teh authors have to agree)

That isn't necessarily true. For joint works, each author can separately
license without asking the others.

In any event, any RFC should be available for free coping by everyone.
Right? Or do IETF policies not guarantee that freedom?

/Larry

Lawrence Rosen
Rosenlaw & Einschlag, technology law offices (www.rosenlaw.com)
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)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Scott Bradner
> Sent: Saturday, January 08, 2005 6:24 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Sat, 08 Jan 2005 21:50:55 -0500

>>>>> "Scott" == Scott Bradner <[email-masked]> writes:

    Scott> the ISOC has a copyright on the specific representation
    Scott> that is the RFC

OK, but what does the ISOC copyright on an internet-draft mean?  As
far as I can tell that work is entirely prepared by the author.  None
of the exclusive rights in 17 USC Sect 106 are transferred to ISOC.
If we're going to correctly claim that ISOC holds copyright on an
internet draft, then it seems there should be some x for which ISOC
holds an exclusive copyright right y in x.  What's x and y?

--Sam

---

From: [email-masked] (Scott Bradner)
Date: Sat, 8 Jan 2005 22:12:36 -0500 (EST)

> OK, but what does the ISOC copyright on an internet-draft mean? 

The ISOC (IETF) is the publisher of the ID
thus the *non excliusive* copyright is on the specific ID

the ISOC has no exclusive copyrights relating to IDs or RFCs

Scott

-----

>From [email-masked]  Sat Jan  8 21:49:53 2005
To: [email-masked] (Scott Bradner)
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked]
Subject: Re: RFC 3667 and copyright asignment
From: Sam Hartman <[email-masked]>
Date: Sat, 08 Jan 2005 21:50:55 -0500

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Sat, 08 Jan 2005 22:57:59 -0500

>> OK, but what does the ISOC copyright on an internet-draft mean?
    Scott> The ISOC (IETF) is the publisher of the ID thus the *non
    Scott> excliusive* copyright is on the specific ID

Scott, I'd like to draw your attention to the following excerpt from 17 USC Sect 401:

      Sect. 401. Notice of copyright: Visually perceptible copies

     (a) General provisions.

     Whenever a work protected under this title [17 USCS Sects. 101 et
     seq.] is published in the United States or elsewhere by authority of
     the copyright owner, a notice of copyright as provided by this
     section may be placed on publicly distributed copies from which the
     work can be visually perceived, either directly or with the aid of a
     machine or device.

     (b) Form of notice.

     If a notice appears on the copies, it shall consist of the following
     three elements:

     (1) the symbol "C" (the letter C in a circle), or the word
     "Copyright", or the abbreviation "Copr."; and

     (2) the year of first publication of the work; in the case of
     compilations or derivative works incorporating previously published
     material, the year date of first publication of the compilation or
     derivative work is sufficient. The year date may be omitted where a
     pictorial, graphic, or sculptural work, with accompanying text
     matter, if any, is reproduced in or on greeting cards, postcards,
     stationery, jewelry, dolls, toys, or any useful articles; and

     (3) the name of the owner of copyright in the work, or an
     abbreviation by which the name can be recognized, or a generally
     known alternative designation of the owner.

going back to 17 USC Sect 101 we find:

     "Copyright owner", with respect to any one of the exclusive rights
        comprised in a copyright, refers to the owner of that particular
           right.

Chapter 2 of the law also supports the conclusion that a copyright
owner must have some exclusive right in some copyrighted work.  I'm
happy to see a citation to case law or an explanation of why my
understanding is incorrect.

However to the best of my knowledge, a copyright owner needs to have
some exclusive right in some copyrighted work.  Moreover, to the best
of my understanding, a copyright notice implies that the stated
copyright owner has an exclusive right in the work in question.

So again, in all of our internet drafts there is a copyright notice
from ISOC.  Please pick one of these drafts and explain to me what
exclusive right in what work related to that draft ISOC has.

As a side note, I'm actually OK with the conclusion that the ISOC
notice is fictional but we want to keep it for some reason.

So far, as best I can tell, that notice does not represent reality.

--Sam

---

From: "todd glassey" <[email-masked]>
Date: Sat, 8 Jan 2005 20:07:24 -0800

It would likely be easier to convey a right-to-publish release and a
hold-harmless release for submissions rather than a copyright transfer. Look
at how much effort is going into this copyright discussion, relative to what
you are trying to accomplish. That being releasing the IETF to publish the
document.

As to any other transfer of IPR that should and would need to happen
separately from the publishing release I would think.

Todd

---

From: Sam Hartman <[email-masked]>
Date: Sat, 08 Jan 2005 23:11:17 -0500

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

    todd> It would likely be easier to convey a right-to-publish
    todd> release and a hold-harmless release for submissions rather
    todd> than a copyright transfer. Look at how much effort is going
    todd> into this copyright discussion, relative to what you are
    todd> trying to accomplish. That being releasing the IETF to
    todd> publish the document.

All I'm trying to do is to determine what if any meaning a notice
required in every internet draft has.

I completely agree that licenses/limited grant of copyright are how we
should affect our copyright policy.  But I'm not trying to *do*
anything right now; I'm trying to understand what the current text
actually does.  Note that what the text does is distinct from what we
want it to do.

--Sam

---

From: "todd glassey" <[email-masked]>
Date: Sat, 8 Jan 2005 20:33:01 -0800

inline below.

Todd

----- Original Message ----- 
From: "Sam Hartman" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Scott Bradner"
<[email-masked]>; <[email-masked]>
Sent: Saturday, January 08, 2005 8:11 PM
Subject: Re: RFC 3667 and copyright asignment

> required in every internet draft has.

Right now - my take is NOTHING... If you cant prove who actually submitted
the draft to the RFC/ID Editors for publication, then there is no way to
properly release its use. Its pretty simple.

The issue Sam is really fundamantal - the license or copyright transferal is
supposed to give the IETF/IESG/ISOC coverage for publishing the IP contained
in the draft. Also to allow others to republish the materials as well with
the inclusion of the controlling language. The debate is as to whether this
is effective is a reasonable one to have. I and others have pushed for a set
of changes to the IP submission and release process for some time now. Ones
that provide for proper authentication of the submitters identity at least.

---

From: "todd glassey" <[email-masked]>
Date: Sun, 9 Jan 2005 07:51:31 -0800

Scott - isn't there a fundamental flaw in this, based on how much of any
initiative those individuals are claiming ownership of?

Is it the IETF and ISOCs proclamation that all participants in any
initiative share equally in its ownership? - That's clearly a problem as far
as I can see, since the IETF is not writing the checks to pay for those
people's time or efforts.

Todd Glassey

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 10 Jan 2005 17:00:33 +0100

This may be hopelessly amateur-lawyerish, but....

is there a reason why the text says "multiple.... copyright statements", 
and does not say "multiple..... licensing statements"?

I get a headache from the discussion of copyright notices, but the 
IMPORTANT part of the statement that Simon wants to add is his license 
terms, not his copyright statement.

And what the IETF cares about is that the IETF rights should not be 
*restricted*.

So would it be OK for an I-D author to say something like this:

  In addition to the license given to the IETF, the author declares that
  Copying and distribution of the work, with or without
  modification, are permitted in any medium without royalty
  provided the copyright notice and this notice are preserved

Or does that make no sense?
(I see lots of corner cases, like the case where portions of the RFC are 
quotes from another RFC that doesn't have such a clause - the "no 
sublicensing" stuff Jorge mentions applies here. But in theory....)

                  Harald

--On 8. januar 2005 05:04 -0500 Scott Bradner <[email-masked]> wrote:

> multiple, potentially conflicting, copyright statements are a problem and
> are currently not permitted
>
> see RFC 3667 section 5.4
>
> Scott
>
>

---

From: [email-masked] (Scott Bradner)
Date: Mon, 10 Jan 2005 11:07:09 -0500 (EST)

> and does not say "multiple..... licensing statements"?

the reason for the text at all was because Bill Simpson wanted to 
add his own conflicting copyright statement (terms) to documents
and thta was a significant pain

the specific language was just what I came up with at the time
to forestall the problem

I see no problem in throry with someone being able to include
terms in teh RFC that are more open than the IETF ones but 
there might be a problem implementing such a thing because 
someone would have to verify that the terms did not actually
conflict (which more open terms would not)

i.e. teh specific text you use as an example seems fine but many
historic examples would not be

Scott

----
>From [email-masked]  Mon Jan 10 11:00:58 2005
Date: Mon, 10 Jan 2005 17:00:33 +0100
From: Harald Tveit Alvestrand <[email-masked]>
To: Scott Bradner <[email-masked]>
Cc: [email-masked]
Subject: Copying and licensing....Re: Copying conditions

                  Harald

---

From: [email-masked] (Scott Bradner)
Date: Mon, 10 Jan 2005 11:10:43 -0500 (EST)

ps - remmber that one of the aims here is also to not have
multiple documents that "define" a technology (like MPLS) - the desire
of teh open source folk to be able to take RFCs and change them in any way 
to modify the technology and then assert that they have now defined 
teh "right" version of the technology is not good for the IETF or for
implementors since no one knows what is the correct technology 
description

also note that if we were that open the ITU (ETSI, 3GPP etc) could
do the same - create modified RFCs and then claim that their version
was the real standard

not a good thing

Scott

---

From: "Lawrence Rosen" <[email-masked]>
Date: Mon, 10 Jan 2005 09:00:34 -0800

> implementors since no one knows what is the correct technology

This statement reflects an improper understanding of the rules of open
source and an exaggeration of the function of industry standards.

Open source requires the freedom to create derivative works, regardless of
the consensus of an IETF working group to define a standard. Of course, this
does not mean that all resulting derivative works meet that standard or that
IETF will bless any such derivative works. Nor does it necessarily mean that
patent licenses will be available for those "non-standard" derivative works.

If IETF wants to make sure people know what the "right" version of a
technology is [to use Scott Bradner's judgmental term], then IETF should
create certification marks. [An example of this is provided by The Open
Group, which owns a certification mark for UNIX.] But IETF simply cannot
force people to follow a standard, nor even to prevent anyone from taking
the specifications for a standard and "change them in any way to modify the
technology." Restricting that freedom is well beyond the power and function
of IETF or any non-governmental standards organization.

> do the same - create modified RFCs and then claim that their version

And that is immoral because????

/Larry Rosen

Lawrence Rosen

> Sent: Monday, January 10, 2005 8:11 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: Copying and licensing....Re: Copying conditions
>

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Mon, 10 Jan 2005 09:49:05 -0800

>  provided the copyright notice and this notice are preserved

Serious question: if some RFCs say that, and others (like the 
previous 4000 RFCs) do not, what is an implementer to think about 
those that do not?

Such an addition seems to generate more confusion than clarity for 
the overall set of RFCs.

--Paul Hoffman, Director
--VPN Consortium

---

From: Daniel Weitzner <[email-masked]>
Date: Mon, 10 Jan 2005 13:43:04 -0500

I'm surprised to see this thread go in this odd direction.

I don't know why Scott would suggest that the open source community 
wants to make modification of specifications (aka 'derivative works') 
and create confusion about which version is a bona fide IETF document. 
I've never heard anyone in the open source community suggest this 
strategy. I have heard people suggest forking strategies, but that's 
about building a deployed base of technology on a competing 
specification, not confusion in the manner that Scott suggested.

By the same token, I am a bit unclear about what right Larry is seeking 
to defend. Any developer community (open source or otherwise) has the 
right to develop its own technical specifications. But I can't see why 
that requires the right to make derivative works of another 
specification. Competition is specification design is, of course, 
healthy. But I can't think of a situation in which such competition was 
served by enabling proponents of a new design to gain 
implementer/adherents by obscuring the provenance or standardization 
status of a given design.

FWIW, W3C's Document license[1], the license under which we publish all 
of our technical specifications, precludes derivative works without 
written permission. This has worked well for the Web community for 
nearly ten years.

Best,

Danny Weitzner

[1] http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231

--
Daniel J. Weitzner                                          
+1.617.253.8036 (MIT)
World Wide Web Consortium                       +1.202.364.4750 (DC)
Technology & Society Domain Leader      <[email-masked]>
http://www.w3.org/People/Weitzner.html

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 10 Jan 2005 22:45:23 +0100

--On 10. januar 2005 09:49 -0800 "Paul Hoffman / VPNC" 
<[email-masked]> wrote:

> Serious question: if some RFCs say that, and others (like the previous
> 4000 RFCs) do not, what is an implementer to think about those that do
> not?

According to what I think Jorge and Scott have said, the implementor is to 
think that he has to ask the author in order to make use of the material.

Changing that assumption for the 4000 other RFCs *is* tricky.

           Harald

---

From: "Lawrence Rosen" <[email-masked]>
Date: Mon, 10 Jan 2005 14:19:04 -0800

> I'm surprised to see this thread go in this odd direction.

This thread has gone off on numerous odd tangents in recent days. I'm not
surprised some would find my email also odd. Sorry, Danny, I'll try to be
clearer why this is so important to me.

I understand that a standards body (or its contributors) can prevent me,
through licensing, from "copying" its published specifications or creating
"derivative works" for unauthorized purposes. [I won't go off on a tangent
to describe how Sun purports to license its Java standards in that way,
except to say that I'm grateful that IETF and W3C are much better!] But a
mere claim of copyright cannot prevent my practice of the ideas contained in
a publicly-disclosed writing. Scott's email seemed to suggest that IETF
could (or should) do precisely that. Now it also seems that W3C may be
implying a similarly overbroad claim of rights in its specifications
license.

Despite my great respect for the cooperative engineering that both
organizations do and my hearty encouragement of commonly-accepted standards,
I cannot sit by while standards organizations imply any restrictions
whatsoever for the open source community -- or anyone, for that matter -- to
implement any published industry standard or a fork of that standard. The
only practical restrictions to that freedom may come from patent licenses,
not copyright licenses -- and this thread is about "copying conditions" not
patents. 

It is wrong for anyone, even standards organizations I admire, to claim
greater ownership rights to the public's intellectual commons than they are
otherwise entitled to.

If you want to, use trademark law and certification marks to denote the
source or origin of your important standards. But don't imply I can't modify
your published ideas just because you put your copyright notice on them.

Sometimes the discussion on this IPR-WG list confuses the three very
different property rights associated with copyright, patent and trademark
law. I didn't want to let Scott's email confuse anyone into believing that
IETF (or W3C, or their contributors and members) can effectively restrict
the adoption or derivation of industry standard technology through copyright
notices.

/Larry

Lawrence Rosen

> From: Daniel Weitzner [mailto:[email-masked]]
> Sent: Monday, January 10, 2005 10:43 AM
> To: [email-masked]
> Cc: Harald Alvestrand; [email-masked]; 'Scott Bradner'

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 15 Jan 2005 19:58:51 +0100

> terms, not his copyright statement.

Right.  I don't care strongly about who owns the copyright.  However,
I, and my customers, do require the right to copy and modify my
software.  And RFCs are frequently part of my software.

It has been suggested that some aspects of what I copy from RFCs are
not copyrightable.  Examples include the data tables from RFC 3454 and
the ASN.1 schema derived from RFC 1510.  But people who claim that
also mention "sweat of the brow", and from what I understand, that is
an US copyright verdict that doesn't hold in several other countries.

When I copy introductory or terminology sections from RFCs, sometimes
quite lengthy, I suspect that would be a clear copyright violation,
and a "sweat of the brow" argument would never hold.

However, regardless of what the law might allow me to do in the latter
situation, or what lawyers may try to convince me that I can do, the
size of the material I borrow has grown to such a length that I feel
that I cannot morally use the content without the authors permission.
This is a moral matter, more than a legal one, though.  The IETF may
want to restrict itself from dealing with moral matters, and only
tackle the legal matters, though.

>  provided the copyright notice and this notice are preserved

It would be OK by me.

Remember that RFC 3492 include:

That would also be sufficient for me.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 15 Jan 2005 20:23:16 +0100

> think that he has to ask the author in order to make use of the material.

A question that can be answered with a negative, alas...

> Changing that assumption for the 4000 other RFCs *is* tricky.

Supposedly there is some history to lean on here: the IETF/ISOC
adopted the copyright on earlier RFCs.  I asked for the copying
conditions for RFC 1510, and received the reply below, which say that
the conditions in RFC 2026 apply to RFC 1510.  How was that achieved?
Why can't it be done again?  Why is it tricky?

Further, hypothetically, if I were to ask the RFC editor the same
question today, would they point at RFC 2026 or RFC 3667?  If the
latter, how was that copying condition change negotiated?  Why would
it be tricky to publish RFC 3667bis, with a new copying condition
statement, and have it apply retroactively?

Finally, I found the text in the URL below so concise, clear and
illuminating that I want to point at it again:

   ftp://ftp.rfc-editor.org/in-notes/rfc-editor/rfc-copyright-story

Please read the motivation for the (old) copyright rules.

I believe I am trying to work towards those goals here, and that RFC
3667 (at the best) do not work toward the same goals or (at the worst)
that RFC 3667 work against those goals.

Thanks,
Simon

From: RFC Editor <[email-masked]>
Subject: Re: Copyright and copying conditions for RFC 1510?
To: Simon Josefsson <[email-masked]>
Cc: RFC Editor <[email-masked]>
Date: Mon, 16 Dec 2002 11:07:28 -0800

Simon,

The copyright statement applies retroactively.  Please follow the
instructions as stated at:

   ftp://ftp.rfc-editor.org/in-notes/rfc-editor/rfc-copyright-story

Thank you.

RFC Editor

On Sun, Dec 15, 2002 at 10:38:30AM +0100, Simon Josefsson wrote:
> rfc1510.txt does not mention copyright or copying condition. Does the
> copyright notice in
> 
> ftp://ftp.rfc-editor.org/in-notes/rfc-editor/rfc-copyright-story
> 
> apply retroactively?  If not, do you know who owns the copyright of
> the document and what the copying conditions are?
> 
> Thanks.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Jan 2005 12:27:02 -0500

>>>>> "Lawrence" == Lawrence Rosen <[email-masked]> writes:

    Lawrence> Scott Bradner wrote:
    >> multiple documents that "define" a technology (like MPLS) - the
    >> desire of teh open source folk to be able to take RFCs and
    >> change them in any way to modify the technology and then assert
    >> that they have now defined teh "right" version of the
    >> technology is not good for the IETF or for implementors since
    >> no one knows what is the correct technology description

    Lawrence> This statement reflects an improper understanding of the
    Lawrence> rules of open source and an exaggeration of the function
    Lawrence> of industry standards.

    Lawrence> Open source requires the freedom to create derivative
    Lawrence> works, regardless of the consensus of an IETF working
    Lawrence> group to define a standard. Of course, this does not
    Lawrence> mean that all resulting derivative works meet that
    Lawrence> standard or that IETF will bless any such derivative
    Lawrence> works. Nor does it necessarily mean that patent licenses
    Lawrence> will be available for those "non-standard" derivative
    Lawrence> works.

We don't want to certify implementations.  Instead, some want to make
sure that we don't make it easier to publish standards that serve
similar functions to our standards but that are different.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Jan 2005 12:25:56 -0500

>>>>> "Scott" == Scott Bradner <[email-masked]> writes:

    Scott> ps - remmber that one of the aims here is also to not have
    Scott> multiple documents that "define" a technology (like MPLS) -
    Scott> the desire of teh open source folk to be able to take RFCs
    Scott> and change them in any way to modify the technology and
    Scott> then assert that they have now defined teh "right" version
    Scott> of the technology is not good for the IETF or for
    Scott> implementors since no one knows what is the correct
    Scott> technology description

Scott, there are two issues here.
The first is identification.

I agree that the IETF has a strong desire to make sure that everyone
knows what the IETF MPLS spec is.  We should use whatever procedures
are appropriate to make sure that no one can go call a document the
IETF MPLS spec besides us and that no one is allowed to present their
MPLS as if it was the IETF's standard.

That's different from saying that no one should be allowed to take our
standard, develop something very similar to our standard and
distribute it as their own standard.

something very 

    Scott> also note that if we were that open the ITU (ETSI, 3GPP

What would be wrong with the ITU making some small change to MPLS and
calling it the ITU MPLS.  Depending on what that change was, we might
object to it technically, but fundamentally I have no problem with the
ITU calling something ITU MPLS provided that no one gets it confused
with IETF MPLS.  People here and on the ietf list have argued that
having the freedom for vendors or other SDOs to easily change our
standards would decrease interoperability.  The ITU would go do their
own thing and it would not work with our standard.  If we could
actually stop that from happening I'd give the argument more weight.

However as you've pointed out on the ietf list we cannot actually stop
the ITU from making their own MPLS.  In particular, the ITU could
publish an MPLS specification that referenced our specification and
then described how their specification differed.

I'm not familiar with the ITU's practices.  I am quite familiar with
vendors wishing to change specs.  I've been working with Kerberos for
the last 10 years.  Microsoft is a large Kerberos vendor with an
interesting set of requirements.

It took me a long time to learn this lesson, but I eventually realized
that the only way you will get interoperability is if the implementers
want interoperability.  If Microsoft cannot meet their requirements
within the standard, they will never the less find some way of meeting
their requirements.  Expecting them to do something else is ludicrous:
they are in the business of writing software that meets customer
needs.  

Even so, Microsoft has fairly strong standard compliance.  There are
two reasons.  First, customers actually want interoperability.  This
creates significant pressure to follow the standard and to meet
customer requirements by going through the standards process .
Secondly, we've learned that  telling a vendor "You can't meet your
customer need," is not the right approcah.  Instead you send messages
like "Doing that is undesirable for these reasons.  However if you're
going to do that anywa, here is the way of doing it with the least
disruption to interoperability."  Or if it turns out that the idea is
good, work with the vendor to extend the standard to support it.

In summary vendors will extend and change our standards if they need
to do so.  We can try to build a market demand for interoperability.
We can also work on clear documentation so people know what the IETF
standard is.  There's a second part of clear documentation though:
allowing people to find out what vendors are actually doing.

Our current practices actually discourage clear documentation.  If I'm
going to change an IETf standard I'm probably not going to document
what I actually do.  I cannot use the text of the IETF standard in my
documentation.  I could go write a diff to the IETF standard.  I'll be
doing that diff by hand using English or some other natural language.
It will probably end up being unclear and confusing.  Why bother?  On
the other hand if I could slap a big note at the top of the RFC
clearly indicating that I had changed it and this was now Sam's SMTP
rather than the IETF standard and then go change the paragraph I care
about, I might well go to that effort.

There's another way in which our claim that our IPR policies prevent
the ITU  or someone else from changing our standards does not hold
water.  The authors have the copyright.  Everyone here admits that the
authors have the necessary rights to give some third party permission
to create a derivative work.  I suspect there are a lot  of authors
who when faced with a deployed reality and a request to write a
non-IETF standard based on that deployed reality would go along.

I'd ask those who believe the current IPR policy is a good idea to
consider several things.  First look at other organizations that do
allow derivative works and see what problems it has actually caused
for them.  I think the Jabber Software Foundation and Free Standards
Group both have more liberal IPR policies than we do.  Second, look at
whether our IPR policies have actually prevented standards drift or
whether they just prevent clear documentation of drift that does
happen.  Finally, is it desirable to have haphazard and complicated
derivative works permissions based on the whim of authors?

--Sam

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 31 Jan 2005 00:05:58 +0100

I didn't receive an answer to the following questions.  The most
interesting questions are in the first paragraph below.  Is there
anyone who is familiar with RFC copyright history, and who is willing
to answer them?  I often find that understanding how things were done
in the past is useful when looking for ways to handle current
situations.  If we are looking at changing copying conditions on RFCs
retroactively now, knowing how it was done before seem like a relevant
piece of information to me.

Thanks.

Harald Tveit Alvestrand <[email-masked]> wrote on changing RFC

Thanks,
Simon

Simon,

Thank you.

RFC Editor