Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 22:59 UTC (Tue) by mjg59 (subscriber, #23239)
In reply to: Questioning EXPORT_SYMBOL_GPL() by PaXTeam
Parent article: Questioning EXPORT_SYMBOL_GPL()

The kernel module loader knows about it. Attempting to reference a _GPL symbol without MODULE_LICENSE("GPL") (or compatible) will fail at runtime.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 23:56 UTC (Tue) by PaXTeam (guest, #24616) [Link] (12 responses)

no, long before that modpost will complain about it.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 25, 2014 0:09 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (11 responses)

modpost may complain, but it's obviously possible for someone to circumvent that with little difficulty. The module loader will refuse to load a module that attempts to use GPL symbols unless there's a compatible license tag - see check_symbol() in kernel/module.c. Failure to load ought to be a pretty clear argument against the "It never occurred to us" defence.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 25, 2014 6:54 UTC (Wed) by PaXTeam (guest, #24616) [Link] (4 responses)

well, i don't see how modpost is easily circumventible while check_symbol isn't. also consider that in a company that has its own fork of the kernel one programmer may not even be aware of such changes in their tree while developing code that uses an EXPORT_SYMBOL_GPL symbol. not saying that it's a legally defensible act but it can happen.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 25, 2014 21:35 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (3 responses)

If you hack modpost so you can build a module that references a _GPL symbol and then send that module to a customer, the module won't load. You'd need to modify their kernel too, and there's no way you could argue that you were distributing a modified kernel without being aware of the nature of the symbols you were using.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 25, 2014 21:44 UTC (Wed) by PaXTeam (guest, #24616) [Link] (2 responses)

you don't need to distribute a modified kernel for this, you can just load a GPL module first that patches the kernel then load the non-GPL module without any repercussions.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 25, 2014 21:45 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (1 responses)

And still claim that you're unaware of the symbols being flagged?

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 25, 2014 23:25 UTC (Wed) by PaXTeam (guest, #24616) [Link]

if it's done by a single person then obviously they cannot claim ignorance, in any other situation (i.e., pretty much all real-life companies) it's up to the courts to decide whether there's plausible deniability (for the person (ab)using the symbol, the company as a whole will probably still be held accountable).

EXPORT_SYMBOL_GPL() remains useful

Posted Jun 25, 2014 20:52 UTC (Wed) by bkuhn (subscriber, #58642) [Link] (5 responses)

As you might expect, I agree with mjg59. There are upsides *and* downsides to EXPORT_SYMBOL_GPL with regard to GPL enforcement. As Jon (more or less) points out in the main article, the issue of whether something is or is not a combined work under copyright is not and cannot be definitively determined by the fact that EXPORT_SYMBOL_GPL was used (or was not used). I don't see anything in the copyright statue mentioning EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL() -- at least in the USA. :)

However, EXPORT_SYMBOL_GPL() does a few things of value nevertheless. First, it shows that the copyright holder who added the symbol felt personally that modules that would combine via that symbol would be combined works in that copyright holder's view and subject to the terms of GPL. The original opinion of the copyright holder *will* matter in GPL enforcement cases to judges and juries.

Second, it requires that anyone seeking to make a proprietary module that combines via that symbol to actually assert their own license as GPL *or* modify Linux to patch out EXPORT_SYMBOL_GPL into EXPORT_SYMBOL. This helps show that they violated the license intentionally (when they violate). That's very helpful in court.

As to Dave's original comments featured in Jon's article that lobbying groups: First, I actually don't know of any lobbying groups that are involved here, but I suspect he means "groups of people who are pushing for enforcement". (Lobbying has a very specific meaning in the USA that Dave might not be aware of in the context of his more colloquial use of that word). However with regard to Dave's likely point that non-profit groups have fialed to take action of enforcement on this issue: that's inaccurate; in fact, they have. Conservancy is actively enforcing the GPL for Linux and is raising this issue of proprietary kernel modules directly with many violators. At some point, I suspect some violator will refuse to comply and we'll have to sue them. But the fact that lawsuits haven't started *doesn't* mean that enforcement isn't happening: lawsuits are always a very last resort, and frankly Conservancy has only been doing enforcement for Linux itself for a few years.

As for suing over the GPL more generally, Conservancy has done plenty of that and will do so again when/if the time and the facts are right.

EXPORT_SYMBOL_GPL() remains useful

Posted Jun 26, 2014 3:46 UTC (Thu) by airlied (subscriber, #9104) [Link]

Oh my lobby group was more at groups of kernel developers who ask for all symbols to get _GPL.

Surely for _GPL to have a meaning, different from non-_GPL exports some thought process should be used to distinguish when something might or might flag a derivative work. Flagging all new symbols as _GPL by default seems to me as if it would dilute the power.

i.e. you go to court and they ask the copyright holder developer, if he had any idea why he used _GPL and he says, Greg told me to.

EXPORT_SYMBOL_GPL() remains useful

Posted Jun 26, 2014 19:59 UTC (Thu) by roblucid (guest, #48964) [Link] (3 responses)

"felt personally that modules that would combine via that symbol would be combined works in that copyright holder's view and subject to the terms of GPL"

Is that actually a problem for the distributor of blobs?

1) They DO not distribute the kernel
2) They DO not modify the kernel files
3) They are specifically entitled by GPL to modify the program and are using a facility of the kernel to alter it in runtime memory only, without taking away the end-users GPL rights.

Remember copyright allows creative alterations to the copyright-ed work of others.

EXPORT_SYMBOL_GPL() remains useful

Posted Jun 28, 2014 2:50 UTC (Sat) by xtifr (guest, #143) [Link] (2 responses)

Yes, it's still a problem for distributors (more properly, for creators) of blobs. It hasn't been to court as far as I know, but the law takes intent into account, and the intent of such a thing is clearly to distribute a derivative work to end users, even if you carefully make the users grab one of the parts themself.

The most famous instance I know of is GCC's ObjectiveC backend. It was originally distributed by NeXT as a blob, but the FSF objected, and Steve Jobs, with all his mega-millions and hordes of lawyers, backed down and released the source under the GPL. Not precedent-setting, but unless you've got better lawyers than Jobs, I don't think it's the sort of thing you want to try yourself.

EXPORT_SYMBOL_GPL() remains useful

Posted Jul 1, 2014 22:55 UTC (Tue) by jwarnica (subscriber, #27492) [Link]

Jobs having millions, and NeXT ever having more than pennines in their accounts are different things. And "we will likely lose in court" isn't the only reason to end a case. "As it turns out, we don't care that much" is as (or more) likely in many cases.

EXPORT_SYMBOL_GPL() remains useful

Posted Jul 10, 2014 14:01 UTC (Thu) by roblucid (guest, #48964) [Link]

GCC didn't have at that time a load binary module interface or plugins - http://lwn.net/Articles/582697/ Next must have engaged in hackery, or they actually did what Wiki says, when they wanted to distribute their compiler externally -

According to http://en.wikipedia.org/wiki/Objective-C "The work to extend GCC was led by Steve Naroff, who joined NeXT from StepStone. The compiler changes were made available as per GPL license terms, but the runtime libraries were not, rendering the open source contribution unusable to the general public. This led to other parties developing such runtime libraries under open source license. Later, Steve Naroff was also principal contributor to work at Apple to build the Objective-C frontend to Clang." Can't find any news source, to back your version of events, nor can I remember any controversy surrounding gcc & objective C, though I do remember it included objective C option, about time Linux was reaching 1.0 release. Finally, Steve Jobs, had made and lost millions at that time, after leaving Apple which was a firm in financial difficulties, as was NeXT, having produced (expensive) workstations, very nice but ultimately failing to achieve real market penetration. I actually saw demo of NeXT kit and Jobs himself on tour in Paris, demo-ing OO as part of a Sun presentation day.

Linking dynamic or static, is not some base legal litmus test of "derived work". Again, looking at definition of derived work in Copyright, it does not necessarily have the effect that's generally assumed, so long as the derived work is creative.