Subject: Re: RFC 5378 "contributions"

From: "Contreras, Jorge" <[email-masked]>
Date: Wed, 14 Jan 2009 20:33:35 -0500

No, absolutely not.  Use of pre-5378 materials in the IETF standards process has never been an issue, only use outside the IETF is problematic (ie, allowed under 5378 but not the earlier rules).

----- Original Message -----

From: [email-masked] <[email-masked]>

To: IETF Discussion <[email-masked]>

Sent: Wed Jan 14 19:32:27 2009

Subject: RFC 5378 "contributions"

Hi -

I originally asked this question on the WG chairs' list, and

was asked to ask again here...

The discussion about RFC 5378 (what little I've been able to

understand of it, anyway) has focussed on I-Ds and RFCs.

However, the definition of "contribution" in that document

includes, among other things, mailing list discussions.

Does this mean that we need to get contributor permission

before using, for example, material from a pre-5378 RFC in

a mailing list discussion, or before including text from a

pre-5378 email posting in an internet draft?

This seems really silly, but that's what the discussion is

starting to sound like to me.

Randy

_______________________________________________

Ietf mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 14 Jan 2009 22:52:58 -0500

On Wed, Jan 14, 2009 at 08:33:35PM -0500, Contreras, Jorge wrote:
> No, absolutely not.&nbsp; Use of pre-5378 materials in the IETF standards process has never been an issue, only use outside the IETF is problematic (ie, allowed under 5378 but not the earlier rules).

Why is the actual situation of the use relevant?  "Contribution" is
defined in section 1a of RFC 5378, and it plainly says that mailing
list posting and anything one says at the microphone in any meeting is
included in the definition.  In section 5.1, RFC 5378 says that, by
submitting the Contribution, the Contributor is "deemed to have agreed
that he/she has obtained the necessary permissions" to enter into the
agreement allowing the IETF to use the Contribution according to the
new rules.

So, just because the Contribution doesn't _happen_ to end up in use
outside the IETF by virtue of the IETF's actions does not mean that a
Contributor doesn't have to obtain the rights to allow such re-use.  I
believe that the _intent_ of 5378 is as you say, but the way it is
written does not seem to restrict it in the way you say it does, at
least when I read it as plain English prose.  I'm not qualified to say
whether there are other relevant legal considerations.

Whether there is any practical effect to this state of affairs is
quite another matter, too, of course.  I find it hard to believe that
there'd be a practical consequence; but then, I have found several
actual legal decisions of the past to be hard to believe, too.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 14 Jan 2009 20:03:33 -0800

Hi -

Thanks for the clarification.  Does this mean that if a WG
really has no concern that the documents it's working on would be
spun off to another organization, then it doesn't need to
worry about tracking down "contributors"?

Randy

> From: "Contreras, Jorge" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Sent: Wednesday, January 14, 2009 5:33 PM
> Subject: Re: RFC 5378 "contributions"
>
> Re: RFC 5378 "contributions"No, absolutely not.  Use of pre-5378 materials in the IETF standards process has never been an issue,
only use outside the IETF is problematic (ie, allowed under 5378 but not the earlier rules).

---

From: "Tom.Petch" <[email-masked]>
Date: Thu, 15 Jan 2009 10:00:06 +0100

----- Original Message -----
From: "Andrew Sullivan" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 15, 2009 4:52 AM
Subject: Re: RFC 5378 "contributions"

> > No, absolutely not.&nbsp; Use of pre-5378 materials in the IETF standards
process has never been an issue, only use outside the IETF is problematic (ie,
allowed under 5378 but not the earlier rules).
>
> Why is the actual situation of the use relevant?

Because when an I-D is submitted, the submitter is confirming by the
boiler plates included in the I-D, that they have gotten the relevant
permissions to allow the IETF Trust to exercise the greater powers
that RFC5378 gives them.  So my take is that any substantial
Contribution (as defined) must have the necessary permissions.  Post
November 9th Contributions of any kind were under the new rules, even
if you had yet to be told so.

Tom Petch

"Contribution" is

---

From: Martin Duerst <[email-masked]>
Date: Thu, 15 Jan 2009 19:48:12 +0900

I'm happy with the answer re. use of pre-5378 RFC material
on an IETF mailing list.

I'm not sure about the answer re. use in an Internet-Draft.
With respect to this, I think what Randy wanted to ask is:

Do we need to get contributor premission before using
material from an email posting made under pre-5378
Note Well in an Internet Draft with the full RFC 5378
boiler plate?

Regards,    Martin.

At 10:33 09/01/15, Contreras, Jorge wrote:
>Content-class: urn:content-classes:message
>Content-Type: text/html;charset="utf-8"
>
><https://www.ietf.org/mailman/listinfo/ietf>https://www.ietf.org/mailman/listinfo/ietf

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Thu, 15 Jan 2009 07:09:46 -0500

I have to agree with Andrew and Tom.

