On Mon, 12 Mar 2007, Laszlo (Laca) Peter wrote:
> Dermot wrote:
>> The controversial part is installing in /usr/gnu, even though it is
>> not name-conflicting with anything in /usr - does /usr/gnu allow
>> for this usage?
>
>
>> It is proposed to install readline under /usr/gnu [3],
>> as placing it in /usr may lead other consolidations or
>> ISVs to ignore its licensing restrictions.
>> **FIXME** need to reference upcoming GPL/LGPL Legal review here?
>
>
>> /usr/gnu/lib/libreadline.so.4 Uncommitted Shared
>> object library
>> /usr/gnu/lib/libhistory.so.4 Uncommitted Shared
>> object library
>
> Hmm... reading this again, it does appear to be an abuse of /usr/gnu.
> /usr/gnu is not about licensing, it's not even mentioned in the
> proposal. So unless we expect an alternative libreadline or libhistory
> that would go into /usr/lib, or if readline depends on a lib that
> is already in /usr/gnu, I don't see why readline would belong
> in /usr/gnu.
>
> BTW, the GPL/LGPL rules doc that I found doesn't differentiate
> between GPL and LGPL when it prohibits installing to /usr/lib, so
> there are already a lot of libs in violation of that rule.
>
> Laca
I for one am glad to hear that. My original reaction to readline shared
objects going in /usr/gnu was something like this:
!! So now we're saying that putting FSF/UNESCO stuff in /usr (not
/usr/gnu) is preferred, except where there's a name collision..., (and
except when the package delivers a viral library... (and library x is
considered viral but library y isn't... (which is debatable depending
on which expert you ask.)))
Eric
