Harald Alvestrand | 3 Jan 09:35
Picon

Decisions from San Diego confirmed for next version of drafts

Given that of the decisions reported from San Diego, only #1400 was 
raised as an issue by more than one person, and that poll showed a 
preponderance of opinion for the San Diego consensus, the chairs have 
asked the document editors to proceed with preparing new drafts based on 
the San Diego decisions.

Once the new draft of -outbound is ready, we will continue with the 
beating of issues into shape.

                     Harald, for the chairs
Brian E Carpenter | 15 Jan 17:35
Picon
Favicon

Re: IETF Trust FAQ

Switched to a more relevant list, where this horse has
been thoroughly flogged already:

On 2007-01-15 16:49, Simon Josefsson wrote:
> Brian E Carpenter <brc <at> zurich.ibm.com> writes:
> 
>> I would refer you to the IETF Trust FAQ on RFC copyright,
>> http://trustee.ietf.org/24.html, point 6 and point 9.
> 
> Interesting.  Point 6 seem incorrect to me, as there is nothing in BCP
> 78 that permits computer code extracts from RFC for third parties. 

Wrong. The parenthesis "(and not limited to use within the IETF Standards
Process)" in BCP 78 does exactly that.

> I
> believe the IPR WG has established that point.  

You may believe that, but our lawyer doesn't.

> Point 9 seem
> irrelevant since the IETF Trust doesn't (by point 1) own the copyright
> on code in RFCs.

Point 9 means what it says. When combined with the parenthesis
quoted above, it's highly relevant.

> 
> I think the FAQ should be updated to reflect the perception of the
> problem being solved by the IPR WG.  
(Continue reading)

Simon Josefsson | 15 Jan 18:07
Favicon
Gravatar

Re: IETF Trust FAQ

Brian E Carpenter <brc <at> zurich.ibm.com> writes:

> Switched to a more relevant list, where this horse has
> been thoroughly flogged already:
>
> On 2007-01-15 16:49, Simon Josefsson wrote:
>> Brian E Carpenter <brc <at> zurich.ibm.com> writes:
>>
>>> I would refer you to the IETF Trust FAQ on RFC copyright,
>>> http://trustee.ietf.org/24.html, point 6 and point 9.
>>
>> Interesting.  Point 6 seem incorrect to me, as there is nothing in BCP
>> 78 that permits computer code extracts from RFC for third parties. 
>
> Wrong. The parenthesis "(and not limited to use within the IETF Standards
> Process)" in BCP 78 does exactly that.

I disagree.  Let's take a look at the license:

   a. To the extent that a Contribution or any portion thereof is
      protected by copyright and other rights of authorship, the
      Contributor, and each named co-Contributor, and the organization
      he or she represents or is sponsored by (if any) grant a
      perpetual, irrevocable, non-exclusive, royalty-free, world-wide
      right and license to the ISOC and the IETF under all intellectual
                        ------------------------
      property rights in the Contribution:
...
      (E) to extract, copy, publish, display, distribute, modify and
          incorporate into other works, for any purpose (and not limited
(Continue reading)

Simon Josefsson | 15 Jan 19:11
Favicon
Gravatar

Re: IETF Trust FAQ

Brian E Carpenter <brc <at> zurich.ibm.com> writes:

> Switched to a more relevant list, where this horse has
> been thoroughly flogged already:

Btw, to move closer to a settling the issue, it would be useful to add
more information to the issue tracker:

https://rt.psg.com/Ticket/Display.html?id=1339

Relevant information would include statements by Scott Bradner:

http://tools.ietf.org/html/draft-bradner-rfc-extracts-00

   "Section 3.3(a)(E) of RFC 3667 [RFC 3667] requires that the author(s)
   of IETF contributions grant the IETF the right to make and use
   certain types of extracts of the contributions for purposes not
   limited to the IETF standards process.  When I wrote that section I
   intended that to mean that anyone could make such extracts but the
   wording I used limited the permission to the IETF.  This document
   tries to fix the words to match my intent."

That confirm that I interpret the wordings of RFC 3978 the same as
Scott Bradner.  I agree that the intention wasn't the same as the
wording, and that we should fix that.

Debian interpret the BCP 78 license as non-free:

http://release.debian.org/removing-non-free-documentation
http://bugs.debian.org/199810
(Continue reading)

The IESG | 15 Jan 22:30
Picon
Favicon

Protocol Action: 'Clarification of the 3rd Party Disclosure procedure in RFC 3979' to BCP

The IESG has approved the following document:

- 'Clarification of the 3rd Party Disclosure procedure in RFC 3979 '
   <draft-narten-ipr-3979-3rd-party-fix-00.txt> as a BCP

This document is the product of the Intellectual Property Rights Working 
Group. 

The IESG contact person is Brian Carpenter.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-narten-ipr-3979-3rd-party-fix-00.txt

Technical Summary

  This document clarifies and updates a single sentence in RFC 3979.
  Specifically, when 3rd party IPR disclosures are made, the intention
  is that the IETF Executive Director notify the IPR holder that a 3rd
  party disclosure has been filed, and to ask the IPR holder whether
  they have any disclosure that needs to be made, per applicable
  RFC3979 rules.

Working Group Summary

  The working group process provided an interesting discussion of past
  history of the handling of IPR disclosures, but there was no real
  controversy.

Document Quality

(Continue reading)

Brian E Carpenter | 16 Jan 10:58
Picon
Favicon

Re: IETF Trust FAQ

On 2007-01-15 18:07, Simon Josefsson wrote:
> Brian E Carpenter <brc <at> zurich.ibm.com> writes:
> 
>> Switched to a more relevant list, where this horse has
>> been thoroughly flogged already:
>>
>> On 2007-01-15 16:49, Simon Josefsson wrote:
>>> Brian E Carpenter <brc <at> zurich.ibm.com> writes:
>>>
>>>> I would refer you to the IETF Trust FAQ on RFC copyright,
>>>> http://trustee.ietf.org/24.html, point 6 and point 9.
>>> Interesting.  Point 6 seem incorrect to me, as there is nothing in BCP
>>> 78 that permits computer code extracts from RFC for third parties. 
>> Wrong. The parenthesis "(and not limited to use within the IETF Standards
>> Process)" in BCP 78 does exactly that.
> 
> I disagree.  