If someone stood up in a WG prior to whenever 5378 was
effective* and made a suggestion of some length, or made a
lengthy textual suggestion on a mailing list, and I copied that
suggestion into a draft without any paraphrasing, a plain-sense
reading of 5378's definition of "Contributor" means that I have
to go back, find that person, and get permission to post that
draft today (without a disclaimer), just because, in making the
posting, I'm asserting that rights are in place that were not
granted when the Contribution was made. 

    john

* I've said this several times before, but neither common sense
nor fairness permits the IETF to say "RFC 5378 became effective
when it was published the first week in November, therefore any
comments, contributions or drafts that appeared after that date
constitute grants of permission under 5378's rules" ...
especially in the absence of any specific notice to that effect
on relevant mailing lists, the presence of a Note Well in the
IETF registration packet that referred to the old rules, etc.
Those of us who trust that common sense interpretation (or who
have been given legal advice that the odds of a judge accepting
an early-November date contrary to that interpretation are
fairly small) need to behave as if we cannot assume that
Contributions made before late November or early December do not
imply permission to use the Contributions under 5378 rules.

--On Wednesday, January 14, 2009 22:52 -0500 Andrew Sullivan
<[email-masked]> wrote:

>> No, absolutely not.&nbsp; Use of pre-5378 materials in the
>> IETF standards process has never been an issue, only use
>> outside the IETF is problematic (ie, allowed under 5378 but
>> not the earlier rules).
> 
> "Contribution" is defined in section 1a of RFC 5378, and it
> plainly says that mailing list posting and anything one says
> at the microphone in any meeting is included in the
> definition.  In section 5.1, RFC 5378 says that, by submitting
> the Contribution, the Contributor is "deemed to have agreed
> that he/she has obtained the necessary permissions" to enter
> into the agreement allowing the IETF to use the Contribution
> according to the new rules.
> 
> So, just because the Contribution doesn't _happen_ to end up
> in use outside the IETF by virtue of the IETF's actions does
> not mean that a Contributor doesn't have to obtain the rights
> to allow such re-use.  I believe that the _intent_ of 5378 is
>...

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 15 Jan 2009 08:24:08 -0500

> suggestion into a draft without any paraphrasing, a plain-sense

John, I am not a lawyer, you are (AFAIK) not a lawyer, and if the IETF  
counsel
says otherwise, I would just let this one lie.

The reason why I do not agree with this reasoning is that these rights  
are
claimed through authorship. If I do not claim authorship in your draft
because you use my text, when I have ample opportunity to do so, then  
I have (in my opinion)
effectively lost them, especially in this context (where there is a  
note well,
an assumption of joint contributions, etc.).

In another context, I know that this is why songwriters
can be so vociferous about getting their name as co-authors when a
song is published - that is how they get royalties.

Yes, I am sure that there are corner cases here, but one thing
I have found about legal affairs is that there are always corner cases.
No legal matter is ever sewn up 100%, and judges actually do take into
consideration when things are done "on advise of counsel." We have it,  
we should use it.

Regards
Marshall

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 15 Jan 2009 09:19:28 -0500

On Thu, Jan 15, 2009 at 08:24:08AM -0500, Marshall Eubanks wrote:
>
> The reason why I do not agree with this reasoning is that these
> rights are claimed through authorship.

That claim is precisely what I think is false, because RFC 5378 has
defined "Contributor" in a particular way, and then asserted that
there are certain terms to which Contributors are deemed to have
agreed by virtue of making a Contribution.  That a Contributor fails to
assert some claim under those conditions seems irrelevant to me.

