GPL as an evaluation license

GPL as an evaluation license

Oleg Goldshmidt pub at goldshmidt.org
Mon Apr 11 00:13:22 IDT 2011


On Sun, Apr 10, 2011 at 9:45 PM, Aviad Mandel <aviad.mandel at gmail.com> wrote:
> On Sun, Apr 10, 2011 at 8:28 PM, Oleg Goldshmidt <pub at goldshmidt.org> wrote:
>>
>> This looks to me (reminder: IANAL) as a rather simplistic attempt to
>> circumvent GPL. I cannot believe that this trick is legal.
>
> I'm likewise skeptic. But if this is illegal, and I don't understand why,
> then there's still an important lesson to learn.

The lesson is that you focus on technical tricks in the (futile) hope
of avoiding the intellectual property question.

You have a GPLed library A and proprietary code B. Is B+A a derivative
work of A or not? No amount of technical trickery (writing a wrapper
for the GPLed API, distributing B and A separately and asking the
customer to o the linking, whatever) should be enough to change the
answer from "yes" to "no" (barring a serious legal hole in GPL).

>> Typically, however, the B part will contain pieces that use the A
>> library - without those pieces the library will not be needed. The
>> rest is a legal (copyright) question: does this make B a "derivative
>> work"?
>
> My question is: Does it matter? Business B owns the B part, so it doesn't
> need any permission to distribute the code.

Yes, it does, if B is a derivative of A, e.g., will not work without
A. In my earlier example, business B will not need A's permission to
sell a microwave oven (that will not need A), but will need such
permission to sell a voice-controlled oven that uses A to implement
voice control functionality. Assuming the whole thing is a single
piece (as it is likely to be in your case) the whole of B+A must be
under GPL. B are free to use some other voice control library with a
more permissive license, or forget about voice control - in both cases
they can keep their code closed. But the cannot base the product on A
and avoid GPL.

> Part A can be distributed anyhow as sources, so there's no problem here
> either. Nobody could claim that there's a problem distributing GPLed sources
> alongside with anything.

As a mere aggregation (both on the same CD), no, as a single piece of
work that requires A, yes.

> So where's the catch? Can a compilation be seen as a copyright infringement?

No, only distribution (conveyance in v3), which is quite well defined,
but you need to apply a serious effort to parse it.

As Guy wrote, you are on shaky ground. I think you have been given
enough food for thought that shows that there are issues. How
important these issues are is out of your control - it is up to your
customers to decide. GPL is a complicated license in practice, and I
strongly suggest that you stop thinking in  terms of "GPL for
evaluation" - it simply does not accommodate the notion of a
specific/limited purpose or scope. If you want to think in terms of a
dual license then it's a different matter, and you will need to decide
how it fits your business model.

Again as Guy wrote, the Vendor A - Business B - Consultant C triangle
will have many fewer problems if you choose LGPL rather than GPL. The
problem that remains (among those already mentioned - there may be
others) in this case is A's possible problem with Mr. C who may use
A's code to directly compete with A. But Mr. A may decide it is OK,
even though he won't necessarily know in advance who Mr. C is.

-- 
Oleg Goldshmidt | pub at goldshmidt.org



More information about the Linux-il mailing list