If we are strict, the normative text in -incoming must only
obtain rights, to be vested in the IETF Trust, and then the
Trust must give the outgoing rights, in accordance with
the advice in -outbound. But logically, -incoming could
meet this test by saying the equivalent of
Contributor must grant to the Trust necessary and
sufficient rights for the Trust to be able to grant the
following outbound rights to third parties: XXXX, YYYY,
...
Brian
On 2007-03-02 14:29, Joel M. Halpern wrote:
> I apparently understand the goal slightly differently
from the way Simon
> does.
> I agree that -incoming does not talk about direct
grants of third party
> rights in documents.
> That's because we (the working group) agreed on the
-incoming /
> -outbound split whereby the -outbound document
describes all rights
> granted to others in IETF contributions, while -inbound
talks about the
> rights the authors grant to the IETF in contributions.
(-incoming
> rights clearly needing to be a superset of -outbound.)
Hence, it is
> almost inevitable that this is going to tighten up the
3978 language
> that provides indirect grants.
>
> Yours,
> Joel M. Halpern
>
> At 06:43 AM 3/2/2007, Simon Josefsson wrote:
>> All,
>>
>> As far as I can see, this document leaves no rights
granted to third
>> parties. That is against both RFC 2026 and RFC
3978. RFC 2026 grants
>> third parties rights in the boiler plate, section
10.4
>>
>> This document and translations of it may
be copied and
>> furnished to others, and derivative works
that comment on or
>> ^^^^^^
>> otherwise explain it or assist in its
implmentation may be
>> prepared, copied, published and
distributed, in whole or in
>> ...
>>
>> RFC 3978 section 3.3 was intended to do the same,
but the wordings
>> were poorly chosen, and the third parties now
granted rights only
>> include the loosely defined recipient
"IETF":
>>
>> 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:
>>
>> However, to clarify, Jorge has said that the
following term in RFC
>> 3978 section 3.3 give third parties additional
rights directly:
>>
>> (E) to extract, copy, publish, display,
distribute, modify and
>> incorporate into other works, for any
purpose (and not limited
>>
^^^^^^^^^^^^^^^
>> to use within the IETF Standards Process)
any executable code
>> or code fragments that are included in
any IETF Document (such
>> as MIB and PIB modules), subject to the
requirements of
>>
>> This text is not clear, I believe it speaks about
intended use, not
>> intended recipients. However, Jorge's opinion
indicates that RFC 3978
>> also grant rights directly to third parties.
>>
>> It may be useful to look at the IPR WG charter
about this document:
>>
>> - An update to RFC 3978 (BCP) that attempts to
specify a complete set
>> of rights with respect to derivative works
granted to the IETF by
>> authors, as well as technical updates
necessitated by the existence
>> of the Trust
>>
>> The way I read that is that this document has the
specific scope of
>> talking about rights granted to the IETF. Thus, it
should not
>> restrict what rights are granted to third parties
by RFC 3978, and let
>> that part of RFC 3978 remain in effect. There seem
to be a conflict
>> between the WG charter and with the documents'
claims that it
>> obsoletes RFC 3978.
>>
>> /Simon
>>
>> _______________________________________________
>> Ipr-wg mailing list
>> Ipr-wg ietf.org
>> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
>
>
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wgietf.org
> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
>
_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
|
