Subject: Re: I-D ACTION:draft-ietf-ipr-outbound-rights-03.txt

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 May 2007 10:35:10 +0200

I'm pretty happy with this version.

One minor substantive comment:

> 6.3.  Rights Granted for Implementing based on IETF Contributions
...
> 
>    Additionally, the Trustees of the IETF Trust should define a
>    textually representation to be included in an IETF contribution to
>    indicate that a portion of the document is considered by the authors
>    (and later the working group, and upon approval the IETF) to be code,
>    and to be subject to the permissions granted to use code.

I think this needs to be "optionally included", to be completely
clear about the intention.

Nits:

> 1.  Introduction
> 
>    Under the current operational and administrative structures, IETF
>    intellectual property rights are vested in the IETF trust
>    administered by a board of trustees made up of the members of the
>    IASA [RFC4371].  

That should be IAOC. IASA potentially includes other people too.

> 3.  When This Document Takes Effect
> 
> 

This blank section isn't needed; the topic is covered later
in the document.

     Brian

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

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 03 May 2007 13:44:35 +0200

6.5.  Additional Licenses for IETF Contributions

   There have been contexts where the material in an IETF contribution
   is also available under other license terms.  The IETF wishes to be
   able to include content which is available under such licenses.  It
   is desirable to indicate in the IETF contribution that other licenses
   are available.  It would be inappropriate and confusing if such
   additional licenses restricted the rights the IETF intends to grant
   in the content of RFCS.

The first sentence strikes me as confusing when reading the second
sentence.  In the second sentence, the material is already included in
the IETF contribution, therefor a "wish to be able to include it" seems
confusing.  Why wish to include something that is already included?

I wonder if the intention here is rather that there may be material,
licensed under other license terms, that may be useful to include in
IETF contributions?

If so, I would rewrite the first sentence as:

   There have been contexts where material available under other license
   terms are relevant to an IETF contribution.

I believe this would cover the case of including example code with a BSD
license, as for example in RFC 4226.

Section 6.5 continues:

   However, the IETF does not wish to have IETF Contributions contain
   additional copyright notices and licenses, as that introduces a
   number of additional difficulties.  Specifically, additional text in
   the document, and any additional license referred to by permitted
   additional text MUST NOT in any way restrict the rights the IETF
   intends to grant to others for using the contents of IETF
   contributions.

I'm quite confused by this paragraph.

It first says that additional copyright notices and licenses should not
be in documents.  Then it says that those licenses MUST NOT restrict the
rights the IETF grants to others.

What license is referred to in the second sentence?  An externally
granted license?

It is perfectly fine for some material to be available under two
mutually or partially exclusive licenses.  That is the case when a piece
of code is available under both the BSD license and the RFC 3978
license.  A consumer can chose which license to use.

One could read the MUST NOT requirement to say that contributors cannot
license the material they own the copyright on in any way the like.
That seems quite at odds with IETF's past tradition.  The intention used
to be that authors own their contribution, and can chose to sub-license
it to anyone else under any license they chose.  That has nothing to do
with the license already granted to the IETF.

I believe the entire paragraph is problematic.

First, as written, it prevents the inclusion of example code, available
only under a BSD, MIT, GPL, etc license, into IETF documents.  Including
such code is useful, and I believe furthers the IETF's goal.

Secondly, it restricts what IETF contributors can do with their own
works outside of the IETF context.

   Authors of contributions retain all rights in their contributions.
   As such, an author may directly grant any rights they wish separately
   from what the IETF grants.  However, a reader wishing to determine or
   make use of such grants will need to consult external sources of
   information, including possibly open source code and documents, or
   contact the author directly.

Here this seem to re-establishes the normal IETF tradition, which is
good.

As I don't understand the intention here, I can't suggest alternative
text, assuming any replacement text is necessary at all.

/Simon

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 May 2007 09:47:12 -0400

--On Thursday, May 03, 2007 1:44 PM +0200 Simon Josefsson 
<[email-masked]> wrote:

>    There have been contexts where the material in an IETF
> contribution    is also available under other license terms.
> The IETF wishes to be    able to include content which is
> available under such licenses.  It    is desirable to indicate
> in the IETF contribution that other licenses    are available.
> It would be inappropriate and confusing if such    additional
> licenses restricted the rights the IETF intends to grant    in
> the content of RFCS.
>
> The first sentence strikes me as confusing when reading the
> second sentence.  In the second sentence, the material is
> already included in the IETF contribution, therefor a "wish to
> be able to include it" seems confusing.  Why wish to include
> something that is already included?

I agree with Simon that this is confusing.

