Subject: Reminder: Open issues

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 10 Feb 2006 16:42:58 +0100

The following are the open issues being tracked:

#1166 Quotations from RFCs and I-Ds

#1167 Excerpt labeling

#1168 Non-code excerpts

#1169 Modified excerpts

#1175 How can code be distinguished from non-code?

Thus far, we have had no specific requests for more issues.

If you want to raise a new issue on the list, please write ISSUE in the 
subject line of your message.

                 Harald, for the chairs

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

---

From: "todd glassey" <[email-masked]>
Date: Fri, 10 Feb 2006 07:53:45 -0800

How about

1 ) How IP is input and how the intent of the individual entrusting the IETF
with the IP figures into any asignements.

2) Whether the IETF's standards process requires an derivative release for
those implementing the mandatory interoperable instances of the protocol
description to qualify for the standards milestones.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 10 Feb 2006 17:07:50 +0100

Please add the following issue:

What license should the IETF grant to third parties on Contributions?

Some discussion:

That was the issue I tried to raise with my draft.

Scott's draft does touches on outbound rights, but I believe it would
be more useful to remove that material from Scott's draft.  Then
Scott's draft would fulfil the following WG work item but NO more.
That will simplify review, and speed up processing, since the outbound
rights issue is more problematic.  Certainly, if the current draft is
last called, I will comment on that part.

[proposed WG charter:]
   - An update to RFC 3978 (BCP) that attempts to specify an useful
     set of rights granted to the IETF by authors

What rights the IETF should grant to third parties should be resolved
either by another update to RFC 3978, or by recommendations to the IPR
Trust.  My recommendations is another update to RFC 3978.

Thanks,
Simon

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

> If you want to raise a new issue on the list, please write ISSUE in
> the subject line of your message.
>
>                 Harald, for the chairs

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 16 Feb 2006 09:12:01 +0100

--On 10. februar 2006 07:53 -0800 todd glassey 
<[email-masked]> wrote:

> How about
>
> 1 ) How IP is input and how the intent of the individual entrusting the
> IETF with the IP figures into any asignements.

Filed as #1197. I believe Scott Bradner's draft is intended to address the 
mechanism for assgning or licensing IPR to the IETF.
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 16 Feb 2006 09:14:47 +0100

> description to qualify for the standards milestones.

Filed as #1198.

I believe the discussion has shown a clear consensus that the answer is 
"no". If anyone (except Todd) wishes to call for a poll on the issue, we 
can do that, but I haven't seen anyone else (lawyer or non-lawyer) argue 
that there is a real issue here.

                          Harald

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 16 Feb 2006 09:16:28 +0100

Filed as issue #1199.

--On 10. februar 2006 17:07 +0100 Simon Josefsson <[email-masked]> wrote:

>> # 1166 Quotations from RFCs and I-Ds
>>
>> # 1167 Excerpt labeling
>>
>> # 1168 Non-code excerpts
>>
>> # 1169 Modified excerpts
>>
>> # 1175 How can code be distinguished from non-code?
>>

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 16 Feb 2006 12:03:38 +0100

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

> I believe the discussion has shown a clear consensus that the answer
> is "no". If anyone (except Todd) wishes to call for a poll on the
> issue, we can do that, but I haven't seen anyone else (lawyer or
> non-lawyer) argue that there is a real issue here.

I'd like to make sure I understand this question better.  I think I
understand your interpretation of it (the subject explain it
succinctly), but I'm not so sure I understand what Todd was saying.

I believe an implementation would only be a derivative work (in the
copyright sense) when it contains copyrighted material from the RFC.

Some RFCs doesn't seem to be implementable unless you include material
from the RFC in your implementation, in some way or another.  For
example, you can't implement IDNA without using the StringPrep tables.
I'd suppose the same would hold with some other things too, perhaps
including ASN.1 schemas and MIBs.

If my understanding is correct, I believe the answer would depend on
the RFC.  The answer would be "yes" for RFC 3454.

However, if Todd is asking, which it seems like, whether the IETF
standards process require the release of these rights, the answer is
certainly "no".  RFC 2026 doesn't say anything like that, from what I
can tell.  That is likely a flaw in that document though.  Perhaps
Todd meant that if the IETF standards process _SHOULD_ require the
release of these rights or not?  I didn't understand.

Anyway, this seem related to my issue of what license the IETF should
grant third parties on Contributions received and published by the
IETF.  If it is required to have certain rights to be able to
implement RFCs, those rights should arguable be granted by the IETF to
third parties, in the license statement.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 16 Feb 2006 12:12:38 +0100

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

> Filed as #1197. I believe Scott Bradner's draft is intended to address
> the mechanism for assgning or licensing IPR to the IETF.

I agree that Scott's mechanism sufficiently solve this issue.

There is a problem if the IETF would had to stand up in court to
defend ownership of an RFC.  The contributors have not signed a
copyright disclaimer, so the IETF would have to spend time explaining
that they actually own the copyright on the published documents.  If
the contributor would have signed papers transferring the copyright,
there would be less cause for confusion.

However, I don't see the IETF caring enough about this principle.
There is a tradition of ignoring copyright infringements (witness the
Sun getadddrinfo example).  It doesn't seem to be in the interests of
the IETF to defend its copyright license on documents strongly.  The
IETF doesn't seem to have little to gain from causing problems for
anyone re-using IETF documents against the RFC 3978 license.  Btw,
this also argue for selecting a permissive license.

Thanks,
Simon

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 16 Feb 2006 12:47:01 +0100

> there would be less cause for confusion.

As written, Scott's document does NOT propose transferring copyright; it 
proposes licensing the right to make derivative works.
Yes, the combination of a copyright statement naming an IETF-related body 
and a non-transfer of copyright makes my head hurt too....

> this also argue for selecting a permissive license.

Under the 3978 terms, we don't have a copyright to defend, except copyright 
in the boilerplate, so it kind of makes sense not to defend the rest....

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 16 Feb 2006 14:07:49 +0100

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

> As written, Scott's document does NOT propose transferring copyright;
> it proposes licensing the right to make derivative works.
> Yes, the combination of a copyright statement naming an IETF-related
> body and a non-transfer of copyright makes my head hurt too....

We've discussed this before, review the thread "RFC 3667 and copyright
asignment" from January 2005.

IIRC, copyright law says that if a copyright statement is present, the
indicated owner has some exclusive right to the document.  I have been
assuming that the IETF acquired those exclusive rights implicitly, by
authors contributing works with a copyright statement including the
ISOC (or IPR Trust).

Are you saying that there isn't even an implicit copyright transfer?

If so, I don't see what relevance the ISOC copyright has on documents.
What exactly does the ISOC copyright refer to?  If the ISOC hasn't
acquired any rights to the text in the document, why isn't another
copyright statement permitted, to indicate what copyright the actual
text has?

Having an incorrect copyright statements on documents doesn't seem
like something useful.

> Under the 3978 terms, we don't have a copyright to defend, except
> copyright in the boilerplate, so it kind of makes sense not to defend
> the rest....

Are you saying that the copyright statement only refer to the
boilerplate text?

Thanks.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 16 Feb 2006 14:32:50 +0100

> Are you saying that there isn't even an implicit copyright transfer?

As I said, it makes my head hurt, but here's what RFC 3667 says (section 5):

               ..........................The copyright notice
   also alerts readers that the document is an IETF Document, and that
   ISOC claims copyright rights to certain aspects of the document, such
   as its layout, the RFC numbering convention and the prefatory
   language of the document.  This legend is not intended to imply that
   ISOC has obtained ownership of the IETF Contribution itself, which is
   retained by the author(s) or remains in the public domain, as
   applicable.

I'll leave it to Jorge, Scott and the previoius generation of IPR chairs to 
explain how this was *arrived at*, but it is clear that it *is* described 
that way.

                         Harald

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 16 Feb 2006 14:56:50 +0100

>   retained by the author(s) or remains in the public domain, as

Ah, thanks for the reference.

However, with Scott's draft, it seems to me that the IETF will have
acquired all rights needed to act as owner of the document.

I don't understand why additional copyright claims are forbidden in
RFCs if the above is the case.  The ISOC copyright apparently is only
applicable to the layout and the boilerplate.  It thus seem prudent to
permit copyright statements that indicate the copyright owner of the
relevant text in documents.

I'd appreciate if people who know the history here would chime in.

Thanks,
Simon

---

From: "todd glassey" <[email-masked]>
Date: Thu, 16 Feb 2006 09:01:51 -0800

Simon - what I am saying is that if someone wants to implement a instance of
a technology that is described in IETF documents they need specific rights
for that. And those rights are much more than just "republication of the
IETF's document's" rights. Those implementor's  need a release against the
use of the IP described in the document. Or they need to know that they DONT
have those rights just because the IETF published a document.

Further, as part of its Standards Framework, the IETF has a formal metric in
its standards process that requires two (2) interoperable ports of any IP
defined in a RFC to advance that RFC to proposed standard status.

