Subject: Incoming - software licenses

From: [email-masked]
Date: Thu, 12 Jul 2007 11:52:37 -0400

I just sent a Last Call issue on software licenses and the -outgoing
document, which I think is a clarification issue.  The interaction
of software licenses and the incoming document is more "interesting".
I should apologize in advance to Simon, as I think he's been over this
ground in much more detail, and I have not had the time to review
what he's done.

There should be a general goal that if incoming code has a software
license, then that license should be consistent with the following
provision of the outbound document:

   As such, the rough consensus is that the IETF trust is to grant
   rights such that code components of IETF contributions can be
   extracted, modified, and used by anyone in any way desired.

and so use of licenses that are not consistent (e.g., copyleft,
patent provisions) ought to be discouraged when there's an alternative.
When there's no alternative, things appear to get "interesting".
Some of these licenses could prevent contribution of code to IETF
because they restrict the copyright grant to the IETF Trust
(Section 5.3 of -incoming) in a fashion that cannot be dealt
with by prohibiting derivative works.

Let me stop here to allow the WG chair to determine whether
discussion of the "interesting" consequences is in scope.  At a
minimum, we probably ought to agree on goals (e.g., do we want to
be able to accept GPL-licensed code in contributions?, should this
be a normal or exceptional procedure?) before discussing mechanisms
to achieve the goals.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 17 Jul 2007 17:42:50 +0200

> with by prohibiting derivative works.

I agree that when there isn't an alternative available, it gets
"interesting".  I believe most practical situations will be in that
interesting area too.  The LGPL code in the Base64 document is an
example, and the many third-party code in various RFCs are others.

However, I challenge that it is simple to solve this when there is an
alternative.  The problem is: Who will decide that something is an
alternative or not?  For anything that is non-trivial, each alternative
solution will have various advantages and disadvantages.  It is rare
that you will find two solutions to the same problem with the exact same
properties.

Going back to the Base64 example.  There are Base64 code available under
more permissive licenses than the LGPL.  However, all of the about 10
such examples that I found and reviwed (before writing my own) turned
out not to follow the recommendations in the RFC, or have other
disadvantages.  Some believed they were "alternatives", but I did not
(and I could point to some section of the RFC).  Deciding who is right
in that situation is difficult.

My point is that any rule written for the situation when an
"alternative" exists will be difficult to apply in the real world,
because the problem is in deciding what an "alternative" is.

/Simon

---

From: [email-masked]
Date: Tue, 17 Jul 2007 12:24:46 -0400

Simon,

And thanks for weighing in on this topic also.

> that you will find two solutions to the same problem with the exact
same

The topic of "Who will decide" is definitely a discussion that I think
the IPR WG ought to have, as it's related to whether this is a normal
or exceptional process, and under what circumstances it's normal vs.
exceptional.

> such examples that I found and reviewed (before writing my own) turned

Ok, and if a similar circumstance came up today, an outcome to
include LGPL code in an RFC would be (IMHO) a plausible conclusion,
but I'd want this issue looked at more closely than if the code
were BSD.  (For those not familiar with the licenses, LGPL is a
copyleft license that allows linking with non-copyleft code, BSD
does not contain copyleft provisions).
 
> because the problem is in deciding what an "alternative" is.

I agree, that it's not possible to write the rules for all cases in
advance, but it should be possible to write the rules to cover common
cases and define the process (plus associated goals and guidelines)
for dealing with the exceptional cases.  We have lots of examples
of MIB modules, ASN.1, ABNF, etc. that just don't run into any
problems here (e.g., no separate software license) and should be
clearly allowed without having to "ask permission".  Writing the
conditions under which it is necessary to "ask permission" and
then figuring out who gets asked is the work that I think needs
to be done here, as opposed to trying to sort out every case in
advance.

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.  Most copyleft licenses do not permit that
grant because it does not require redistribution to be under
the copyleft license, and hence that grant requires rights beyond
the scope of copyright carried by the copyleft license.  We may
achieve some of this via the processes already available for
exceptions (e.g., I believe the IESG is empowered to grant some
exceptions to the standards process), but we should work through
what we want for an exceptions process as opposed to just
taking what we get by default with the existing process documents.

All of the above is about copyright.  If patent rights ever land
in the IETF Trust, then patent license provisions of software
licenses become a consideration.

Thanks,
--David

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Jul 2007 10:12:56 +0200

On 2007-07-17 18:24, [email-masked] wrote:
...
> -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.

     Brian

---

From: [email-masked]
Date: Wed, 18 Jul 2007 09:18:43 -0400

Brian, 

> done. I think making exceptions possible will produce a world

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.  

Thanks,
--David

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Jul 2007 15:41:35 +0200

> 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

---

From: [email-masked]
Date: Wed, 18 Jul 2007 10:21:27 -0400

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
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 18 Jul 2007 10:27:57 -0400

I tend to agree with Brian.

>done. I think making exceptions possible will produce a world

I get to this conclusion from another angle as well.  If we introduce 
exceptions, conditions, and variations then we produce two bad results:
Firstly, we require everyone using code from RFCs to be careful to 
figure out what terms the code is under.  And the RFC implementor may 
even (as has been discussed on the list before) have to take 
interesting steps to avoid license contamination.
Secondly, we cause various working groups to have to have debates 
about this non-technical aspect of their work.  Debates which have 
been demonstrated to consume VAST quantities of time.

Yours,
Joel

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 20 Jul 2007 06:28:44 -0700

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