License poisoning from dependencies

#1

So this is an interesting scenario that I’ve recently stumbled upon due to needing a feature in a build manager for shared library dependencies.

A quick rundown for those who are not native programmers.
There are two outputs a compiler can produce that is directly executable, executables and shared libraries. Both of these can be referred to as binary images.
An output that a compiler can produce that is not directly executable is static libraries, these get linked into a binary image.

Now the scenario. ProjectA depends on ProjectB. ProjectB is a library that is compiled as shared library. But it defines a (or set of) file(s) that will be injected into the build process of any code that depends upon it.

ProjectB in their ever-strong desire to be copy-left but friendly for shared library usage, decided to go with LGPL. A license that basically means in context that as long as you state that a dependent library is LGPL, you’re good.
BUT they added that nifty new feature! Injection of source files.

Those source files are also LGPL except, they are being compiled into ProjectA’s binary! Which means that they are actually devolved into GPL, poisoning ProjectA’s license.

Anyway, I thought this was an interesting legal situation that could be ran into.

#2

As in, the source code is included as binary data in the executable? Just so its’s part of the binary that gets distributed?

#3

Yes.

Utility type stuff, registration of types, globals that sort of thing.

#4

‘poisoning’ or ‘hybridization’? AFAIK you can’t license the output from code? Isn’t that’s what is happening here, in a way?

#5

No.

The injected source file is not generated. It absolutely is licensed.

#6

Right… but I’m thinking either the dependency injection is a middleware type of thing, in which case the license just stays fixed to the source, or it offers a build with artefacts which would (AFAIK) lie outside the scope of the license?

#7

In the case of LGPL, it resorts to being GPL.

Basically, LGPL has dynamic linking exceptions, but you used it in a statically linked binary (unintentionally), where the LGPL exceptions don’t apply.

The license scope is clear, it’s just that the build manager hid the fact that you used GPL code when you didn’t expect to.

#8

Okay, but my thinking is that courts may or may not follow computer science logic?

1 Like
#9

In that same post a reference to Lewis Galoob Toys, Inc. v. Nintendo of America, Inc.

Here is a relevant quote from the source article:

The Copyright Act’s definition of “audiovisual works” is inapposite; the only question before us is whether the audiovisual displays created by the Game Genie are “derivative works.” The Act does not similarly provide that a work can be a derivative work regardless of the nature of the material objects in which the work is embodied. A derivative work must incorporate a protected work in some concrete or permanent form. We cannot ignore the actual source of the Game Genie’s display.

So at the very least, I would argue (without a law degree anyway) that the injection of source feature in a build manager constitutes a binary to become a derivative work due to a source file being incorporated in a permanent form in it.

This may not apply everywhere, or even still apply, but I think that this certainly does add interest!

#10

Related, perhaps of interest: GCC Runtime Library Exception Rationale and FAQ - GNU Project - Free Software Foundation

1 Like
#11

If I were a court judge, I would throw this shape of argument out in a jiffy because the source isn’t changed in the build AFAICT and the injection into the build manager doesn’t create a derivative - again - only IMO. Maybe it’s fortuitous for everyone that I am just a fat-fingered stack mercenary then…