That said, I completely agree that geeks playing at law is a nasty
sight (I am tempted to think that it's how we got into this mess).  I
don't personally feel comfortable taking the say-so of the IETF Trust
counsel, though, since the IETF Trust is an interested party in this
discussion.

A

---

From: Theodore Tso <[email-masked]>
Date: Thu, 15 Jan 2009 09:29:29 -0500

On Thu, Jan 15, 2009 at 08:24:08AM -0500, Marshall Eubanks wrote:
> John, I am not a lawyer, you are (AFAIK) not a lawyer, and if the
> IETF counsel says otherwise, I would just let this one lie.
>
> rights are claimed through authorship. If I do not claim authorship
> in your draft because you use my text, when I have ample opportunity
> to do so, then I have (in my opinion) effectively lost them,
> especially in this context (where there is a note well, an
> assumption of joint contributions, etc.).

So it's a problem if every single I-D and RFC author is going to have
to consult their own counsel before deciding that won't get into legal
trouble when guaranteeing that all of their text is appropriately
licensed.

So whether or not I am I lawyer, and whether or not the Berne
Convention very clearly states that copyright rights are automatically
enforced, and do not need to be explicitly claimed, and whether or not
the Note Well is enough to override the Berne Convention, John's
position that he wants to be conservative enough not to make
guarantees that might expose him to legal liability is a reasonable one.

I don't think it's fair to say, "I'm not a lawyer, and you're not a
lawyer" so you should do something which you fear exposes you to legal
risk --- especially when all of the IP training many of us have gotten
have basically told us that the Berne Convention explicitly states
that you don't have to claim copyright to get copyright protections....

> consideration when things are done "on advise of counsel." We have it,  

Has the IETF Counsel actually given explicit legal advice to all IETF
contributors (which would have legal liability implications for the
IETF Trust if said advice was wrong, as I understand things) that the
Note Well to guarantee the transfer of RFC 5378 rights for text taken
from IETF mailing list discussions or at an IETF meeting?  

Better yet would be if the IETF Trust was willing to ***indemnify***
I-D and RFC authors that they are on firm legal ground for asserting
that they have all RFC 5378 rights when they take text from an IETF
mailing list discussion or IETF face-to-face meeting, on the basis of
the Note Well.  After all, it is the IETF Trust which is requiring I-D
and RFC authors to make this legal guarantee, so one might assert that
in a fair world they should take the legal risks associated with that
guarantee.

						- Ted

---

From: Theodore Tso <[email-masked]>
Date: Thu, 15 Jan 2009 09:38:42 -0500

More to the point, the question at hand was to what happens to mailing
list discussions (or face to face discussions) which took place
*before* RFC 5378 was published.  John's observation was that it
doesn't matter when the I-D or RFC is published, even if it is
published *after* RFC 5378, if it contains text that was derived
*before* RFC 5378, regardless of whether it came from an RFC, I-D,
mailing list discussion, or face-to-face discussion, the RFC 5378
rights that a Contributor might provide wouldn't exist.

       	      		  		- Ted

---

From: "Contreras, Jorge" <[email-masked]>
Date: Thu, 15 Jan 2009 10:08:09 -0500

All -- It's been pointed out to me that I may have been answering the
wrong question, or at least only a subset of the full question, in my
posting of last night, so I'll clarify below in some detail.

But first, for those whom I haven't met before, you should know that I'm
a lawyer -- the lawyer who has been advising the Trust on these issues.
I did help produce the work-around proposal that Ed circulated last
week, and am also one of the co-authors of RFC 5378, so I take some of
the blame for starting this whole mess in the first place.  This being
said, I'm not putting forward an "official" position of the Trust, nor
has the below message been vetted by the Trust.  It's simply my attempt
to clarify my earlier response, which someone (not a Trustee) suggested
that I send.

1.  It's correct that "Contribution", as defined in RFC 5378, includes
e-mail exchanges, oral discussions and any other contribution to the
IETF process.  This definition has existed since RFC 3978 and the Note
Well that has been published for the past several years.  5378 did not
make a change here.

2.  Therefor, the same rules that apply to I-D submission also apply to
the other, less formal, types of contributions.  John and others are
correct in drawing this conclusion.

3.  The IETF (meaning the collective activity of participants who
interact on standards-development activities under the aegis of the
IETF) has a perpetual, irrevocable right to use all Contributions in the
IETF Standards Process.  This right applies to all IETF Contributions,
whether made under the rules in existence under 5378, 3978, 2026 or
earlier.  That was my response to Randy Presuhn last evening.

4.  However, various people have identified a bug in 5378 that relates
to "hybrid" Contributions -- those that contain both pre-5378 and
post-5378 material.  In short, contributors can't assure the Trust that
pre-5378 contributions meet all the requirements of 5378.

5.  The Trust's proposed work-around deals with this issue by allowing
Contributors to flag hybrid contributions.  If the flag is in place,
then licenses outside the IETF Standards Process are not allowed, and
the set of rights being granted for the pre-5378 and post-5378 material
becomes equivalent (i.e., full use within the IETF Standards Process,
plus a couple of other rights for code, etc.)  As a result, if the flag
is in place for a Contribution, the Contributor can make the warranties
required by 5378 without worrying about any violation with respect to
the included pre-5378 material.

6.  While this flagging approach seems to be workable (from what I've
heard) for I-Ds and other "formal" contributions, it would not be easy
to manage for less formal contributions, such as e-mails and especially
oral statements.  That's the issue that John, Theodore and others have
been elaborating recently, and I do agree.

7.  Unfortunately, the Trust's ability to affect 5378 is limited to the
inclusion (and tweaking) of the legends that are included in I-Ds and
other written documents.  5378 does not give the Trust a broader power
to alter the rights granted under 5378 or the warranties required by
5378.  Thus, the proposed workaround, with the flag applied to submitted
I-Ds, is probably as far as the Trust can go at this point (though I'm
open to suggestions).

8.  Ultimately, a fix is needed to 5378.  But, in the interim, I was
hoping that the proposed work-around would enable *most* IETF work to
continue, and also hope that, while technically correct, the possibility
of someone being sued for breaching a warranty with respect to an oral
statement made at an IETF meeting is a very remote risk that would not
inhibit IETF work.

9.  This being said, I do agree that a permanent solution to fix 5378 is
needed soon.  This solution should address both formal and less formal
types of Contributions, and, as Fred Baker and others have urged,
require a minimum of effort on the part of IETF contributors. 

Thanks,
Jorge Contreras

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of John C Klensin
> Sent: Thursday, January 15, 2009 7:10 AM
> To: Andrew Sullivan; [email-masked]

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 15 Jan 2009 11:50:46 -0500

> trouble when guaranteeing that all of their text is appropriately

This is an IETF list, to discuss matters of relevance to the IETF.  
Whether or
not you need to consult counsel is not really on topic, and for sure  
you should not
make that decision based on what anyone (especially me!) says on this  
list.

If, on the other hand, you do obtain advice of counsel on this matter  
I would be curious to
learn what they say.

> in a fair world they should take the legal risks associated with that

Consider the threat model here.

This threat applies ONLY to material that the Trust licenses to third  
parties (such as, say,
the IEEE) for inclusion and modification in their standards. (Just  
reprinting or translating an RFC is not at issue.)

Suppose that you author an RFC today, and use pre-5378 material, and  
warrant (in good faith) that the Trust has a license for that  
material, or apply a legend from the Trust that says that these rights  
are not obtainable by you, and it happens that the original author of  
that earlier material disagrees with this license to a third party.  
Note that these earlier author's (and their companies) agreed to  
freely use this material in the IETF process (the note well, etc.),  
and so you have no risk just by publishing the RFC as long as it is  
not licensed to other parties.

The Trust would be the party that would be licensing this material to  
third parties, so clearly
the Trust would be the major party at risk. What is your risk ?

There is a theoretical risk that the Trust might sue you. That is one  
thing that the work-around is intended to remove.

There is an actual risk that a third party might sue you and the Trust  
- specifically, that the original author or their heirs, etc.,  might  
sue. They can only do this if there is infringing use, and that would  
have to be based on a license from the Trust.

If the Trust does NOT license your material to third parties, then  
there is no infringement, no one with standing to sue, and no risk to  
authors. It may be necessary for the Trust to state that they will not  
assume 5378 to be in place for this purpose until there is a  
replacement. (In that case, if the IEEE or some other body wants to  
take over an RFC and modify it, they will have to get explicit  
permission from all authors until there is a replacement for 5378 in  
place, just as they did before 5378 as put into place.) My  
understanding is that the Trust is responsible for these licenses, and  
so they could just (in their best judgement) refuse to issue them  
without further conditions.

These requests are very infrequent (less than 1 RFC per year is my  
understanding) and doing this would NOT stop the work of the IETF. I  
am beginning to feel that this may be a necessary step.

What about going forward ? Should we (the IETF, through the Trust)  
indemnify authors ?

Indemnification in practice translates to insurance. The Trust has  
insurance for its activities.
I personally think it would be wise for the Trust to investigate  
whether it could obtain insurance
for all authors _of materials licensed to others_ (post 5378 or post  
some later RFC), what it would cost, and whether the insurers would  
want changes in our procedures. (I would feel more comfortable if we  
just learned that
our processes were insurable, even if we did not actually get  
insurance.)

Given that the Trust is insured for its handling of ALL IETF work, and  
this extra insurance would be for maybe 1 RFC per year, the cost to do  
this might be very reasonable. I don't know, but I would urge the  
Trust to find out.

Or (and this is my opinion), maybe the authors should only warrant  
_their work_ as being subject to such licenses, and put the burden on  
the Trust to obtain any necessary approvals from other parties, only  
alerting the Trust to the extent they know of such prior authorship.  
My understanding is that this would require a 5378bis.

Again, please note that I am trying to discuss what the Trust and the  
IETF should do, not what you or other individuals should do.

Regards
Marshall

---

From: TSG <[email-masked]>
Date: Thu, 15 Jan 2009 09:10:33 -0800

> insurance for its activities.
I dont believe that is true. Since those policies would continuously 
have to be reviewed by the Underwriter every time anything under the 
trust changed.

http://www.products-liability-insurance.com/abatement-defense-qa.php

See also

http://www.premier-source.com/ip-defense-insurance

The problem the IETF faces is that its "current IP intake processes" probably will not be insurable IMHO based on the refusal to put proper contractual conveyance processes and the proper mandatory disclosure requirement's in place. 

> just learned that our processes were insurable, even if we did not 
> actually get insurance.)
Sure - this is about ownership issues. There is insurance available for 
perfecting ownership rights. Its pretty expensive these days. And again 
since the IETF's IP staff refuses to perform those Risk Analysis which 
come with the creation of use process models for the IP it codifies, 
every time something changes in the operations of the Trust, the 
underwriting will have to be redone.

