Re: [Ksummit-discuss] [CORE TOPIC] GPL defense issues

[Jeremy Allison <jra@samba.org>]

On Fri, Aug 26, 2016 at 05:19:55PM -0700, Linus Torvalds wrote:
> On Fri, Aug 26, 2016 at 4:58 PM, Jeremy Allison <jra@samba.org> wrote:
> > Can you describe the conditions you personally would feel justify
> > filing a lawsuit over GPL non-compliance ?
> 
> You asked Ted, but I'll answer for one of the conditions for me: that
> it is not some gray area. It has to be a pretty damn clear violation.
> 
> Quite frankly, I've seen a lot of people be confused about what the
> GPLv2 actually says over the years. The most common confusion is the
> whole thing about "linking". It gets mentioned a lot.
> 
> Not only is "linking" not something that has any legal meaning, but
> the GPLv2 doesn't even mention it.  Yet people _continually_ talk
> about linking.
> 
> I think the confusion actually comes from the FSF itself, and the
> original LGPL discussions, where the FSF at some point tried to
> convince people that linking against a GPL library somehow meant that
> the end result was a "derived work" in a very different way than "mere
> aggregation". It comes from some GPL maximalist argument, and it's
> where the whole LGPL came from, after all.
> 
> So a *lot* of people think that "linking" means that the GPLv2 is
> automatically in effect.
> 
> But what the license says - and more importantly, what copyright law
> itself actually is all about - is not linking, but "derived work".
> 
> And there's a _lot_ of gray areas there, and no, technical measures
> does not make something derived or not.
> 
> In the kernel, we have tried to kind of clarify our thinking with the
> whole module interface, and the EXPORT_SYMBOL_GPL() distinction - the
> argument being one of both intent (which does have some legal weight,
> although the key word there is "some") and just to clarify that some
> parts are so clearly "internal Linux implementation" that if you need
> them, you're clearly not an independent module.
> 
> But everybody should know that that is not necessarily black and white
> either. Are GPL'd shim modules that use that EXPORT_SYMBOL_GPL() and
> thjen export something else (non-GPL'd) that uses them legal? They
> certainly fail the _smell_ test. A technical trick doesn't really have
> any legal meaning. If I were a judge (and I'm not, not even a lawyer),
> I'd certainly frown on it, but I might not take the initial
> EXPORT_SYMBOL_GPL() distinction all that seriously _either_.
> 
> Anyway, end result is that there's a lot of very murky "what is
> actually a derived work" issues.
> 
> I'd not be interested in ever having a lawsuit to "clarify" such an
> issue. I don't think it would really clarify anything anyway (it will
> just set one boundary in one case for one specific thing).
> 
> So it has to be a pretty damn obvious violation.

So it's a "I know it when I see it" boundary, like porn or
indecency :-).

Actually, that was pretty damn helpful. At least it shows there
is a "this far and no further" line beyond which you think a
lawsuit can be appropriate. I was getting worried that there
was no violation so egregious that you'd think was worth legal
action.

That way lies BSD-land.. (and the mountains of Madness :-).

Actually, your feelings are pretty similar to mine (other than
the harsh words about the FSF, but then again they did kill
your dog :-).

I try and set a similar set of boundaries when it comes to
Samba - which can load the equivalent of kernel modules via
our pluggable VFS interface.

My rules are:

1). In kernel - not my business (unless you're crazy enough
to try and put the entirety of Samba in-kernel) - go forth
with my blessings.

2). In kernel-but with "special“ system calls used by Samba
VFS modules. Here I want the source code for the Samba VFS
module released, but what's in the kernel is your business.

Interestingly enough there have been some vendors who tried
to argue they could keep their system calls secret by hiding
the Samba VFS code - but we ended up with a successful outcome
(in one case by getting them to commit next release to a
fully specified syscall interface as the one they were using
was too ugly to support long term).

3). In a separate process - but Samba talks to it via IPC.
Still not my code, but it's getting closer depending on how
closely tied the IPC is. If your daemon simply won't do anything
without Samba talking to it, then I'd argue this is probably
a derived work. But it depends. This is the most difficult
case, similar to your "independent module" question above.

I usually say if the IPC interface has other uses than just
Samba (i.e. the NFS server uses it too), then it's not a
derived work. I've successfully gotten several companies
to architect their solutions this way to avoid any possible
violation questions. It usually gets them to create a better
solution as well, as thinking about an interface having to
be used by multiple consumers almost always ends up in a better
design.

4). Code modifications to Samba itself. You code is *mine*.
Unless you're Amazon of course, who run Samba4 Active Directory
in their cloud and never ship to their customers :-). Even then
they're slowly but surely getting their changes upstream by
contracting with one of the vendors who employ Samba Team
members.

There are many other grey areas, but the main thing I try
and do by enumerating these rules is to give clarity to
corporations wanting to use the code.

The only time we've ever come close to a lawsuit was a long
time ago with a company that just renamed the source code
files, added a license manager and tried to sell us as a
proprietary solution ! Even then it was only after we contacted
their main purchaser to let them know what they were buying
that these guys went back to stealing car radios, or whatever
previous petty criminality they used to make a living doing.

Having said that these are just my opinions, and I know there
are differing opinions within the Samba Team developers.

The main thing is that we all reach consensus before asking
Conservancy to take any action on our behalf. The other Team
developers trust Conservancy to act in a responsible way.

The way to ensure that happens is to join the Conservancy
"GPL Compliance Project For Linux Developers" so your
individual voice is heard. I'm sure they'd love to have
you ! :-).