Shared publicly  - 
Ah, the "GPL Condom" design pattern, when will people learn that this isn't a valid thing to even attempt.

Oracle, you know better, please clean this stuff up...
Linus Torvalds's profile photoRich Freeman's profile photoSteven Rostedt's profile photoMatthias Urlichs's profile photo
.... em... based on Oracle's recent history... I'm pretty sure that no, they do not actually know any better. 
Or they just don't care... :-\ 
The link is mangled for me. Can't get to the right commit... what's it all about?
I think people will believe that linking to GPL code creates a derivative work when there's evidence beyond legal theories from the FSF and SFLC (and a few other organizations). There's a reason Google's own legal team doesn't consider at least dynamic linking, especially PHP-style at runtime, to be a derivative work. It's not a fringe theory.

While there's a long history now of courts supporting the GPL in clear-cut cases of modifying and redistributing code, we cannot say the same for the issue of linking.

I personally fear the linking argument of the FSF, given that it seems to make Firefox for Windows a derivative of Windows because it links to Microsoft's APIs. We can't make the linking-derivative claim for FOSS without making it for proprietary software, too. [1]

Just search commits for 6380cdfd, gitweb seems unable to handle the URL mangling.

Basically, they wrapped a GPL-only symbol in a function then exported it as "dtrace_gethrtime."

Doesn't something as useless as that get optimized out anyway?
Greg S
Firefox is perfectly usable without Windows. The same would not be true for GIMP plugins or GCC backends. The law does not hinge on particular engineering choices. If your code cannot be used without some existing body of code then the law doesn't care whether it's linked, communicates over pipes, or is even on different systems communicating by RPC, the new work is a derivative work because it isn't an independent work. 
+Will Marone No, gcc does not optimize that way. It's a function call with an exported symbol, after all.
 static const struct stacktrace_ops print_trace_ops = {
+<<<<<<< HEAD
        .stack                  = print_trace_stack,
        .address                = print_trace_address,
        .walk_stack             = print_context_stack,
+       .warning = print_trace_warning,
+       .warning_symbol = print_trace_warning_symbol,
+       .stack = print_trace_stack,
+       .address = print_trace_address,
+       .walk_stack = print_context_stack,
+>>>>>>> a99218c... Initial import of DTrace kernelspace code.

This is lovely.
Greg S - by your logic, every application is a derivative work of the operating system on which it runs. Linus explicitly disclaims such a thing - but he is neither a lawyer nor a judge, so treat that disclaimer with all the legal weight it deserves.
Tony: the GPL has an explicit operating system exception for that. 
I would be interested in any actual case law that supports the linking claim. I also have questioned whether it actually creates a derivative work in the legal sense of the term. 
I think someone needs to come up with two different terms for the two types of  "derivative works" people so easily confuse.  Most people go straight for "Source A and Source B are at some point written and at some point linked; Source B is GPL'd; is Source A derived from Source B?"  That's a hard question that starts out "maybe..."  The easier one that most people miss is "Source A and Source B are at some point written and at some point linked; Source B is GPL'd; A and B are distributed together; is (A+B) derived from Source B?"  That one seems much easier question that starts out, "Explain how it's not..."
+David Timothy Strauss As +Olivier Crête said, the GPL has an explicit exemption for proprietary system libraries.  If it's a component of Windows itself, the GPL allows you to link to it via the system library exemption.
I wonder if we should just make _GPL exports recursive - whenever a module uses a GPL export, and of its exports would be forced to be GPL-only too. 

It might not be workable for some of our own core modules (we do have modules that implement whole subsystems, like the sound module, and export lots of symbols to regular drivers), but the "GPL condom pattern" really is pretty annoying.
+Linus Torvalds I guess you can do that, but what stops people from just continuing to do what they're already doing.  They'll argue their sources aren't GPL, and that they're doing nothing wrong.  Simply having some other piece of code apply a symbol to them doesn't really change the legality of the situation one way or another, unless it is in the sense of being more up-front about your claim that this infringes.

Let A = 10k lines of code.  Let B=200 new lines of code intended to be combined with A.  Let C=A+B.  The argument people are going to make is that B is NOT a derivative work of A, but C is.  By that logic the in-memory linked (that is, with addresses resolved by the dynamic linker) non-GPL module plus the rest of the kernel is a derivative of the kernel, but the non-GPL module files on disk are not.  Since nobody distributes the in-memory image they would argue this is not a GPL violation.

By this logic there is little distinction between the LGPL and the GPL.  Clearly this is not the intent of those who use the LGPL vs the GPL, but ultimately what matters is what a court decides.  Can a copyright holder restrict linking?

And what is linking, anyway?  One program exports a list of symbols.  Another program imports them.  If you don't buy the whole SCO argument the names of the symbols themselves are an interface and aren't copyrightable, so their inclusion in the linking software doesn't make it a derivative work.  Then a linker goes and resolves a bunch of function calls between them, which isn't really a creative work.

Personally, I'd prefer that things work the way the way the kernel team intends them to work.  However, I'm not certain a court would agree.  If there actually is any testing of this in court I'd be interested.
+Rich Freeman I don't think it would change anything directly from a legal standpoint, but it would make
 (a) users more aware that somebody is doing questionable things

 (b) remove a "but but we didn't notice" excuse from people who are playing fast-and-loose games

I think (a) is the biggest issue: there are clearly dodgy users that are playing these games not because they think it makes it right, but because they want to hide their dodgyness from users.

But (b) is an actualreal  legal issue. You had better feel damn confident that you have copyright law on your side if the kernel keeps complaining and saying "I think what you are doing looks like a license violation".

I agree that technical measures should never trump common sense and law (the whole issue with DRM and copyright is certainly an example of where technical measures are a bad thing), but I do think that we can and should point out when things look excessively dodgy.

In other words: I don't think that "I only use non-GPL exports" in any way guarantees that you aren't violating copyright, the same way as I don't think the reverse is true. But using a GPL-only export sure as hell is a big red flag.
+Linus Torvalds Agree on that - it isn't unlike locking a window made out of glass.  It won't keep anybody from breaking in, but they can't argue they didn't realize you didn't want them inside.

Obviously copyright law wasn't really written with FOSS in mind which is why this stuff gets hazy.  Maybe that is to the advantage of FOSS, because after the lobbyists were done any copyright reform would probably not be to our liking...
+Morgan Freeman The lobbyists will prevent any copyright reform from happening in the first place. They like the current "extend copyright protection by 20 years, every 20 years" pattern just fine. Hell, they created it.
+Matthias Urlichs Copyright doesn't have a 20 year protection limit. IIUC, it's for life (and then some). I think you are thinking of patents.
+Steven Rostedt I am not thinking of patents. You misunderstood me: I didn't say it's 20 years long, I said it'll be extended by another 20 years – as soon as Disney's legacy is in danger of dropping into the public domain again.

Currently it's for life plus 70 years in the US. 70 years ago, US copyright was 17 years from the registration of the work, not your death, you could get it extended it for another 17 years, and that was that. (Assuming I remember that correctly.)
Add a comment...