The Trust issued its FAQ after taking legal advice, and the Trust has
made its interpretation of its own IPR clear via the FAQ.

     Brian
Simon Josefsson | 16 Jan 18:21
Favicon
Gravatar

Re: IETF Trust FAQ

Brian E Carpenter <brc <at> zurich.ibm.com> writes:

> On 2007-01-15 18:07, Simon Josefsson wrote:
>> Brian E Carpenter <brc <at> zurich.ibm.com> writes:
>>
>>> Switched to a more relevant list, where this horse has
>>> been thoroughly flogged already:
>>>
>>> On 2007-01-15 16:49, Simon Josefsson wrote:
>>>> Brian E Carpenter <brc <at> zurich.ibm.com> writes:
>>>>
>>>>> I would refer you to the IETF Trust FAQ on RFC copyright,
>>>>> http://trustee.ietf.org/24.html, point 6 and point 9.
>>>> Interesting.  Point 6 seem incorrect to me, as there is nothing in BCP
>>>> 78 that permits computer code extracts from RFC for third
>>>> parties. 
>>> Wrong. The parenthesis "(and not limited to use within the IETF Standards
>>> Process)" in BCP 78 does exactly that.
>>
>> I disagree.  
>
> The Trust issued its FAQ after taking legal advice, and the Trust has
> made its interpretation of its own IPR clear via the FAQ.

The Trust seem to have done a poor job of convincing the community
that their interpretation is correct.  It is not clear whether they
considered the problem mentioned in this thread.  Making more of the
discussions in the Trust that led to this interpretation available
would help them to convince others and build community confidence in
that the Trust is working properly.
(Continue reading)

Harald Alvestrand | 16 Jan 20:36
Picon

Re: IETF Trust FAQ

Simon Josefsson wrote:
>>
>> The Trust issued its FAQ after taking legal advice, and the Trust has
>> made its interpretation of its own IPR clear via the FAQ.
>>     
>
> The Trust seem to have done a poor job of convincing the community
> that their interpretation is correct.  It is not clear whether they
> considered the problem mentioned in this thread.  Making more of the
> discussions in the Trust that led to this interpretation available
> would help them to convince others and build community confidence in
> that the Trust is working properly.
>   
They haven't convinced you. I'm happy.
Let others speak for themselves.
Lawrence Rosen | 17 Jan 01:40

RE: IETF Trust FAQ

At Harald's suggestion that others "speak for themselves," I'll speak up. I
agree with Simon. I'd feel more comfortable about this working group punting
Simon's issues and passing them to the IETF Trust if I had some assurance
that they were going to solve these IP policy problems in a public way with
public input. 

I do not believe that the current draft of RFC 3978 solves the problems
Simon and others have identified. For the record, I'm copying an earlier
private thread with Simon. I copied Brian and Jorge but they haven't
responded. So I'm going to copy it to the full list below. We might as well
discuss these problems now rather than have to do it right a second time.

I wish the IETF Trust lawyers who promise to help that organization draft
its policies were here now to help us, because our current policies aren't
sufficient to do the job.

/Larry Rosen

*********************************

Thanks, Simon. I specifically wrote to you and Brian directly so that I can
get to the gist of the problem you wrote about without in-channel "noise."
:-) I look forward to Brian's response. What I ultimately say publicly on
the list depends upon what I learn from you two.

I agree, though, with the fundamental premise you raised in your earlier
email, and so I suggested that contributors to IETF should be given express
notice and assurance that their contributions are intended to be
*sublicensed to the public by the IETF Trust* in the form of published
specifications compatible with both open source and proprietary licenses.
(Continue reading)

Contreras, Jorge | 17 Jan 02:34
Favicon

RE: IETF Trust FAQ


Larry,

I think that you are attempting to find ambiguity in the language
of RFC 3978 when there is none.

Section 3.3.a deals with the licenses that Contributors
grant to IETF participants with respect to their Contributions
(which are mostly text, but can also be code).  These
licenses enable the standards development and publication work
that is coordinated through IETF.  To the extent that a patent
license may be required to conduct IETF standards development
work (a proposition that is debatable), such a license is granted.
That's why 3.3.a says "under all intellectual property
rights in the Contribution".  However, if a license is granted
under patents under 3.3.a, it is very limited and only extends to standards
development work within the IETF.

The licenses under 3.3.a (other than 3.3.a.E, see below)
do NOT grant any rights to implement IETF standards 
in products.  IETF Contributors are NOT required to grant patent
licenses to implementers.  This has always been IETF's policy, and
there is no ambiguity here.

Section 3.3.a.E covers a special case in which code is embedded
in IETF documents.  Under this license, code can be extracted
and used.  However, there is an explicit exception in the license:
it does not include a license under patents.  That exception was
included for very reason stated above.  IETF does not require
participants to grant patent licenses to implementers.  Someone who
(Continue reading)


Gmane