[Sugar-devel] Full Licence field
sdaly.be at gmail.com
Wed Mar 18 20:32:46 EDT 2009
Questions like these are bread and butter for the SFC.
On Wed, Mar 18, 2009 at 10:24 PM, Walter Bender <walter.bender at gmail.com> wrote:
> On Wed, Mar 18, 2009 at 4:44 PM, David Malcolm <dmalcolm at redhat.com> wrote:
>> On Wed, 2009-03-18 at 16:00 -0400, Tom "spot" Callaway wrote:
>>> On 03/18/2009 03:45 PM, Kevin Kofler wrote:
>>> > Simon Schampijer wrote:
>>> >> Yes. So the main question is now if Fedora would be willing to ship
>>> >> general licenses under /usr/share/common-licenses, I think.
>>> I really don't want to do this. Here's why:
>>> A) Many copyright holders make minor modifications to the licensing
>>> terms. These modifications usually do not affect the rights granted by
>>> the license (which is why we do not mark them as distinct and individual
>>> licenses), but it would be incorrect to have these packages pointing to
>>> general license texts when those do not apply.
>>> B) Many licenses require that any distribution include the license text.
>>> Red Hat Legal was very uncomfortable with us using a rpm dependency to
>>> meet that requirement.
>>> What I do think we were looking at doing is having rpm mark %license
>>> texts in a unique way that is different from %doc. This would permit rpm
>>> --excludedocs but retain the license texts.
>> Thinking aloud, a couple of other approaches:
>> (i) Embed the SHA256 checksum of each license into the path e.g.:
>> then have each file's identical implementation of those bytes overwrite
>> each other, and you might have many packages owning that path on the
>> installed system. Slight modifications thus lead to different paths.
>> That way you still have duplicates in the .rpm files, but an installed
>> system has just one copy of each, and each rpm does indeed ship the
>> precise license it's required to.
>> I suspect that the arguments from crypto and from the legal side will
>> "pass through one another like angry ghosts", though (and legal thus
> What a nice idea.
>> (ii) Compress the licenses?
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
> Walter Bender
> Sugar Labs
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
More information about the Sugar-devel