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