chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] Re: Backdoor GPL in message-digest


From: Alaric Snell-Pym
Subject: Re: [Chicken-hackers] Re: Backdoor GPL in message-digest
Date: Tue, 24 Aug 2010 11:08:56 +0100
User-agent: Mozilla/5.0 (X11; U; NetBSD amd64; en-US; rv:1.9.1.9) Gecko/20100520 Lightning/1.0b2pre Shredder/3.0.4

On 08/24/10 10:59, Peter Bex wrote:

Yes, I know I can work around it by making Ugarit containg a plugin
registry, and then having separate GPL-ed backend eggs that depend on
Ugarit and work by registering themselves as plugins somehow, but that's
Extra Work.

I don't see how that Extra Work is more Extra Work than testing every
possible permutation of options you would have in order to verify it
works in all those cases, let alone testing those permutations on
different OS/architecture combinations.  I think that's even harder
to test consistently.  What do we tell Salmonella to test?

Hmmm. Perhaps the answer, then, is to make a nice (public domain!)
plugin-registry egg that handles this for us.

It'd keep a list (somewhere) of what modules implemented what
interfaces, along with other metadata, with some suitable hooking into
the install/deinstall process so that .setup scripts can register the
modules from the eggs with it.

Then, it would provide a library that lets apps and other libraries find
a list of implementations of a specified interface (eg, "hash
function"), along with their metadata (hash size, "considered broken so
only here for compatability", etc), and the ability to "load" one and
get back an object (record full of closures or whatever) representing
the plugin.

Doing that once and for all would take the burden off of people who
really need plugins, and would avoid having a zillion different plugin
systems lying around for different things.

Also note that the LGPL is incompatible with the GPL in that you cannot
link a LGPL library or program to a GPL library(!)   I think if we build
a license checking feature into chicken-install, it should handle
incompatible licenses in general.

Hmmm, true. As long as this can be done with a simple (read:
non-bloating) extension inside chicken-install, with all the evil stored
in some kind of license metadata.

Also, I think that chicken-install should not *forbid* license clashes,
merely *warn* about them. License clashes are generally a problem for
people wanting to distribute binaries, and not an issue at all for
people just hacking around at home, right?

Cheers,
Peter

ABS

--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]