My quesiton is "How are those ports licensed?". They clearly go way beyond
the use or republication for commentay use models defined in the basic IETF
process. Further while it may have direct linkages to the IETF's standards
process I can see where someone who was shepparding a process through the
IETF's Framework might not want anyone else but specific players to
implement those two ports. The point is that the Ports are critical to the
Standards Framework as it is now and the licenseing of the materials for
those uses is still unclear.

Todd Glassey

----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: "Harald Tveit Alvestrand" <[email-masked]>
Cc: "todd glassey" <[email-masked]>; <[email-masked]>
Sent: Thursday, February 16, 2006 3:03 AM
Subject: Re: #1198 Implementation = derivative work? (Re: ISSUES How IP is
input and Intent...)

---

From: "todd glassey" <[email-masked]>
Date: Thu, 16 Feb 2006 09:05:20 -0800

The point is we need a formal statement from the Lawyer's that this process
works and is sufficient. And if they WILL NOT PRODUCE THAT STATEMENT then
this system and its processes are broken.

This is very black-and-white

Todd Glassey

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 17 Feb 2006 04:12:27 +0100

Simon Josefsson wrote:

> The contributors have not signed a copyright disclaimer

Getting past those "note well" everywhere for an extended
period of time is unlikely, isn't that good enough ?

It would be odd if I sue the new "trust" because one of my
contributions ended up in an RFC - why did I post it on an
IETF list if that wasn't my plan ?

> the IETF would have to spend time explaining that they
> actually own the copyright on the published documents.

Isn't that the new "trust", before that ISOC ?  It's hard
to define "the IETF", is it anything more than say the
"Jabber community" ?  Abd does it "own" _the_ copyright ?

I thought it "has" _a_ copyright, especially that of the
publication as RFC, but the authors still also have _a_
copyright, the actual content, RFC minus boilerplate.

And as per the stated rules anybody has the right to copy
an RFC as is (plus some other rights, but you're talking
about "own the copyright").

> I don't see the IETF caring enough about this principle

Somewhere you've to draw a line, a signed contract to buy
a six-pack would be overkill.  Which doesn't exclude that
it's dangerous, don't sell it to kids, or in countries
where alcohol is strictly illegal.

> Btw, this also argue for selecting a permissive license.

Depends.  A permissive license in clear contradiction to
what the authors stated, as in the case of the SHA RFC, is
misleading.  Claiming to have implemented SHA as stated in
the RFC is cumbersome, if conformant implementations MUST
be tested by an accredited lab, and the test result MUST
be registered.  And the RFC doesn't mention this legalese
with a single word, unless readers follow the link to the
real specification.

As soon as you start to talk about legal issues anywhere.
not only RFCs, your situation rapidly deteriorates.  The
exception are of course lawyers, because it's their job.

                        IANAL, Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Feb 2006 16:35:10 +0100

> Harald Tveit Alvestrand <[email-masked]> writes:
...
> copyright sense) when it contains copyrighted material from the RFC.

That is a different matter and one we do have to resolve.

What is quite clear, as a matter of common sense, is that the
reason we publish specifications is so that people can
implement them (it's called "running code" I believe).
It's also a matter of fact, because I checked recently for
another reason, that there doesn't seem to be any BCP that
actually says this. Well, BCP 95 does say:

    The mission of the IETF is to produce high quality, relevant
    technical and engineering documents that influence the way people
    design, use, and manage the Internet in such a way as to make the
    Internet work better.  These documents include protocol standards,
    best current practices, and informational documents of various kinds.

That makes it prety clear but it doesn't actually say:

    The IETF publishes specifications with the intention that people
    should implement them.

I wouldn't mind seeing that in 3978bis.

     Brian

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 17 Feb 2006 17:39:51 +0100

> period of time is unlikely, isn't that good enough ?

No, since the NOTE WELL doesn't say anything about signing over the
copyright of your work to the IETF, as far as I know.

It says, if I understand correctly, that participators are providing
their copyrighted input under the license in BCP 78.

> copyright, the actual content, RFC minus boilerplate.

A copyright ownership imply certain exclusive rights.

ISOC/Trust has exclusive rights to the boilerplate text.

The authors has exclusive rights to the content.

> about "own the copyright").

This is not in RFC 3978 though.  Third parties are not given any
rights whatsoever by the license in RFC 3978.

> misleading.

I don't follow.  In what way?

> Claiming to have implemented SHA as stated in the RFC is cumbersome,
> if conformant implementations MUST be tested by an accredited lab,
> and the test result MUST be registered.

This seem pointless.  I haven't seen a serious effort to make IETF
produce standards in this way.

> And the RFC doesn't mention this legalese with a single word, unless
> readers follow the link to the real specification.

