[scikit-image] linking to GPL code from BSD code (was: BM3D)

[Nathaniel Smith]

On Wed, Nov 1, 2017 at 8:24 PM, Josh Warner <silvertrumpet999 at gmail.com> wrote:
> I'm not a lawyer, but I believe there is a longstanding misunderstanding on
> this matter and the FSF is in the wrong.  The FSF, in the GPL FAQ, says that
> maintained dynamic linking, as exhibited in Python, infects any package that
> imports.  However, to trigger this clause the 'linked' package must
> constitute a derivative work, which has a definite legal meaning.  The FSF's
> justification in the case of static linking is relatively sound.  However,
> legal rulings on the matter of dynamic linking, as in Python (Galoob v.
> Nintendo) disagree.
>
> For those interested, the actual ruling for Galoob v. Nintendo:
> https://law.justia.com/cases/federal/appellate-courts/F2/964/965/341457/
>
> The relevant portion of the ruling, which stands today and was affirmed in
> Micro Star v. FormGen Inc., states rather concretely
>
>> A derivative work must incorporate a protected work in some concrete or
>> permanent "form."
>>
>
>
> Ergo, despite what the FSF states, on the basis of current law dynamic
> linking - linking without creating a file in any way, simply asking another
> library to do something - does not constitute creation of a derivative work,
> and thus does not infringe the GPL.  Linking as a matter of current law
> involves actually combining the linked code with the code from the linking
> package into a concrete form, generally a file, which can then be executed.
> Thus, static linking infects, but dynamic linking does not.  Again, this
> isn't what the FSF says, but ultimately the GPL means what it actually says,
> not what the FSF wants it to.  Consider this the same way that the US
> Constitution exists separately from the Federalist papers and other writings
> of the founding fathers.
>
> Despite this being relatively clearly settled law, very few people call the
> FSF out on it, and fewer have the guts to act appropriately as permitted
> under the law.  Most It's actually harming communities, though, and PyFFTW
> is a great example.
>
> If anyone can actually refute this, I'm all ears.

I'm not a lawyer either, but this strikes me as extraordinarily
overconfident armchair lawyering. You can't take one sentence out of
one ruling and base a whole legal analysis on it.

In this case, I guess you're arguing that because dynamic linking only
combines the works temporarily in memory at runtime, this isn't a
"concrete or permanent form", just like the Game Genie only modified
Nintendo games dynamically in memory, so no derivative work is
created. But... this is refuting a straw man. Even the FSF doesn't
think that you combining two works at runtime in the privacy of your
home is a license violation; I've never even heard that argument. The
usual argument for dynamic linking creating derivative works is that
in order to write the program that calls PyFFTW or whatever, you had
to incorporate various creative ideas encoded in the PyFFTW API into
the structure of your program. A crude example would be that your
program's text probably contains a bunch of function names that the
PyFFTW developers invented, but it's more than just that -- look up
the Abstraction-Filtration-Comparison test, and consider that if you
write a book that's just like Harry Potter but with every word
replaced by a synonym, or even a piece of fan-fic that uses the same
characters but none of the same language, then those can still be
derivative works of J. K. Rowling's texts.

The FSF is definitely guilty of oversimplifying this, but it's
probably best to think of their position as a simple bright-line rule
of thumb, like... if you follow this rule you're definitely safe, and
if you don't follow this rule... well, it's complicated and ultimately
it might depend on what the jury had for lunch that day, so good luck.
Or at least you should ask an actual lawyer :-)

-n

-- 
Nathaniel J. Smith -- https://vorpus.org