[Sugar-devel] Full Licence field

Tom "spot" Callaway tcallawa at redhat.com
Fri Mar 20 09:36:22 EDT 2009

On 03/20/2009 08:52 AM, Lyos Gemini Norezel wrote:

> Maybe it's because I'm not a lawyer, that I fail to see the problem with
> that. As long as there exists some reference to the license and a location
> where it can be read, doesn't that meet the requirements of those licenses?

The short answer is not really. The more assumptions we make, the
farther we get from reality, and for the majority of FOSS licenses, we
(Fedora/Red Hat) bear the burden of informing the user of the licensing
terms of the software that we are distributing.

Here is a common scenario:

The upstream for a package changes licensing from GPL to LGPL. If we are
using a generic-licenses package, we are far less likely to notice this
change, whereas, we would immediately notice that COPYING was replaced

> Wasn't there a discussion, somewhat recently, about libraries that are
> shipped with the program instead
> of being stored in /lib or /usr/lib?

This is notably different. The licensing is part of our legal obligation
to our users and downstream consumers.

In addition, this comes out to about 17 MB. It is not a huge amount of
disk space, and certainly not worth the rather additional hassle it
would cause.

As it is now, each package maintainer is responsible for keeping the
license text as provided by upstream in the package, and the License tag
correct. If we were to generalize this into a central package, we'd have
to do constant auditing to be sure that the license text in the
generalized "LICENSE.rpm" exactly matched that of the package. And by
we, I mean me. Even if Red Hat Legal signed off on such an arrangement,
I'm not really thrilled by this prospect.

Now, if there were a clever way to handle this behind the scenes so that
these license files were not duplicated if they were identical, but
instead, symlinked to the license files in a generic license rpm, I
might be more interested. (If they weren't bit for bit identical, it
wouldn't be symlinked).


More information about the Sugar-devel mailing list