The SHA RFC do mention legalese.

Legal text apply even if it is not part of the document, too.

Thanks.

---

From: "todd glassey" <[email-masked]>
Date: Fri, 17 Feb 2006 09:48:43 -0800

Brian - the Mission of the IETF is to create Internet Standards - that is
the ONLY reason the IETF exists. And if publishing alone wont get you there,
then the derivative rights will have to be addressed too.

Todd Glassey

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: "Simon Josefsson" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, February 17, 2006 7:35 AM
Subject: Re: #1198 Implementation = derivative work? (Re: ISSUES How IP is
input and Intent...)

---

From: "todd glassey" <[email-masked]>
Date: Fri, 17 Feb 2006 10:04:59 -0800

Simon there is an underlying flaw in all of this regarding notewell and what
is posted in the WG's and that is that this becomes the community property
of the IETF in the interest of furthering its standards process. The IETF
maintaines and operates the mailing lists through its network of volunteers
but it still as the formam umbrella under which the lists are operated can
claim any and all ip developed or vetted therein one would think.

That said, only the submittals to the Editor's are in question, since the
IETF probably does indeed own what happens in the WG's at least from a
republishing rights standpoint.

The derivative rights question with regard to the production of the two
required ports is still a stumbling block I think but we can work that out
too.

Todd Glassey

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 17 Feb 2006 21:06:25 +0100

Simon Josefsson wrote:
 
 [NOTE WELL]
> It says, if I understand correctly, that participators are
> providing their copyrighted input under the license in BCP 78.

Yes.  It's not exactly obvious for me how to interpret BCP 78
wrt to mailing list articles and similar contributions, but I
guess it does the right thing.
 
>> an RFC as is
[...]
> This is not in RFC 3978 though.  Third parties are not given
> any rights whatsoever by the license in RFC 3978.

 [7.1]
| b. the right to let the document be freely reproduced in the
|    formats that the IETF publishes it in

Is that something else then ?

>> A permissive license in clear contradiction to what the 
>> authors stated, as in the case of the SHA RFC, is
>> misleading.
 
> I don't follow.  In what way?

There are some restrictions in the original (referenced) SHA
spec., e.g. they apparently reserve the right to define what
a "conforming" implementation is.  Which is fine to get some
quality control and interoperable implementations, but it's
no free service, the testing is done by an accreddited lab,
and there is an registration fee for the test result.

In many cases that's probably irrelevant, but for commercial
products, one conforming (= spent the money for registration),
the other not, it might be relevant.

It could be also relevant if you want to sell a product to
governmental agencies which "must" ask for a conforming SHA.
 
> This seem pointless.  I haven't seen a serious effort to
> make IETF produce standards in this way.

Nor me.  It's on the NIST (?) Web page for SHA.  Accredited
"test labs" with some "registration" is no new idea, over here
that's mandatory for e.g. cars.  And IIRC also for e-signature
software.

> Legal text apply even if it is not part of the document, too.

Okay, but the RFC license sounded like "enjoy" (not passing 
one of yor tests, but that's an unrelated issue), while the
referenced source had _apparently_ some serious restrictions.

                      As always: IANAL

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 20 Feb 2006 09:59:50 +0100

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

> for that.

If the document includes material they have to copy into an
implementation, like for StringPrep or ASN.1 schemas, I agree.

> And those rights are much more than just "republication of the
> IETF's document's" rights.

Yes, a permission to be able to create a derivative work that third
parties can modify would be needed.

> Those implementor's need a release against the use of the IP
> described in the document. Or they need to know that they DONT have
> those rights just because the IETF published a document.

By "IP", I hope and assume you refer to copyrights.

> defined in a RFC to advance that RFC to proposed standard status.

I thought it was draft standard, but anyway.

> those uses is still unclear.

The copyright license is unclear in some aspects, but at least the
intent seem clear that it doesn't permit the things some organizations
need to implement it.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 20 Feb 2006 10:10:56 +0100

> guess it does the right thing.

"IETF Contributions" include mailing list articles too.

Making the IETF have rights to IETF posts may be a bit strange.  It
seems the IETF only need those rights for RFC documents.

> Is that something else then ?

The section 7 title is "Exposition of Why These Procedures Are the Way
They Are".  It doesn't seem to be part of the license.

> governmental agencies which "must" ask for a conforming SHA.

Oh, I see what you are getting at.  The authors cannot grant more
rights than what they have.  If the original SHA spec places certain
restrictions, re-publishing that document without those restrictions
seem wrong.

However, this is just the copyright license though.  Does the original
SHA spec reserve the right to define what a confirming implementation
is, in the copyright license?  If that right is reserved in any other
context, it is probably not relevant.

If "SHA" is a trademark, you couldn't implement the SHA RFC and claim
you have SHA, but under trademark law it is certainly possible to
claim that you implement the SHA RFC.

> that's mandatory for e.g. cars.  And IIRC also for e-signature

Right.  Whether this is relevant for the SHA RFC depends on where the
rights are reserved.  If NIST says, in the copying conditions, that
you can't create a derivative work from the SHA specs without
conformity testing, it will not be possible to use it in free
software.

> referenced source had _apparently_ some serious restrictions.

I didn't know about the referenced sources.  It seems serious.  I
wonder whether the authors of the SHA RFC had acquired all the rights
they needed to be able to grant the rights they grant to the IETF and
to third parties.

Thanks,
Simon

---

From: "todd glassey" <[email-masked]>
Date: Mon, 20 Feb 2006 07:23:59 -0800

----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "Harald Tveit Alvestrand" <[email-masked]>; <[email-masked]>
Sent: Monday, February 20, 2006 12:59 AM
Subject: Re: #1198 Implementation = derivative work? (Re: ISSUES How IP
isinput and Intent...)

