On 08/05/2009 07:15 PM, Gregory Maxwell wrote:
So if you create a piece of software that can equally link to X or Y, and you never use/distribute X yourself you are simply not within reach of X's licensing terms. If someone else takes your software and X then sticks them on a CD, then they are obligated to follow X's license, which may include terms that make depends about the licensing of other software— ... software that links to it... software on the same media .... software in the same building ... software that starts with the same letter. Doesn't matter. Whatever the conditions are, they are the conditions for using X. If you can't simultaneously satisfy the requirements of X and the requirements of some other software package you'll have to stop distributing one or the other or risk litigation from whomevers requirements you're violating.
This is another reason why in Fedora, we ensure that linked packages are compatible, but we don't try to label the license of a package based upon externally "inherited" licensing.
The concept of what makes up a "derived work" in software is extremely complicated, and widely disputed, depending upon who you ask. There is also not a lot of case law in the US that would help provide clarification on how the courts would interpret things. The FSF is rather outspoken in their opinion that all linking creates a shared work, but that is simply their opinion. I would argue that there are probably many situations like the one Chris described where the software could clearly be argued to not be a derived work of either "crypto" API, or when a dependent library can be easily replaced with an ABI compatible alternative (either with a recompile or without). What if an application dlopens another library to use it?
At the end of the day, the answer that any lawyer worth talking to will give you is that it depends on the specifics of the situation at hand.
Red Hat Legal is comfortable with the general policies that we've adopted in Fedora, which is to ensure that there is license compatibility across shared library linking, with the exception of "System Libraries". (I'm in the middle of trying to convince them that OpenSSL consists of a "system library" at this point, but we still haven't decided whether we're going to adopt that stance or not)
~spot -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list