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

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.

- *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