Personally I figure litigation against the IETF to run in the $300k to 
$500K region based on the number of people who would fight back to try 
and cover up the various frauds and  damages their employee's possibly 
were directly and indirectly involved with inside the IETF. The problem 
is that for each RFC published there would be a need to insure it's 
submission to the trust meaning we are looking at several hundred 
thousand dollars PER RFC or I-D filed with the Publishing Desk of the 
IETF's Trust.

> this might be very reasonable. I don't know, but I would urge the 
So then the Trust and its officers are NOT insured for anything now 
right? That means they and their sponsors bear all financial 
responsibilities for IP Damage to the owners of IP which is wrongly 
submitted to the IETF.  A submission without perfecting the Ownership 
cannot convey actual title to that IP to the trust... and that is the 
issue here I think.

> ------------------------------------------------------------------------
>
>
> Internal Virus Database is out of date.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.176 / Virus Database: 270.10.4/1880 - Release Date: 1/7/2009 8:49 AM
>
>

---

From: TSG <[email-masked]>
Date: Thu, 15 Jan 2009 09:34:16 -0800

> granted when the Contribution was made. 
Correct.

---

From: TSG <[email-masked]>
Date: Thu, 15 Jan 2009 09:53:14 -0800

> Well that has been published for the past several years.  5378 did not
Unfortunately that means that participation from anyone who's corporate 
policy is that the corporation owns the IP moving through their email 
gateway makes the individuals assertion of those rights subject to that 
oversight and as such the conveyance model is flawed and ineffective.
> correct in drawing this conclusion.
yeah, but only because the IETF's process makes criminals out of those 
who fraudulently assert they have and continue to have power of attorney 
for their sponsors  when in fact most all of them don't.
> IETF Standards Process.  
The scope of that changed and the actual terminology changed with these 
documents and since the IETF refused to force its submitters to prove 
that they actually do own those rights when 99% of the corporate 
sponsors have formally filed notices with their SOX compliance processes 
that there are no external contracts which effect their employees and no 
external contracts which effect their IP operations.
> This right applies to all IETF Contributions,
Hmmm... ONLY if the party submitting that IP has the legal authority to 
convey its ownership or to license it to the IETF. If the party working 
within the IETF doesnt have those rights then the IETF becomes a 
co-conspirator after the fact to a RICO violation one would think.
> pre-5378 contributions meet all the requirements of 5378.
The same is true of revisions to existing documents when the submission 
conveyance process changed too.
> the included pre-5378 material.
Again - this doesn't make sense to me.  Pre-licensed works are still 
licensed under those terms whether the IETF changes those participation 
rules or not.
> require a minimum of effort on the part of IETF contributors. 