Let me take a shot at guessing what the intent might be.

Suppose I submit something as an IETF Contribution.   Suppose I 
have granted, or am willing to grant, licenses to others under 
other circumstances.  I think what is being said here is that 
the IETF understands that it is in everyone's interest to make 
the information about those other licenses, or about how the 
information may be obtained, available.

Is it possible that we can sweep away the circumlocutions by 
simply saying something like, probably after the "authors retain 
all rights" statement:

    In addition to the license granted to the IETF, contributors
    how have made other licensing arrangements may document
    those arrangements as part of the contribution, using
    mechanisms that may be specified from time to time by the
    IETF Trust.  The absence of documentation of additional
    licenses should not be taken to indicate that those licenses
    are not available; instead, the author should be contacted
    for information as needed.

Note the desire to avoid getting hung up in boilerplate here. 
Then, if I were the Trust, I'd construct, in consultation with 
Counsel, one sentence that said something like "Additional 
licenses may be available from the author for some or all of 
this material, see <link>", where <link> is supplied by the 
author.

When that link is essentially a pointer to some well-known 
literary work, I'd expect to see something like "The material in 
this Contribution is also available under the Tie Your Hands and 
Feet Together (TYHAF) license whose text is available at <link>. 
Where it is more individualized and the author does not have a 
convenient mechanism for available for providing a stable link, 
I think the IETF should provide for posting such license 
materials on the same basis that we provide for posting IPR 
disclosures of other varieties.

Does that disentangle things?

Or, if I've missed the intent of the that section, could someone 
please explain it in plain English (rather than pseudo-lawyer)?

      john

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 03 May 2007 16:36:50 +0200

> Does that disentangle things?

If put into the document, that would at least make the situation
clearer.  I don't think the situation would be ideal though.

If I understand your proposal correctly, it does not allow the inclusion
of material taken from BSD/GPL implementations into IETF documents, at
least not without permission to re-license the material under the IETF
license from all copyright holders.

I believe, for example, example code is helpful in many stages when new
technology is introduced -- testing, implementing, interop testing etc.
For example, I believe that IDNA implementations would not have been
available as quickly if the Punycode code had not been available in the
RFC.  Essentially, it is good for the IETF if the standards are easier
and quicker to implement and deploy.  Therefor, I believe the IETF rules
should permit including external material.  If you look in the last
years worth of RFCs, there is already source code borrowed from external
projects, with various licensing conditions in them.  I haven't seen
anyone claim it has been bad for the IETF to include such code, and I
know people find it useful.  So it is already appear to be running
practice.

I don't know if it is possible to devise a license situation which would
make everyone happy here.  It depends on whether people believe having
additional copyright notices and licenses is harmful.  As someone who
contributes to software with multiple copyright notices and multiple
licenses every day, I feel perfectly comfortable with that situation.

/Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 May 2007 17:02:04 +0200

> license from all copyright holders.

I think that's correct, and I have the feeling that is where we will
find the least rough consensus.

To be clear, if I write some code, contribute it to the IETF, and
subsequently contribute it to an open source project, I don't see
a problem. If I do it the other way round, that might be awkward.

      Brian

---

From: "todd glassey" <[email-masked]>
Date: Thu, 3 May 2007 08:38:37 -0700

Open Source licenses cannot grant more rights to that code or change the 
original licensing of that or its derivatives however...

Todd Glassey

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 03 May 2007 19:41:01 -0400

My personal understanding of what I thought I was trying to say.

1) Obviously, whatever I meant it needs to be fixed.  Suggestions 
such as the one below are necessary.
2) There are two different issues that we had said we wanted to 
address in this section, as I understood it.  One is the issue 
mentioned separately by Brian, and one is the issue mentioned 
separately by Simon.

a) With regard to code which is also available under other terms (for 
example because it was written after the IETF code segment) we wanted 
to acknowledge that this was perfectly acceptable, and suggest thtat 
techniques like contacting the author were appropriate for finding 
these.  (Originally it just said "contact the author" as per John's 
comment below.  I changed that because someone had said roughly ~it 
is not always necessary or desirable to contact the author.~)

b) With regard to code that is licensed under different rules with 
some restrictions not in the IETF rules, that code can not be 
included as sample code in the IETF documents.  I was told that the 
rough consensus was against allowing more restrictive licenses to be 
included in the documents.  So, for example, any code that requires 
that changes be returned to the origin can not be included as code in 
an IETF document according to these rules.   Would it be nice to be 
able to use such code?  Sure.  But having multiple different sets of 
rules, and license terms in documents, and efforts to decide ~are we 
willing to include this code with this license?~ was not what the 
group decided.

