On Fri, 2009-11-06 at 10:31 +0200, Damyan Ivanov wrote: > -=| Daniel Kahn Gillmor, Thu, Nov 05, 2009 at 02:33:47PM -0500 |=- > > On 11/05/2009 11:22 AM, Stefan Hornburg (Racke) wrote: > > > The module author may allow compiling/linking/using OpenSSL in addition > > > to the GPL. > > > > hrm. This is true for the smaller case, but then what about other > > GPL'ed perl modules that depend on Filter::Crypto::Decrypt? > > > > Do those modules also need to have the OpenSSL exception in them? How > > far does the extension need to reach? > > I think the answer to this question is "No", but can't remember why :| I think the answer's "yes and no and it doesn't matter". Yes, all reverse deps would need a GPL exception if the GPL was their only license (and it could get complicated if those modules then depended on unrelated Perl modules without an exception). See, for instance, the special exception that Totem (and Rhythmbox, but it's not in debian/copyright, tut, tut) have added so that non-GPL compatible GStreamer plugins can be used. No, in practice, most Perl modules are also under the Artistic license, which is compatible with the OpenSSL license, so we could use them on those terms. It doesn't matter, because in the specific case of libfilter-crypto-perl, any module that truly depended on it would be using encrypted source code (or just obfuscated, given we know the key?) so would be contradicting the GPL from the beginning (because we need to ship the preferred form for modifications). I suppose we could conceive of an app that generates obfuscated code, though... [Standard disclaimers about this not being legal advice apply.] -- Tim Retout <tim@retout.co.uk>
Attachment:
signature.asc
Description: This is a digitally signed message part