-----Original Message-----
From: Richard Fontana [mailto:rfontana@...]
Sent: Wednesday, January 26, 2011 2:29 PM
To: Tom Incorvia
Cc: Jilayne Lovejoy; Kim Weins; SPDX
Subject: Re: new version of License List uploaded

Delurking ...

On Wed, Jan 26, 2011 at 12:07:02PM -0800, Tom Incorvia wrote:

- Regarding the MIT license.  This is a VERY well-established license,
#4 on the Black Duck site, is listed in expected form the OSI site, etc.  I
have not seen variants other than the copyright year and copyright holders
template holders.  I strongly recommend that we maintain the MIT license
without associating it with Expat.   No opinion on whether to list Expat or not
– I have not used it, but am in the commercial world

This is rather contrary to our experiences at Red Hat. We've
encountered fascinatingly numerous language variants on the
MIT/X11/Expat license family in the wild (though you might want to
argue that these shouldn't be treated as one family). I once started
to make an effort to catalogue all the different variants you find in
just one project (Kerberos) and gave up (maybe out of boredom, but
still...). Tom Callaway has probably made the most careful attempt to
collect the various licenses that seem to often be labelled "MIT". (No
question that the direction is towards standardization on the version
that OSI happens to list as a template, or something close to that.)
Some of the variants one finds in this license family are arguably
legally significant. For what it's worth, Red Hat and Fedora use the
"MIT" label to describe all of the various licenses in this family in
package metadata.

I would assume that Black Duck listing the MIT license as #4 involves
to at least some degree collecting a bunch of variants.

- Regarding Perl – since there is not a Perl license or Perl license
stack (like Python), I suggest that we not list Perl as a license.

I wonder if the value in doing so lies in the fact that Perl modules
are commonly licensed as "under the same terms as Perl itself", which
most often probably means (Artistic 1.0 or GPL) but is sometimes
unclear.

- I am not familiar with the general use of the OpenSSL exception, but
it is certainly distinct from any exceptions that we currently have listed. 
Here is a reference from Debian Legal on this exception.  Does anyone have
experience with this exception and know if the text is consistent?

We have experience with it. Not sure there is one canonical version
but I think the one in that debian-legal posting is the one that the
FSF recommended at one time. I believe that there is a different
version that was updated for GPLv3, but I may be misremembering. I
seem to remember writing my own version (while at Red Hat) at one
point.

Conceptually, the OpenSSL exception is one of a class of GPL linking
exceptions.

- Anyone else familiar with GPL Font – not me? 

The GPL font exception, which originates with the FSF, is pretty well
known. We've used and encountered it in certain forms at Red Hat. It
is possible the FSF has an updated version for GPLv3, or will someday.

- Richard


This message has been scanned for viruses by MailController - www.MailController.altohiway.com