Yours,
Joel

At 09:47 AM 5/3/2007, John C Klensin wrote:

>Suppose I submit something as an IETF Contribution.   Suppose I have 
>granted, or am willing to grant, licenses to others under other 
>circumstances.  I think what is being said here is that the IETF 
>understands that it is in everyone's interest to make the 
>information about those other licenses, or about how the information 
>may be obtained, available.
>
>Is it possible that we can sweep away the circumlocutions by simply 
>saying something like, probably after the "authors retain all 
>rights" statement:
>
>Note the desire to avoid getting hung up in boilerplate here. Then, 
>if I were the Trust, I'd construct, in consultation with Counsel, 
>one sentence that said something like "Additional licenses may be 
>available from the author for some or all of this material, see 
><link>", where <link> is supplied by the author.
>
>When that link is essentially a pointer to some well-known literary 
>work, I'd expect to see something like "The material in this 
>Contribution is also available under the Tie Your Hands and Feet 
>Together (TYHAF) license whose text is available at <link>. Where it 
>is more individualized and the author does not have a convenient 
>mechanism for available for providing a stable link, I think the 
>IETF should provide for posting such license materials on the same 
>basis that we provide for posting IPR disclosures of other varieties.
>

---

From: Don Armstrong <[email-masked]>
Date: Thu, 3 May 2007 16:41:03 -0700

On Thu, 03 May 2007, Brian E Carpenter wrote:
> subsequently contribute it to an open source project, I don't see a
> problem. If I do it the other way round, that might be awkward.

If you were the copyright holder, it wouldn't matter either way,
because you could just grant appropriate rights to the IETF after
granting appropriate rights to the FOSS project.

The only place where this becomes an issue is taking code which cannot
be relicesed to the IETF but is useful and placing it in a standards
document.

Getting back to the main issue, I would think that licenses like
MIT/Expat or the 1,2,4-clause BSD license would be appropriate even
for inclusion in IETF works because they contain no significant
restrictions on the use of the code. GPLed and other works may cause a
problem, because they inherently restrict wide inclusion of code in
projects.[1]

If the requirements for the inclusion of code are written in an
affirmative manner, that is to say users of included code must be able
to do X, Y, Z, then the actual license that the code is under matters
little so long as it complies. The downside is an increased need for
tracking the actual license of a code, but considering that the IETF
will have to track the copyright and licensing state of every
copyrightable work submitted anyway, it should not be significant.

Don Armstrong

1: I should note here that even the FSF has PD'd quite a few important
works specifically to allow the type of interoperability that the IETF
seeks to acchieve, so I'd think that at least some copyright holders
would be willing to relicense even GPLed works appropriately.
-- 
N: Why should I believe that?"
B: Because it's a fact."
N: Fact?"
B: F, A, C, T... fact"
N: So you're saying that I should believe it because it's true. 
   That's your argument?
B: It IS true.
-- "Ploy" http://www.mediacampaign.org/multimedia/Ploy.MPG

http://www.donarmstrong.com              http://rzlab.ucr.edu

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 03 May 2007 19:41:01 -0400

Yours,
Joel

---

From: Don Armstrong <[email-masked]>
Date: Thu, 3 May 2007 16:41:03 -0700

Don Armstrong

---

From: "todd glassey" <[email-masked]>
Date: Fri, 4 May 2007 10:49:05 -0700

Simon -

----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, May 03, 2007 4:44 AM
Subject: Section 6.5: Additional Licenses for IETF Contributions

>   is also available under other license terms.

This is critical since it means that the IETF's Outgoing Licensing must meet 
the requirements of all of that other licensing.

Likewise, publishing any document and its Code Inclusions for any and all 
uses, clearly violates the Research Exemption section from the US Copyright 
code as well, since the only exemption is for specific research and not "any 
and all" uses as the IETF has stated in its outgoing licensing.

>   The IETF wishes to be
>   able to include content which is available under such licenses.

Again - so if this is true, then the terms and conditions of those licenses 
need to be retained in the IETF's outgoing rights model.

>   It
>   are available.

It is critical in disclosing that there are external rights issues 
pertaining to this IP and as such the relying party needs to do proper 
diligence on their rights to use this IP which may in fact be "not at all" 
depending on the external rights.

Also if External Rights issues pop up, since they (those other IP Rights 
holders) will have Take Down and Retraction/Termination Processes, for the 
IETF to intentionally publish something under its ANY AND ALL USES FOREVER

---

From: "todd glassey" <[email-masked]>
Date: Fri, 4 May 2007 10:49:05 -0700