> implementation, like for StringPrep or ASN.1 schemas, I agree.

Even if the document contained a descripttive analysis or list of steps and
the handshaking necessary to do that. This would also constitute a
derivative license. In fact whenever ANYTHING except the republication or
excerpting of the draft submissions to the Editors happens it would require
Derivative Rights to do anything with it.

> By "IP", I hope and assume you refer to copyrights.

No the derivative rights - The point is that the derivative rights are
separate from the publication rights, and in all instances there is a need
to protect and defend those rights or else suffer the loss of those rights.
The IETF is no where ready for this and since it cannot financially defend
the IP it has now without an operating budget, the entire IETF ownership and
protectability of that is very doubtful in a court. Since I am at this very
second suing in Federal Court over an IP matter, I can attest to the pain
and cost of this activity.

> I thought it was draft standard, but anyway.

I am not referring to the state of the document within the framework, but
rather the requirements of the IETF's standards process as a whole.

> intent seem clear that it doesn't permit the things some organizations

Agreed - so the win here is in deciding what those rights are to be and how
they will be built into the process.

> >> >> 2) Whether the IETF's standards process requires an derivative
release
> > for

---

From: "todd glassey" <[email-masked]>
Date: Mon, 20 Feb 2006 07:32:00 -0800

Simon - what is happening here is that we are arguing over what constitutes
Intellectual property and the US Courts have long since decided and evolved
that definition to keep it current. That said the IETF doesnt get to
redefine the term IP unless it formally wants to create what is referred to
as a Term of Art (ToA) inside of the larger process of its standards
framework.

If it were to do that then the issues of notification and stating the
differences between the IETF's rules and process and how Government's or
Court's are forced to deal with IP.

That said, in answer again to the commentary about code and IP and what
makes it up, the IP in the text portions of the document is equally
protectable as the IP in the code-example portion of the document, if such
exist meaning that there is really no clean way to tell the two apart. If
you doubt this go spend a couple of days looking at patent applications in
the EU or US...

Todd Glassey

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 22 Feb 2006 13:57:03 +0100

> seems the IETF only need those rights for RFC documents.

One reason why we have to have them is that in many cases, people will send 
messages like "I think better text for section X would be...." - and the 
editor will cut-and-paste that text into the document.

Unless the mailing list article is an "IETF contribution", the editor would 
have to check with the sender that he gives permission to use his words.

Keep It Simple.

                    Harald

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 22 Feb 2006 13:57:03 +0100

Keep It Simple.

                    Harald

---

From: "todd glassey" <[email-masked]>
Date: Wed, 22 Feb 2006 06:59:23 -0800

Harald I am replying to you personally offlist and Jorge on this one

Todd Glassey
----- Original Message ----- 
From: "Harald Tveit Alvestrand" <[email-masked]>
To: "Simon Josefsson" <[email-masked]>; "Frank Ellermann"
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, February 22, 2006 4:57 AM
Subject: Righs in mailing list articles (Re: #1197 Re: ISSUES How IP is
input and Intent...)

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 22 Feb 2006 17:44:14 +0100

> Harald I am replying to you personally offlist and Jorge on this one

Note that a private note to the WG chair is not mentioned in the NOTE WELL 
statement, so cannot with certainty be considered an "IETF Contribution".

I will not make any use of the offlist-contributed material in the 
evaluation of the result of the Last Call on the issue; this seems to be 
the most prudent course both legally and as an IETF process issue.

                    Harald