I suggest that the creation of imperfect licnsing because of these 5378 
flaws is incompetent and as such 5378 and any other imperfect process 
document be suspended until such time as those issues can be addressed.

Todd Glassey

---

From: Theodore Tso <[email-masked]>
Date: Thu, 15 Jan 2009 19:23:14 -0500

On Thu, Jan 15, 2009 at 11:50:46AM -0500, Marshall Eubanks wrote:
> This threat applies ONLY to material that the Trust licenses to
> third parties (such as, say, the IEEE) for inclusion and
> modification in their standards. (Just reprinting or translating an
> RFC is not at issue.)

So this licensing to third parties is not automatic; which makes sense
in terms of letting the IESG to have a control point before allowing
another standards body to take over a standard (or try to take over a
standard).

However, that presumably wouldn't be tree for allowing text or code to
be used in implementations, open source or otherwise --- I assume
that wouldn't require prior permission first, right?

> If the Trust does NOT license your material to third parties, then there 
> is no infringement, no one with standing to sue, and no risk to authors. 
> It may be necessary for the Trust to state that they will not assume 5378 
> to be in place for this purpose until there is a replacement. (In that 
> case, if the IEEE or some other body wants to take over an RFC and modify 
> it, they will have to get explicit permission from all authors until 
> there is a replacement for 5378 in place, just as they did before 5378 as 
> put into place.) My understanding is that the Trust is responsible for 
> these licenses, and so they could just (in their best judgement) refuse 
> to issue them without further conditions.

So there probably isn't much risk for a standards bodies wanting to
take over a MIB, for example, But what about someone using pseudo-code
from a RFC where the RFC editor is required to make an assertion that
he/she had all of the rights, and the code or pseudo code was
contributed by a third party who copied the code from some Microsoft
source they had access to while they were a graduate student?   

> alerting the Trust to the extent they know of such prior authorship. My 
> understanding is that this would require a 5378bis.

That I think is the key; each person can only warrant what they
themselves have authored.  Something that might be worth looking at is
the Developer's Certification of Origin, which is how Linux Kernel
developers deal with contributions for the Linux Kernel.  Anything
which gets incoproated into the kernel must have a Signed-off-by, like
this:

Signed-off-by: "Theodore Ts'o" <[email-masked]>

What this mean is an explicit assertion of the following:

	Developer's Certificate of Origin 1.1

	By making a contribution to this project, I certify that:

        (a) The contribution was created in whole or in part by me and I
            have the right to submit it under the open source license
            indicated in the file; or

        (b) The contribution is based upon previous work that, to the best
            of my knowledge, is covered under an appropriate open source
            license and I have the right under that license to submit that
            work with modifications, whether created in whole or in part
            by me, under the same open source license (unless I am
            permitted to submit under a different license), as indicated
            in the file; or

        (c) The contribution was provided directly to me by some other
            person who certified (a), (b) or (c) and I have not modified
            it.

	(d) I understand and agree that this project and the contribution
	    are public and that a record of the contribution (including all
	    personal information I submit with it, including my sign-off) is
	    maintained indefinitely and may be redistributed consistent with
	    this project or the open source license(s) involved.

This would obviously have to be modified for the IETF's purpose, but
what's nice about it is that each Linux Kernel Developer is only
making assertions about things which he or she has personally has
control over, and by using the Signed-off-by chain, it's possible to
see the handoffs as the patch was passed up the chain from one
developer to another, i.e:

commit 166348dd37a4baacfb6fe495954b56f56b116f0c
Author: Aneesh Kumar K.V <[email-masked]>
Date:   Mon Sep 8 23:08:40 2008 -0400

    ext4: Don't add the inode to journal handle until after the block is allocated
    
    Make sure we don't add the inode to the journal handle until after the
    block allocation, so that a journal commit will not include the inode in
    case of block allocation failure.
    
    Signed-off-by: Aneesh Kumar K.V <[email-masked]>
    Signed-off-by: Mingming Cao <[email-masked]>
    Signed-off-by: "Theodore Ts'o" <[email-masked]>

						- Ted

---

From: "Doug Ewell" <[email-masked]>
Date: Thu, 15 Jan 2009 07:44:28 -0700

> trouble when guaranteeing that all of their text is appropriately 

I certainly won't be volunteering to edit any more I-Ds after 
draft-ietf-ltru-4645bis if I have to worry about my personal legal 
liability if someone in the Working Group who contributed text has not 
granted me sufficient IP rights.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 16 Jan 2009 10:54:01 +0100

> that wouldn't require prior permission first, right?

Right, but only for code.  See section 4 of
<http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf>.  The
copyright header used in the BSD license will typically be incorrect
(and the text in the PDF was modified after the trust approved the
document, which makes the version available on the web dubious from a
legal perspective) but otherwise, and as far as I can tell, the section
grants sufficient rights for free software packages to use code from
RFCs.  It would be useful if you and others in the free software
community reviewed that more thoroughly though.

> developers deal with contributions for the Linux Kernel.

Agreed.  The GNU project has used a similar approach for a long time.
In many ways, the atmosphere in the IPR WG was to not review and learn
from others' mistakes in this area.  I think this is one area where we
could have done better.

/Simon

---

From: "Tom.Petch" <[email-masked]>
Date: Fri, 16 Jan 2009 10:54:36 +0100

----- Original Message -----
From: "Theodore Tso" <[email-masked]>
Sent: Friday, January 16, 2009 1:23 AM

> another standards body to take over a standard (or try to take over a

Well, no. To me, RFC5378 asks that future Contributions include an unrestricted
right to produce derivative works (previously restricted to within the IETF)
which right is given to the IETF Trust.  RFC5377 guides the IETF Trust as to
when this right should be given to third parties but it is the IETF Trust that
decides.  I see no role for the IESG.  We have put our trust in the IETF Trust,
to produce legends and to exercise grants; that is what I see us as having
signed up to when we endorsed RFC5377.

eg s.3 "the legal authority for determining and granting users
   rights to copy material in RFCs and other IETF Contributions rests
   with the Trustees for the IETF Trust"

Tom Petch

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 16 Jan 2009 06:29:46 -0500

On Jan 16, 2009, at 4:54 AM, Tom.Petch wrote:

> decides.  I see no role for the IESG.

Note that the IETF Trustees include (RFC4071)

o  One member appointed by the IESG;
o The IETF Chair (ex officio);
so the Trust certainly has a IESG representation.

Regards
Marshall

is IETF Chair

> We have put our trust in the IETF Trust,
>>> there
>>    ext4: Don't add the inode to journal handle until after the  
>> block is
> allocated
>>

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 16 Jan 2009 07:04:13 -0500

> source they had access to while they were a graduate student?

You are absolutely correct here IMO. This is a different threat model,  
and
it seems to me that care has to be taken that no code is published  
open source post 5378 that
is not cleared. Possible solutions to this due diligence problem might  
include

- an automatic search of the RFC archive to see if code being published
is present in an earlier incarnation.

- the ability to _quote_ code from earlier text with a note saying  
that it might be not open source if it
is from an earlier RFC (would this require a 5378bis ?).

This raises a question. The IETF publishes relatively little code  
compared to the millions of
lines of open source code out there. How do the large open source  
projects protect and
indemnify themselves and their participants in case someone takes some  
code they don't own,
post it to a CVS, and it winds up in (say) the Linux kernel ?

Regards
Marshall

---

From: Theodore Tso <[email-masked]>
Date: Fri, 16 Jan 2009 10:01:50 -0500

On Fri, Jan 16, 2009 at 07:04:13AM -0500, Marshall Eubanks wrote:
> compared to the millions of lines of open source code out there. How
> do the large open source projects protect and indemnify themselves
> and their participants in case someone takes some code they don't
> own, post it to a CVS, and it winds up in (say) the Linux kernel ?

For the Linux Kernel, we use the Developer's Certification of Origin
system, which was the Signed-off-by: headers I demonstrated.  There
are also code-scanning tools available at sites such as Fossology.org
(a working group of the Linux Foundation).  A lot of this will be
noticed by humans doing code review; for example, Microsoft code
usually decorates its variables using Hungarian Notation (i.e.,
szName), and most OSS projects don't use that coding convention, so
code which looks horrible and/or causes unpleasant flashbacks will
raise red flags.  :-)