Simon -

----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, May 03, 2007 4:44 AM
Subject: Section 6.5: Additional Licenses for IETF Contributions

Also if External Rights issues pop up, since they (those other IP Rights 
holders) will have Take Down and Retraction/Termination Processes, for the 
IETF to intentionally publish something under its ANY AND ALL USES FOREVER 
constraint clearly violates those other controls effectivity, and anyone who 
reads those licenses would see this.

>  It would be inappropriate and confusing if such

Again without some process to control the IP after its published the IETF is 
willingly and intentionally creating a process to enable the violation of 
others IP rights. This is more than messy... its grounds for litigation 
against those parties involved, their sponsors and the IETF/ISOC as a whole 
IMHO.

>   number of additional difficulties.

The problem is in instances where those other IP's are published under 
constraints where they are protected after publication and the IETF is 
seeking to hide that in its publishing its own statement's without those 
same controls. Likewise since the IETF's use model is really constrained to 
just "research purposes" there is another issue here and that is the damage 
those licenses do to the IP Holders that the IETF is intenionally trying to 
screw by forcing them to have to sue the IETF and the massive number of 
people involved here.

>   Specifically, additional text in

Then the IETF may not publish anything that it does not fully control... 
meaning without proper IP releases it can publish nothing.

> rights the IETF grants to others.

Which means simply that:

    1) The IETF has proclaimed that its outgoing license is the only license 
protecting the IP in its documents and Code Samples/Examples...

    2) And that as such no other licenses will be printed in the IETF 
documents if they exist...

This isnt complex, its just broken.

> Secondly, it restrictconstraint clearly violates those other controls effectivity, and anyone who 
reads those licenses would see this.

>  It would be inappropriate and confusing if such

Again without some process to control the IP after its published the IETF is 
willingly and intentionally creating a process to enable the violation of 
others IP rights. This is more than messy... its grounds for litigation 
against those parties involved, their sponsors and the IETF/ISOC as a whole 
IMHO.

>   number of additional difficulties.

The problem is in instances where those other IP's are published under 
constraints where they are protected after publication and the IETF is 
seeking to hide that in its publishing its own statement's without those 
same controls. Likewise since the IETF's use model is really constrained to 
just "research purposes" there is another issue here and that is the damage 
those licenses do to the IP Holders that the IETF is intenionally trying to 
screw by forcing them to have to sue the IETF and the massive number of 
people involved here.

>   Specifically, additional text in

Then the IETF may not publish anything that it does not fully control... 
meaning without proper IP releases it can publish nothing.

> rights the IETF grants to others.

Which means simply that:

    1) The IETF has proclaimed that its outgoing license is the only license 
protecting the IP in its documents and Code Samples/Examples...

    2) And that as such no other licenses will be printed in the IETF 
documents if they exist...

This isnt complex, its just broken.

> Here this seem to re-establishes the normal IETF tradition, which is

Garbage - there is NO IETF tradition. This is the lie that the IPR Working 
Group is using to promulgate these bad process models into rule and process 
"Oooooh its an IETF Tradition and the IETF community demands it..."

OK Simon - prove it. Lets force this issue of that all IPR rules must be 
approved by all of the IETF members in place when those rules are modified, 
and that all the sponsor's of those individuals must also at the Corporate 
or Entity Counsel level, sign off on the IETF's participation process.

If this were put in place, I bet the IETF is turned into a ghost-town by the 
end of the week.

---

From: "todd glassey" <[email-masked]>
Date: Fri, 4 May 2007 10:29:44 -0700

----- Original Message ----s what IETF contributors can do with their own

---

From: "todd glassey" <[email-masked]>
Date: Fri, 4 May 2007 10:29:44 -0700

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: "IPR WG" <[email-masked]>
Sent: Thursday, May 03, 2007 1:35 AM
Subject: Re: I-D ACTION:draft-ietf-ipr-outbound-rights-03.txt

> clear about the intention.

I disagree with the term OPTIONALLY. This is a key part of defining 
derivative rights inside the IETF's licensing model

>>    administered by a board of trustees made up of the members of the

It also needs to have the word 'AND' added between 'trust' and 
'administered' so it reads properly.

- 
From: "Brian E Carpenter" <[email-masked]>
To: "IPR WG" <[email-masked]>
Sent: Thursday, May 03, 2007 1:35 AM
Subject: Re: I-D ACTION:draft-ietf-ipr-outbound-rights-03.txt

> clear about the intention.

I disagree with the term OPTIONALLY. This is a key part of defining 
derivative rights inside the IETF's licensing model

