[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

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" <harald at alvestrand.no>
To: <Black_David at emc.com>; <brian.e.carpenter at gmail.com>
Cc: <ipr-wg at ietf.org>
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 Black_David at emc.com 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:brian.e.carpenter at gmail.com]
Sent: Wednesday, July 18, 2007 9:42 AM
To: Black, David
Cc: simon at josefsson.org; ipr-wg at ietf.org
Subject: Re: Incoming - software licenses

On 2007-07-18 15:18, Black_David at emc.com wrote:
> Brian,
>
>> On 2007-07-17 18:24, Black_David at emc.com 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
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg







_______________________________________________
Ipr-wg mailing list
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg



_______________________________________________
Ipr-wg mailing list
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg