[Fedora-legal-list] Another list of potential issues

[Tom "spot" Callaway]

On 04/30/2009 03:38 AM, Rahul Sundaram wrote:
> Hi
> 
> I know there are differences in legal policies but there might be common
> problems as well.
> 
> http://www.mail-archive.com/gnewsense-dev@nongnu.org/msg00125.html

So, looking at that list:

* afio: Yeah, we know about this one. Not in Fedora, caught it on review.
* texlive-base, texlive-latex-base: Yes, we're aware of it, auditing it
is a nightmare, but I plan to revisit it in earnest after Fedora 11.
* libsnmp-base: This is net-snmp (In Lenny, this is 5.4.1, in Rawhide,
we're at 5.4.2.1). This is about the MIB files derived from IETF RFCs.
The license for IETF RFC docs says:

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

As the MIBs are clearly derivative works, they are available as
derivative works that "assist" in the implementation of the various
RFCs, without restriction of any kind. Unfortunately, the paragraph is
confusingly worded, as they almost certainly mean for "the document" to
mean the original RFC from which the work is derived. In addition, these
MIB files are arguably in a gray area between Documentation, Code, and
Content. I'm going to interpret them as Content, since they serve simply
as reinterpretations of the published standard. It would be nice for the
IETF to fix this, but as no obvious "code" is under these terms, it is
less of a problem.

* libsmi: Same issue as libsnmp.
* pike: Not in Fedora.
* gkrell-snmp: I don't think this is in Fedora, but it is resolved with
upstream adding the OpenSSL exception clause in 1.1.

~spot