>>    administered by a board of trustees made up of the members of the

It also needs to have the word 'AND' added between 'trust' and 
'administered' so it reads properly.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 07 May 2007 11:11:36 +0200

"Joel M. Halpern" <[email-masked]> writes:

> some restrictions not in the IETF rules, that code can not be included
> as sample code in the IETF documents.  I was told that the rough
> consensus was against allowing more restrictive licenses to be
> an IETF document according to these rules.

That would make it impossible to include example code licensed under,
e.g., the BSD, MIT or similar licenses, in IETF document.  Doing that
has been done with good results in several RFCs.  It can be argued that
including example code, under various licenses (including less
permissive than this, which there are many examples of in past RFCs),
furthers the goal of the IETF, and therefor should be permitted.  The
argument against appear to be variations on the following theme:

> Would it be nice to be able to use such code?  Sure.  But having
> multiple different sets of rules, and license terms in documents, and
> efforts to decide ~are we willing to include this code with this
> license?~ was not what the group decided.

This situation would be the same as for patents.

/Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 07 May 2007 20:07:49 +0200

> argument against appear to be variations on the following theme:
The argument against is that it's onerous and nearly impossible for 
users to track down the provenance and licensing of each individual 
piece of code in an RFC to verify its usability, unless the IETF can 
help them.

The conclusion of the WG, as I understood it, was that we wanted 
implementors to be able to exercise the set of rights that the IETF 
grants to users of IETF code to all users of all IETF code (going 
forward from the day of implementation).
> This situation would be the same as for patents.
No, because the publication of a text (such as an RFC, or a citation 
from an RFC) can never violate a patent.
The publication of a text can violate a copyright.

---

From: Don Armstrong <[email-masked]>
Date: Mon, 7 May 2007 16:24:36 -0700

On Mon, 07 May 2007, Harald Alvestrand wrote:
> Simon Josefsson wrote:
> >That would make it impossible to include example code licensed
> >under, e.g., the BSD, MIT or similar licenses, in IETF document.
>

The IETF should have available to it in some format the provenance and
licensing information corresponding to every copyrightable segment
created by any author present in the RFC. The IETF just has to figure
out how to best convey this information to readers of the RFC in a
useful format so they can make decisions on their own as to which code
should be used.

> forward from the day of implementation).

Right, but that means that licenses which are less restrictive than
the IETF requires should be allowed, because those rights are granted.

Don Armstrong

-- 
If everything seems to be going well, you have obviously overlooked
something.
 -- Steven Wright

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 7 May 2007 23:24:18 +0200

On 7 maj 2007, at 20.07, Harald Alvestrand wrote:

>>> included
> piece of code in an RFC to verify its usability, unless the IETF  
> can help them.

A natural requirement to publish something as an IETF document would  
be that any copyright notices and licenses are clearly marked.

Btw, having clear markings is what the current WG documents imply  
too: documents need to clarify which parts are licensed under the  
future "IETF code license" and which parts are under the "IETF text  
license".

> forward from the day of implementation).

I understood it as a conclusion to not permit copyleft licenses, but  
nothing further.

> No, because the publication of a text (such as an RFC, or a  
> citation from an RFC) can never violate a patent.

Handling a problem like that is why we write policies that  
contributors must follow.

/Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 May 2007 13:47:33 +0200

> piece of code in an RFC to verify its usability, unless the IETF can 

Furthermore, it is not particularly onerous to expect RFC authors to
obtain the necessary rights direct from the code authors. There is nothing
that I know of that prevents a code author from granting derivative works
rights to the IETF *and* contributing the same code to an open source project.
There would only be a violation if somebody received a distribution of
open source code and extracted code from it to insert in an RFC.

And I don't think we (the IETF) need to do anything special about this,
since the act of contributing text carries with it acceptance of our
rules. We just need to warn contributors to ensure that they have the
original code authors' direct agreement.

     Brian

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 14 May 2007 16:34:21 +0200

> original code authors' direct agreement.

That could be noted in an example for the inbound I-D or Simon's I-D.
Something like this:

   In draft x author X reproduces code y written by Y.  Author X got the
   permission of Y to do this, and might note it in the acknowledgements
   of draft x:  "Thanks to Y for the permission to reproduce code y in
   this contribution, readers can use code y as specified in BCP 78bis."

If that's what you're talking about.  

Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 May 2007 16:55:13 +0200

> If that's what you're talking about.  

Yes, I think so. This is the one case where getting explicit permission
may be necessary; that's something we want to avoid in general.

     Brian

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 May 2007 11:24:20 -0400

