Re: Netatalk and OpenSSL licencing
Glenn Maynard wrote:
>In practice, there are some implicit boundaries that are generally
>agreed on in practice; for example, the kernel tends to act as a magic
>licensing firewall, such that GPL code isn't "linked" against the
>kernel or to other, unrelated processes. (I can't offer a legal
>grounding for this, though.)
Some background here.
The issue is entirely one of what sort of combination C constitutes a
"derivative work" of two sources (source A and source B), as opposed to
being an aggregation or collection.
Now, if A provides a public (and published, and freely implementable)
interface, with multiple implementations, and you program B to the
interface, then having B use this interface of A is normal and expected
use of A. The code in B and A is not intertwined or interdependent in
any way. I really hope no judge would then declare that there was a
derivative work involved. IANAL, however.
The rule of thumb for linking-type situations is "can you simply and
directly replace A with something else?" If you can, then you probably
don't have a derivative work when you distribute B with A.
The kernel provides a public, documented, freely implementable interface
of system calls. I don't know if you can replace it with something
else, but you should be able to.
Similarly, shell scripts are definitely not derived from 'bash', GNU
'find', etc. if they're written to run on any POSIX shell with a POSIX
set of tools. (If they use obscure bashisms which you only understand
how to use by looking at the bash source code, well, then you might have
to worry. :-( )
Theoretically, OpenSSL provides a public, documented, freely
implementable interface. However, the fact that nobody has actually
done a successful, fully compatible reimplementation makes that somewhat
suspicious.
Reply to: