Subject: Re: Incoming - software licenses

From: "TS Glassey" <[email-masked]>
Date: Sun, 7 Oct 2007 08:22:08 -0700

Harald - its really good to see you echoing my words finally. I should have 
sent this out a month ago but just found it in my DRAFTS folder and since it 
pertains to the IP rights of an Entity who is sponsoring people in the IETF 
its relevant.

The problem is that there is an issue with submitting anything to the IETF 
for vetting by SPONSORED ENGINEERING STAFF that is 'assigned to the IETF to 
work on the Entity's Effort's therein'.

Simply said, the SPONSORS own the WORK PRODUCT their Sponsoree's work on, 
and also get the privilege of determining what their SPONSOREE's work on. 
That is a key flaw in the current work-flow model. It assumes and insists 
that the SPONSOREE themselves control their actions within the IETF and that 
simply is not true.

That said, because the SPONSORING ENTITY does retain ownership of the IP 
until there is something between them and the IETF itself acknowledging that 
the SPONSOREE holds those abilities themselves. Otherwise their are owned 
lock, stock, and barrel, and the SPONSOREE doesnt have the legal authority 
to assing any of the SPONSORING ENTITY's IP Rights to the IETF or the IETF 
Trust no matter what the IPR WG says they do.

As such,  the IETF has a responsibility to force any and all submssions to 
disclose any and all IP Rights so that relying party's are informed as to 
what they are investing assets (the time of their Sponsoree's) w... but 
there is a problem with the IETF's disclosure model and that is that the 
model may make the IETF a formal part of a fraud by Wire which could be a 
criminal matter in my estimation.

I suggest you review the inline comments below.

----- Original Message ----- 
From: "Harald Tveit Alvestrand" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, July 20, 2007 6:28 AM
Subject: RE: Incoming - software licenses

> Seems to me (speaking as contributor) that if the contributor is not in a
> position to grant the licenses that are asked for in -incoming, he cannot
> make the contribution. I think we should make that a "no exceptions" rule.
>
> In the case of *GPL code, I think we have a couple of outs that allow us
> to get most of the benefit to the community already:
>
> - *GPL code contributed under the "no derivative works" rule would not
> impose any additional onus on the recipient - he can't use the IETF
> license to make modified versions anyway, but can discover (possibly from
> the document) that a *GPL license is available for the code, and act
> accordingly. This bars the example code from being standards-track,
> naturally.

OK now that we are at "that we cannot grant rights to our relying parties
which we as the relying party were not granted", the only impact this has is
that for proprietary standards runs, the IETF MUST require full and final
IPR disclosure in the original filing, so that SPONSORS are enabled to 
review whether
their ENGINEERING RESOURCES which they CONTRIBUTE TO THE IETF, should work
on thise initiatives or not. The IETF does not get to make its mind up what 
to of
its Member's Time to focus on any given initiative, that is up to those 
spending time there on those efforts.

Otherwise the IETF itself becomes a part to any mechanical frauds which 
occur when a relying party invests their engineer's time in a project which 
has undisclosed IP rights issues with it, and as such the IETF and the 
IPR-WG member's may ultimately be responsible for any commercial damages 
which occur.

The argument is simple, the engineer's in the IETF cannot also say "no we 
are not liable" and make that liability go away. That is to say, the IETF, 
and those inside it may in fact liable and so are those inside it I am 
betting.

>
> - *GPL code can be pointed to by contributions - possibly even published
> by the IETF in some repository that is *not* the I-D/RFC document series.
>
> Like Brian, I see an exception process as a rather expensive component of
> the process.
>
>                Harald
>
> --On 18. juli 2007 10:21 -0400 [email-masked] wrote:
>
>> Brian
>>
>> I think I agree with this line of thought - here are some more
>> detailed ideas to move this along:
>>
>> - Whatever IETF exception process exists for restrictive software
>> licenses needs to be a process of last resort.
>> - As input to the process, we should require the requester of the
>> exception to demonstrate that the code cannot be obtained
>> under conditions that allow the copyright grant required
>> by the -incoming draft. (i.e., the default hypothesis is
>> that the code can be obtained under suitable conditions,
>> and it is the requester's responsibility to disprove this
>> hypothesis).
>> - The requester should not expect IETF to act on his/her behalf
>> in attempting to obtain the code or assisting with obtaining
>> the code.
>> - Absent a convincing demonstration that the code is not available
>> under conditions that permit the copyright grant, the
>> exception should be denied.
>>
>> Thanks,
>> --David
>>
>>
>>> -----Original Message-----
>>> From: Brian E Carpenter [mailto:[email-masked]]
>>> Sent: Wednesday, July 18, 2007 9:42 AM
>>> To: Black, David
>>> Cc: [email-masked]; [email-masked]
>>> Subject: Re: Incoming - software licenses
>>>
>>> On 2007-07-18 15:18, [email-masked] wrote:
>>> > Brian,
>>> >
>>> >> On 2007-07-17 18:24, [email-masked] wrote:
>>> >> ...
>>> >>> A starting point may be that some sort of exception and official
>>> >>> approval could be required for code with a license that does not
>>> >>> permit the copyright grant to the IETF Trust required by the
>>> >>> -incoming document.
>>> >> My starting point would be to tell the person attempting to
>>> >> contribute the code to go find its original author and have
>>> >> them grant the necessary license to the IETF, independently of
>>> >> whatever other license they have put it under, and repeat until
>>> >> done. I think making exceptions possible will produce a world
>>> >> of hurt.
>>> >
>>> > That's a fine starting point, but (IMHO) it's already insufficient,
>>> > because:
>>> >
>>> > Exceptions are already happening - cf. Simon's example of LGPL
>>> > Base64 code, and I believe Simon has already brought a number of
>>> > other examples to our attention.  Ignoring this issue is a decision
>>> > that the existing exception process(es) are what we want.  I'd
>>> > prefer that to be a conscious decision rather than something that
>>> > happens by default.
>>> >
>>> > Also, there needs to be a warning somewhere for those without
>>> > sensitive legal antennae that the copyright provisions in -incoming
>>> > conflict with copyleft software licenses.  The warning could be in
>>> > an FAQ or some sort of notice in the submission process and/or tool;
>>> > it doesn't have to be in the -incoming document itself.  My concern
>>> > here is that I suspect that the members of this mailing list are
>>> > among the minority that understand the conflict between copyleft
>>> > and the -incoming copyright grant.
>>>
>>> But I think if we include that warning we have to offer a work-around
>>> which doesn't lead to exception handling in *our* process - put the
>>> onus for the work-around on the person who wrote the code and decided
>>> to encumber it with copyleft in the first place.
>>>
>>>      Brian
>>>
>>>
>>
>> _______________________________________________
>> Ipr-wg mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/ipr-wg
>>
>>
>
>
>
>
>
> _______________________________________________
> Ipr-wg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipr-wg

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

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 7 Oct 2007 08:29:27 -0700

Damn spell checker... "assign"... sorry.

T
----- Original Message ----- 
From: "TS Glassey" <[email-masked]>
To: "Harald Tveit Alvestrand" <[email-masked]>; <[email-masked]>; 
"Brian E Carpenter" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, October 07, 2007 8:22 AM
Subject: Re: Incoming - software licenses

> Harald - its really good to see you echoing my words finally. I should 
> have sent this out a month ago but just found it in my DRAFTS folder and 
> since it pertains to the IP rights of an Entity who is sponsoring people 
> in the IETF its relevant.
>
> for vetting by SPONSORED ENGINEERING STAFF that is 'assigned to the IETF 
> to work on the Entity's Effort's therein'.
>
> that the SPONSOREE themselves control their actions within the IETF and 
> that simply is not true.
>
> until there is something between them and the IETF itself acknowledging 
> that the SPONSOREE holds those abilities themselves. Otherwise their are 
> owned lock, stock, and barrel, and the SPONSOREE doesnt have the legal 
> authority to assing any of the SPONSORING ENTITY's IP Rights to the IETF 
> or the IETF Trust no matter what the IPR WG says they do.
>
> on thise initiatives or not. The IETF does not get to make its mind up 
> what to of
> occur when a relying party invests their engineer's time in a project 
> which has undisclosed IP rights issues with it, and as such the IETF and 
> the IPR-WG member's may ultimately be responsible for any commercial 
> damages which occur.
>