--On Monday, 14 May, 2007 16:55 +0200 Brian E Carpenter
<[email-masked]> wrote:

>>    In draft x author X reproduces code y written by Y.
>>    Author X got the permission of Y to do this, and might
>>    note it in the acknowledgements of draft x:  "Thanks to Y
>>    for the permission to reproduce code y in this
>>    contribution, readers can use code y as specified in BCP
>>    78bis."
>> 

Of course, our existing rules about acknowledgments encourage,
if not require, such statements anyway.   One can even argue
that, if Y is not actively participating in the IETF, explicit
permission is required in many cases: without it, a strict
reading of our rules prevents X from posting the document in the
first place, even as an I-D.

    john

---

From: "todd glassey" <[email-masked]>
Date: Mon, 14 May 2007 09:22:31 -0700

----- Original Message ----- 
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>
Sent: Monday, May 14, 2007 7:34 AM
Subject: Re: Section 6.5: Additional Licenses for IETF Contributions

>   this contribution, readers can use code y as specified in BCP 78bis."

How does the submitter prove they have legal capability to submit 
third-party IP's to the IETF or does the IETF even care?

Todd Glassey

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 May 2007 12:39:00 -0400

--On Monday, 14 May, 2007 09:22 -0700 todd glassey
<[email-masked]> wrote:

>>   In draft x author X reproduces code y written by Y.  Author
>>   X got the permission of Y to do this, and might note it in
>>   the acknowledgements of draft x:  "Thanks to Y for the
>>   permission to reproduce code y in this contribution,
>>   readers can use code y as specified in BCP 78bis."
> 
> How does the submitter prove they have legal capability to
> submit third-party IP's to the IETF or does the IETF even care?

Todd,

You may disagree based on your extensive legal experience, but
my impression is that, if the IETF requires that the submitter
assert that he, she, or it has that permission/capability, then,
if the submitter is (deliberately or not) incorrect about that,
it is mostly the submitter's problem, not the IETF's.  That is,
IMO, the right situation since one doesn't want the IETF in the
business of trying to evaluate who has which permissions and who
does not ... or, to put that in the context of your note, of
evaluating whether the submitter's proof is adequate.

I suggest that, for these types of issues --remembering that we
are talking about copyrights and not patents-- we want the IETF
to act as nearly as possible in the role of a publisher who does
not get in the middle of those ownership rights disputes.   Even
if we were talking about patents, the IETF would be publishing
information that is supposed to be public, not "practicing" the
invention.

      john

---

From: "todd glassey" <[email-masked]>
Date: Mon, 14 May 2007 10:26:43 -0700

John - I am speaking from simple UCC which clearly says any property with a
value of more than $500 takes a signature to convey to anyone. The issue is
that the Court's and especially those based on Judge Grimm's Digital
Evidence tests which were published just last week,  clearly puts the IETF
in a place where it is publishing IP it clearly hasn't completed the
conveyance to, and that its "Email Only" process of transferring IP 
Ownership
doesn't work since the Email cannot be authenticated or proven as reliable
or factual.

By the way - in this matter, which sets the bar-height here,  the Judge Paul
Grimm (A Federal District Magistrate and the Chief Magistrate at that)
specifically threw out a bunch of Emails as unauthenticated and unreliable
as Court Evidence, meaning that the IETF's IP Conveyance process just got
bombed in a US District Court.

http://www.mdd.uscourts.gov/Opinions152/Opinions/Lorraine%20v.%20Markel%20-%20ESIADMISSIBILITY%20OPINION.pdf

This totally sets aside the IETF's Email Only process as unreliable and
failing to meet the Daubert or Frye-Test requirements for its admission as
'expert testimony' as to some digital event.

By the way that this is not coming from Wilmer-Hale is also an issue itself,
eh Jorge?

Gotcha!

Todd Glassey

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 15 May 2007 00:12:13 +0200

John C Klensin wrote:

> if not require, such statements anyway.

Yes, I've used the acknowledgements here as vehicle to make the
permission obvious in an unobtrusive way.

The case I had in mind was the RFC with the SHA code, where it
wasn't obvious for me if that was meant to be "feel free to use
it, we've asked NIST", or if it was meant to be "that's how you
could do it, if you prepare for the required conformance tests
in country A, and you can't do it at all in country B if it's
for a product sold in country A".

> One can even argue that, if Y is not actively participating
> in the IETF, explicit permission is required in many cases:
> without it, a strict reading of our rules prevents X from
> posting the document in the first place, even as an I-D.