That being said, this is a problem which common to proprorietary
software as well as open source software.  More than once, I have been
contacted by companies doing due-diligence before, during, and after a
corporate acquisition, when they had found copies of GPL'ed code which
I had authored, complete with my copyright statement and "This code
may only be copied under the terms of the GNU Public License"...  in
proprietary code that was shipped as product by the company that had
just been acquired.  Yes, there *are* programmers that clueless out
their writing code for proprietary software companies....

						- Ted

---

From: SM <[email-masked]>
Date: Fri, 16 Jan 2009 07:37:48 -0800

>developers deal with contributions for the Linux Kernel.  Anything

First, we get authors to certify their works.  Then we get 
contributors (see Note Well) to certify their contributions.  If we 
take that one step further, the IETF will be able to establish formal 
membership.

>which gets incoproated into the kernel must have a Signed-off-by, like

The IETF does not use version control to keep track of changes to a 
document.  Document changes cannot be compared to code contributions 
as the process is different.  Historically, the process of getting 
from idea to RFC has been informal.  "Official" communication is 
usually done through email.  Those messages aren't even signed with 
S/MIME or PGP.

There was a time when it was easy to make a contribution to the IETF 
and when we could tap into the large pool of published knowledge and 
build upon it.  In my opinion, copyright was relatively 
straight-forward if one was operating within the Standards 
Process.  Now, I need to hire a lawyer before asserting anything.

Regards,
-sm

P.S. I share the blame because of the comments I posted to the IPR WG.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 16 Jan 2009 17:34:43 +0100

SM <[email-masked]> writes:

> document.

Version control is not needed to track changes.

> Document changes cannot be compared to code contributions as the
> process is different.

I disagree.  Plenty of technical protocol documents, similar to RFCs,
are maintained by free software projects.

> Historically, the process of getting from idea to RFC has been
> informal.  "Official" communication is usually done through email.
> Those messages aren't even signed with S/MIME or PGP.

Neither are contributions to free software projects in general, but it
does not matter.

I believe the IETF community has much to learn from the free software
community when it comes to legal arrangements.  The end product (a
community influenced document) is similar and the rules around legally
protecting each contributor are also similar.  The IETF could require
that contributors license their contributions under, if you want a short
license, the BSD license, or, if you want a longer license text that
allows for non-modifiable portions (which some people appear to think is
necessary), the GFDL.  I proposed this model to think of code and text
the same to the IPR WG, but could not gather sufficient people to agree
with the idea.

/Simon

---

From: "Tom.Petch" <[email-masked]>
Date: Tue, 20 Jan 2009 15:20:20 +0100

<snip>
> the same to the IPR WG, but could not gather sufficient people to agree

Precisely; that is how the IETF works, gain rough consensus or your proposal
will not be accepted.  Having been not accepted in the IPR working group, I
see what I think is you (and others) trying to end run the WG's work and gain
rough consensus on the main list:-)

Underlying this, I believe that if only the IPR WG had not had to spend so
much time discussing and re-discussing and re-re-discussing ... this issue, then
may be, just may be, we would have had more time to focus
on the transition arrangements that we identified the need for in RFC5377 s.3.
In which case, this thread and all the other related ones would never have
occurred.

So, in all seriousness, I do see this re-raising of this issue, by you and
others, as impeding our ability to solve the problem that most needs solving,
that of
moving forward to a world where our Contributions do contain greater rights to
allow derivative works.  Which, ironically, is a prerequisite for what you want.

Tom Petch

---

From: John C Klensin <[email-masked]>
Date: Wed, 21 Jan 2009 09:23:13 -0500

--On Tuesday, January 20, 2009 15:20 +0100 "Tom.Petch"
<[email-masked]> wrote:

>...
> Underlying this, I believe that if only the IPR WG had not had
> to spend so much time discussing and re-discussing and
> re-re-discussing ... this issue, then may be, just may be, we
> would have had more time to focus on the transition
> arrangements that we identified the need for in RFC5377 s.3.
> In which case, this thread and all the other related ones
> would never have occurred.
> 
> So, in all seriousness, I do see this re-raising of this
> issue, by you and others, as impeding our ability to solve the
> problem that most needs solving, that of
> moving forward to a world where our Contributions do contain
> greater rights to allow derivative works.  Which, ironically,
> is a prerequisite for what you want.

---

From: Theodore Tso <[email-masked]>
Date: Wed, 21 Jan 2009 09:44:51 -0500

> 
> Underlying this, I believe that if only the IPR WG had not had to
> spend so much time discussing and re-discussing and re-re-discussing
> ... this issue, then may be, just may be, we would have had more
> time to focus on the transition arrangements that we identified the
> need for in RFC5377 s.3.  In which case, this thread and all the
> other related ones would never have occurred.

