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

[Alaric Snell-Pym]

On 08/23/10 21:50, Peter Bex wrote:

> > I'm just saying that in the "check-errors" package none of the other
> > modules were actually exposed to the contagion from the GPL tainted
> > "error-utils".
>
> That may or may not be the case, but I think it's important to be
> crystal clear in these matters.  For us hackers it's confusing, but
> for companies it's probably a deal-breaker since they'd have to put
> expensive lawyers on figuring out if that's indeed the case.

Relatedly, I've been wondering about how to neatly handle "optional
dependencies" in eggs.

Take Ugarit, for example. It has pluggable hash functions and
compression engines and storage backends. If I want to offer the ability
to use some GPL-ed storage backend - creating a GPL-ed Ugarit binary - I
don't want to then taint Ugarit.

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 want to do this work for the storage backends, as there is
a compelling reason for me to want them to be separate binaries spoken
to via a protocol over stdin/stdout - it lets one talk to a remote
backend over an ssh connection, which is handy for a backup system! But
hash and compression functions are a bit more tightly coupled into the core.

What I'd love is to have optional dependencies listed in the egg
metadata, and then a way in the egg of being able to cond-expand based
on which dependencies are available and enabled. chicken-install should
have some mechanism to "disable" optional dependencies even through
they're installed, so it's easier to build the non-GPL version of the
egg in testing :-)

AIUI, the GPL issue is this: We can have BSD or GPL licenses on source
code to our heart's content, but a binary that contains GPL code *or
dynamically links to GPL code* is then a GPL binary, and all source code
that went into it must be released?

I'm a bit hazy on how that extends from "one binary" to "a tarball",
mind; an egg can generate multiple libraries and executable binaries.

But by that interpretation, a BSD egg could have an optional GPL
dependency, and thus be able to generate BSD and GPL binaries, depending
on whether the optional dependency was used. Right?!?

chicken-install might be extended with a 'viral' flag on an egg's
license, and then compute a license for every *installed compiled egg*,
which will be the intersection of the egg's own license and the viral
licenses of all its dependencies, and a viral flag if the egg's own
license is viral. This could be easily represented as a symbol (the
egg's native license) and a list of viral licenses (which may include
the egg's own license if it's viral, and which all dependent eggs inherit).

Then people can easily know if they've just built a GPL binary!

ABS

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