Yes, my example was a proposal how to make the existence of an
explicit permission obvious for readers.  Including Y when he
gets a copy of the I-D, giving him the chance to say "wait a
moment, contribution, BCP 78bis, what is this stuff ?  I want
to sell software and thought an I-D is a free marketing venue."

Frank

---

From: John C Klensin <[email-masked]>
Date: Tue, 15 May 2007 01:48:41 -0400

> to sell software and thought an I-D is a free marketing venue."

I think I understood all of that, even though the clarification
/ confirmation was useful.   I was trying to make two other
points:

(i) Using the acknowledgements that way is not a particularly
novel proposal or one that the IPR WG would have to impose as an
innovation on the publication process: the rules today certainly
permit doing what you are suggesting.

(ii) This proposal is somewhat more of the nature of encouraging
an author to supply specific types of information -- information
that might be required under the existing acknowledgement rules
even though those rules are a bit fuzzy-- and where to put it,
rather than a new requirement.

All things being equal, less radical changes make me more happy
and this is definitely not a radical change.

     john

---

From: Don Armstrong <[email-masked]>
Date: Tue, 15 May 2007 01:01:13 -0700

On Mon, 14 May 2007, todd glassey wrote:
> John - I am speaking from simple UCC which clearly says any property
> with a value of more than $500 takes a signature to convey to
> anyone. 

We're not talking about the conveyance of property; we're talking
about the licensing of a work by a copyright holder.

As far as assuring that the copyright holder has actually licensed the
IETF, there are many methods of doing this, but those are the domain
of the inbound rights document, not the outbound rights document.

Don Armstrong

-- 
Certainly the game is rigged. Don't let that stop you. If you don't
bet, you can't win.
 -- Robert Heinlein _Time Enough For Love_ p240

---

From: "todd glassey" <[email-masked]>
Date: Tue, 15 May 2007 07:47:13 -0700

No Don

----- Original Message ----- 
From: "Don Armstrong" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, May 15, 2007 1:01 AM
Subject: Re: Section 6.5: Additional Licenses for IETF Contributions

> about the licensing of a work by a copyright holder.

I disagree. What we are talking about deriviative rights so that the code or 
a derivative copy of it can be used inside a program written by a third 
party. That's part of the Any and All uses clause which is clearly a 
superset of publication rights, or it would say just that "For any and all 
republication purposes and no derivative works"...

> of the inbound rights document, not the outbound rights document.\

Again wrong - the IB Rights Statement also needs to codify how those rights 
are mechancially transferred to the IETF or its Trust Entity and how the 
IETF is assured and made clean from liability in recieving things that those 
submitting them dont own.

---

From: "Bill Fardy" <[email-masked]>
Date: Tue, 15 May 2007 13:40:30 -0400

no todd.

actually, the UCC doesn't 'clearly' say property, it clearly says 'goods'.

i think citing it is noise in this context, though i certainly defer to
jorge.

frankly this subject and this thread is difficutl enough to follow without
interjecting this type of thing, imho.

---

From: "todd glassey" <[email-masked]>
Date: Tue, 15 May 2007 11:34:47 -0700

Bill - interesting response ...

----- Original Message ----- 
From: "Bill Fardy" <[email-masked]>
To: "todd glassey" <[email-masked]>; "Don Armstrong" 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, May 15, 2007 10:40 AM
Subject: Re: Section 6.5: Additional Licenses for IETF Contributions

> actually, the UCC doesn't 'clearly' say property, it clearly says 'goods'.

No it actually it does say property - and it has specific rules for both 
Tanglible Property (aka Goods per your definition) and for Intangible 
Property, i.e. Intellectual Properties, of which interestingly enough SW and 
Copyrighted Documents clearly are.

As such, the transfer of ANY property (tangible or intangible), if its 
valued at more than $500 requires a signature.

>
> i think citing it is noise in this context,

Everyone is entitled to their opinion, but that doesnt make it right - me 
included... unfortunately in this case I am right as far as I can tell. IP 
is Intangible Property who's conveyance is controlled by any number of UCC 
articles and their clauses.

> though i certainly defer to
> jorge.

As would I ...

The questions are SIMPLE...

1)    Is the transfer of IP (as "intangible property"), who's value is more 
than $500 controlled under the UCC by the formal requirement of a signature 
based process? Yes or No...

2)    Would Wilmer-Hale or Jorge as a practicing attorney himself recommend 
to any of its/their other client's that they can formally rely on the IETF's 
IP Transfer Process to protect them from damage claims from third parties?

3)    BY THE WAY - Do your own sponsors agree that the IETF IP Licensing 
Model is strong enough to satisfy their internal Corporate IP Acquisition 
Rules, and if not what else do the Sponsor Entitie's require for their own 
reliance on externally supplied Intellectual Properties... this  is 
important since they are the relying parties of the licensing models that 
the IETF is putting forth here.