So I wasn't on the IPR working group, but it seems to me that there
are two separable issues.  There is the question of *which* license to
use for contributions (which might or might not vary based on type of
contribution, i.e., text vs. code), and then there is the question of
whether we are sticking the entire legal liability and respponsibility
onto the I-D editors/authors to guarantee/warant that the entire
document can be released under the the new licensing requirements, and
that relates quite strongly to the transition issue.

Was that second issue discussed by the IPR wg?

    	 	      		       	   - Ted

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 21 Jan 2009 16:19:08 +0100

> On Tue, Jan 20, 2009 at 03:20:20PM +0100, Tom.Petch wrote:
>> 

The discussions weren't framed under topics like that, but I don't
recall extensive discussions on the liability aspect.

However, the theme were present in several discussions about simplifying
the procedures.  One link (but probably not the best one) would be:

http://thread.gmane.org/gmane.ietf.ipr/3738

Implicit in that argument is that contributors release their own
contribution under a license, and do not vouch for anyone else's
contribution, and that others can re-use the material under that
license.  This is the normal procedure in the free software community.

What we are seeing now is, I believe, one instance of what John referred
to in that thread as (paraphrasing liberally) perpetually fixing yet
another corner case.  Unfortunately but not surprisingly, people appears
to react to the current problem by searching for the simplest quick-fix.

/Simon

---

From: Theodore Tso <[email-masked]>
Date: Wed, 21 Jan 2009 12:10:52 -0500

> license.  This is the normal procedure in the free software community.

Um, I just looked at that thread, and it was talking more about
whether or not SDO's should be allowed to "fork" an RFC specification
without getting prior permission from the IETF or not, and worries
about "fake" RFC's.  That has nothing to do with shoving all of the
liabilities associating with assuring that all contributions following
the IPR responsibilities onto the I-D author/editors.

Maybe you thought it was implicit in the argument, but it certainly
wasn't obvious to me.  So if your goal was to advance that point of
view, it probably wasn't the best strategy as an advocate.

Regards,

						- Ted

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 21 Jan 2009 21:56:56 +0100

> On Wed, Jan 21, 2009 at 04:19:08PM +0100, Simon Josefsson wrote:
>> 

I didn't mean to imply that I were aware of the transition issue at the
time.  Sorry for the confusion.  My point was to suggest that we reduce
complexity and re-use something that has been proven to work for many
years.  The current problem appear to stem from a complex solution and
too little review.

/Simon

---

From: TSG <[email-masked]>
Date: Fri, 23 Jan 2009 12:12:52 -0800

>
> No, absolutely not.  Use of pre-5378 materials in the IETF standards 
> process has never been an issue, only use outside the IETF is 
> problematic (ie, allowed under 5378 but not the earlier rules).
>
Jorge - if the contributor's in a RC2026 controlled submission choose 
NOT to allow the new licensing models, then you are saying that the 
IETF's new rules apply?

If not specifically - which rules would apply. The point is that 
contracts require that the people being bound by them fully understand 
the terms and conditions, and if they don't then their gifts are faulty 
at best.

Is this or is it not true - and if not why Counsel

Todd Glassey

---

From: "Tom.Petch" <[email-masked]>
Date: Fri, 23 Jan 2009 21:50:08 +0100

----- Original Message -----
From: "Theodore Tso" <[email-masked]>
To: "Tom.Petch" <[email-masked]>
Cc: "Simon Josefsson" <[email-masked]>; <[email-masked]>
Sent: Wednesday, January 21, 2009 3:44 PM
Subject: Re: RFC 5378 "contributions"
> contribution, i.e., text vs. code),

To quote Harald quoting Counsel 15 Mar 07
"1 - The legal theory the IETF operates under is that people who contribute
to the IETF process know they are doing so.
....
2 - There is no legal requirement for ANY boilerplate to appear in a
contribution to the IETF. This includes internet-drafts."

so the boiler plate is there ... well, at the behest of the IETF Trust; it is
the contents
of the Note Wells and the referenced BCP that matter more.

> and then there is the question of
and the BCP says
" By submission of a Contribution, each person actually submitting the
   Contribution and each named co-Contributor is deemed to have read and
   understood the rules and requirements set forth in this document."

which are (inter alia) to grant derivative rights; and also,

"With respect to each Contribution, each Contributor represents that,
   to the best of his or her knowledge and ability:
   a. The Contribution properly acknowledges all Contributors, including
      Indirect Contributors."

so the way I see it, a Contribution (eg an I-D) should acknowledge all relevant
people, ensure all names are there.  If that name is of a person within the IETF
process, then I think that grant may now be presumed.  If not, then it must be
sought.
> Was that second issue discussed by the IPR wg?

In terms of Contributions and Contributors, yes; it is Contributions and
Contributors that formed the taxa of the IPR WG (eg, 26 Nov 2007, 'issue #1515'
and around there, but especially Brian Carpenter's post to 'ISSUE Incoming
5.6').  Editors and authors, well they appeared, but I saw that as something of
an aberration.

Tom Petch