RE: Incoming - software licenses

[Black_David at emc.com]

Simon,

And thanks for weighing in on this topic also.

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

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.

> 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 reviewed (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.

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).
 
> 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.

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
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

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