> interjecting this type of thing, imho.

You mean without coloring what is a process being designed and voted on by 
Technical People with Legal Requirements as well?

---

From: "todd glassey" <[email-masked]>
Date: Tue, 15 May 2007 11:09:20 -0700

UCC defines GOODS as:

(44) "Goods" means all things that are movable when a security interest 
attaches. The term includes (i) fixtures, (ii) standing timber that is to be 
cut and removed under a conveyance or contract for sale, (iii) the unborn 
young of animals, (iv) crops grown, growing, or to be grown, even if the 
crops are produced on trees, vines, or bushes, and (v) manufactured homes. 
The term also includes a computer program embedded in goods and any 
supporting information provided in connection with a transaction relating to 
the program if (i) the program is associated with the goods in such a manner 
that it customarily is considered part of the goods, or (ii) by becoming the 
owner of the goods, a person acquires a right to use the program in 
connection with the goods. The term does not include a computer program 
embedded in goods that consist solely of the medium in which the program is 
embedded. The term also does not include accounts, chattel paper, commercial 
tort claims, deposit accounts, documents, general intangibles, instruments, 
investment property, letter-of-credit rights, letters of credit, money, or 
oil, gas, or other minerals before extraction.

I suggest that you look these things up... since GOODS are clearly what is 
sent in in the form of "General Intangibles"

---

From: "todd glassey" <[email-masked]>
Date: Tue, 15 May 2007 11:34:47 -0700

----- Original Message ----- 
From: "Bill Fardy" <[email-masked]>
To: "todd glassey" <[email-masked]>; "Don Armstrong" 

As would I ...

---

From: "todd glassey" <[email-masked]>
Date: Tue, 15 May 2007 11:09:20 -0700

UCC defines GOODS as:

---

From: "todd glassey" <[email-masked]>
Date: Tue, 15 May 2007 13:37:22 -0700

Bill - http://www.law.upenn.edu/bll/archives/ulc/ucita/2002final.htm

So UCC does allow for UETA type transactions but those are not one-way 
contracts and are proven by multiple emails between the parties 
acknowledging the requirements for participation and the transfer of 
ownership to the IETF.

Generally speaking no single instance of an email should constitute a 
transaction unless it has something in it that documents:

    "This email is meant to form a contract and convey the license-specified 
rights as indicated to the IETF or its Agents under the Uniform Electronic 
Transaction Act", which none of the submission statement's have today.

But even that is sloppy. Its too easy to force multiple emails from the 
submitter reasserting the submission multiple times which will protect the 
IETF too then one would think. The intent is only that there should be 
follow-up reconfirmations from the IETF Editor's to the Submitter's and in 
this the Submitter should be forced to again assert that they:

A) Hold Legal Title or POA for the entity that actually owns the IP
B) That they are filing this IP with the IETF with the intent of formally 
participating in the IETF's publication/standards process and that all 
parties involved in the submission of the IP agree as such.
C) Formally list all of the involved parties and carbon copy them on the 
emails to allow them to object to the IETF directly (in the interest of 
being upright).
D) Are willing to take the chance that the IETF will not allow their IP to 
foster or create a WG, and that the IP Submission is made with no 
expectation of publication...
E) That the submitter is not aware of any other IP issues pertaining to that 
submission and warrants to the IETF and all who adopt that IP that there are 
no IP constraints of ownership outstanding for that IP.

These would allow for a contract under UETA to be done, and the multiplicity 
of emails back and forth will work for the UETA's signature/agreement 
mechanism requirement.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 17 May 2007 22:18:14 +0200

todd glassey wrote:
 
> http://www.law.upenn.edu/bll/archives/ulc/ucita/2002final.htm

That's apparently an US law or proposed unification of US state
laws.  Does it permit to arrest the complete IETF leadership when
they happen to meet in the Commonwealth of Virginia ?  If not, why
should I care about US laws, there are more than enough EU laws I
need to worry about.

> "This email is meant to form a contract and convey the license-
>  specified rights as indicated to the IETF or its Agents under
>  the Uniform Electronic Transaction Act"

There won't be an RFC recognizing national laws in this form.  The
Trust agreement recognozing the Commonwealth of Virginia is as far
as it gets.  You'd scream if you hear what constitutes a "qualified
signature" in my country, and why you "must" use this for invoices
(by email or unattended fax) related to later tax paying.  Just an
example, let's ignore national laws in this WG.

Frank