Questioning EXPORT_SYMBOL_GPL()

By Jonathan Corbet
June 23, 2014

There have been arguments about the legality of binary-only kernel modules for almost as long as the kernel has had loadable module support. One of the key factors in this disagreement is the EXPORT_SYMBOL_GPL() directive, which is intended to keep certain kernel functions out of the reach of proprietary modules. A recent discussion about the merging of a proposed new kernel subsystem has revived some questions about the meaning and value of EXPORT_SYMBOL_GPL() — and whether it is worth bothering with at all.

Loadable modules do not have access to every function or variable in the kernel; instead, they can only make use of symbols that have been explicitly "exported" to them by way of the EXPORT_SYMBOL() macro or one of its variants. When plain EXPORT_SYMBOL() is used, any kernel module is able to gain access to the named symbol. If the developer uses EXPORT_SYMBOL_GPL() instead, the symbol will only be made available to modules that have declared that they are distributable under a GPL-compatible license. EXPORT_SYMBOL_GPL() is meant to mark kernel interfaces that are deemed to be so low-level and specific to the kernel that any software that uses them must perforce be a derived product of the kernel. The GPL requires that derived products, if distributed, be made available under the same license; EXPORT_SYMBOL_GPL() is thus a statement that the named symbol should only be used by GPL-compatible code.

It is worth noting that nobody has said that symbols exported with plain EXPORT_SYMBOL() can be freely used by proprietary code; indeed, a number of developers claim that all (or nearly all) loadable modules are derived products of the kernel regardless of whether they use GPL-only symbols or not. In general, the kernel community has long worked to maintain a vague and scary ambiguity around the legal status of proprietary modules while being unwilling to attempt to ban such modules outright.

Shared DMA buffers

Recent years have seen a fair amount of development intended to allow device drivers to share DMA buffers with each other and with user space. A common use case for this capability is transferring video data directly from a camera to a graphics controller, allowing that data to be displayed with no need for user-space involvement. The DMA buffer-sharing subsystem, often just called "dma-buf," is a key part of this functionality. When the dma-buf code was merged in 2012, there was a lengthy discussion on whether that subsystem should be exported to modules in the GPL-only mode or not.

The code as originally written used EXPORT_SYMBOL_GPL(). A representative from NVIDIA requested that those exports be changed to EXPORT_SYMBOL() instead. If dma-buf were to be GPL-only, he said, the result would not be to get NVIDIA to open-source its driver. Instead:

For example, in the future, if we can't agree on using EXPORT_SYMBOL, then if somebody were to introduce a laptop that had a Tegra GPU (which uses GPL-compatible open-source Linux drivers) and a GeForce GPU (which is, as described above, supported by our existing binary driver) then I imagine we'd have no choice but to re-implement a different open-source buffer allocation mechanism for Tegra that could be used between the two, or just continue using our existing nvhost code. This, along with every other SoC's version, is exactly what the dma-buf project was intended to replace.

At the time, a number of the developers involved evidently discussed the question at the Embedded Linux Conference and concluded that EXPORT_SYMBOL() was appropriate in this case. Other developers, however, made it clear that they objected to the change. No resolution was ever posted publicly, but the end result is clear: the dma-buf symbols are still exported GPL-only in current kernels.

On the fence

More recently, a major enhancement to dma-buf functionality has come along in the form of the fence synchronization subsystem. A "fence" is a primitive that indicates whether an operation on a dma-buf has completed or not. For the camera device described above, for example, the camera driver could use a fence to signal when the buffer actually contains a new video frame. The graphics driver would then wait for the fence to signal completion before rendering the buffer to the display; it, in turn, could use a fence to signal when the rendering is complete and the buffer can be reused. Fences thus sound something like the completion API, but there is additional complexity there to allow for hardware signaling, cancellation, fences depending on other fences, and more. All told, the fence patches add some 2400 lines of code to the kernel.

The fence subsystem is meant to replace Android-specific code (called "Sync") with similar functionality. Whether that will happen remains to be seen; it seems that the Android developers have not said whether they will be able to use it, and, apparently, not all of the needed functionality is there. But there is another potential roadblock here: GPL-only exports.

The current fence code does not export its symbols with EXPORT_SYMBOL_GPL(); it mirrors the Sync driver (which is in the mainline staging area) in that regard. While he was reviewing the code, driver core maintainer Greg Kroah-Hartman requested that the exports be changed to GPL-only, saying that GPL-only is how the rest of the driver core has been done. That request was not well received by Rob Clark, who said:

We already went through this debate once with dma-buf. We aren't going to change $evil_vendor's mind about non-gpl modules. The only result will be a more flugly convoluted solution (ie. use syncpt EXPORT_SYMBOL() on top of fence EXPORT_SYMBOL_GPL()) just as a workaround, with the result that no-one benefits.

(A "syncpt" is an NVIDIA-specific equivalent to a fence).

Greg proved to be persistent in his request, though, claiming that GPL-only exports have made the difference in bringing companies around in the past. Graphics maintainer Dave Airlie, who came down hard on proprietary graphics modules a few years ago, disagreed here, saying that the only thing that has really made the difference has been companies putting pressure on each other. Little else, he said, has been effective despite claims that some in the community might like to make. His vote was for "author's choice" in this case.

Is EXPORT_SYMBOL_GPL() broken?

Dave went on to talk about the GPL-only export situation in general:

Personally I think _GPL is broken by design, and that Linus's initial point for them has been so diluted by random lobby groups asking for every symbol to be _GPL that they are becoming effectively pointless now. I also dislike the fact that the lobby groups don't just bring violators to court.

The last sentence above might be the most relevant in the end. For years, the kernel community has muttered threateningly about proprietary kernel modules without taking much action to change the situation. So manufacturers continue to ship such modules without much fear of any sort of reprisal. Clearly the community tolerates these modules, regardless of its (often loud) statements about the possible legal dangers that come with distributing them.

Even circumvention of EXPORT_SYMBOL_GPL() limitations seems to be tolerated in the end; developers will complain publicly (sometimes) when it happens, but no further action ensues. So it should not be surprising if companies are figuring out that they need not worry too much about their binary-only modules.

So it is not clear that EXPORT_SYMBOL_GPL() actually helps much at this point. It has no teeth to back it up. Instead, it could be seen as a sort of speed bump that makes life a bit more inconvenient for companies shipping binary-only modules. A GPL-only export lets developers express their feelings, and it may slow things down a bit, but, in many cases at least, these exports do not appear to be changing behavior much. The fence patches, in particular, are aimed at embedded devices, where proprietary graphics drivers are, unfortunately, still the norm. Making the interface be GPL-only is probably not going to turn that situation around.

Perhaps one could argue that EXPORT_SYMBOL_GPL() is a classic example of an attempt at a technical solution to a social problem. If proprietary modules are truly a violation of the rights of kernel developers, then, sooner or later, some of those developers are going to need to take a stand to enforce those rights. The alternative is a world where binary-only kernel drivers are distributed with tacit approval from the kernel community, regardless of how many symbols are marked as being EXPORT_SYMBOL_GPL().

As with the dma-buf case, no resolution to the question of how symbols should be exported from the fence subsystem has been posted. But Greg has said that he will not give up on this particular issue, and, as the maintainer who would normally accept a patch set in this area, he is in a fairly strong position to back up his views. We may have to wait until this code is actually merged to see which position will ultimately prevail. But it seems that, increasingly, some developers will wonder if it even matters.

Index entries for this article
Kernel	Copyright issues
Kernel	EXPORT_SYMBOL_GPL
Kernel	Modules/Exported symbols

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 23, 2014 20:56 UTC (Mon) by nix (subscriber, #2304) [Link] (41 responses)

Dave said:

But anyways, has someone checked that iOS or Windows don't have a fence interface? so we know that this is a Linux only interface and any works using it are derived? Say the nvidia driver isn't a derived work now, will using this interface magically translate it into a derived work, so we can go sue them? I don't think so.

Quite. I note the flap a while back about ktime_get() use. I cannot believe that anyone seriously thinks that getting the time is a Linux-specific concept, or that things that want to know what time it is must necessarily be deeply interwoven with the kernel and have been written with nothing but Linux in mind from the start -- yet ktime_get() was marked as a GPL-only export. FWIW, I'm certain that iOS and Windows both have time-getting functions... the real reason for this marking was probably 'this was horribly hard to get right so it feels wrong if proprietary modules can benefit from our hard work' -- but EXPORT_SYMBOL_GPL isn't meant to be a 'this was a hard bit' marker, is it?

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 23, 2014 22:37 UTC (Mon) by airlied (subscriber, #9104) [Link] (27 responses)

Yup this is exactly my problem,

if we stick _GPL on every symbol no matter what, then it doesn't help anymore to distinguish a derived work, since we aren't making any distinctions anymore, we are just playing monkey see, monkey do.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 8:29 UTC (Tue) by drago01 (subscriber, #50715) [Link] (26 responses)

Trying to enforcing copyright through technical means never worked (see DRM) and will never work ... its pointless.

So we should just do s/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/ and be done with it. If some module is not GPL licensed and is a derived work and someone cares enough take it to court.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 13:40 UTC (Tue) by Funcan (guest, #44209) [Link] (24 responses)

EXPORT_SYMBOL_GPL *is* useful should anybody wish to take it to court though... it makes it *very* clear of the author's opinion of the status of derived works, which can guide the court's. It certainly removes the 'It never occured to us it could be a derived work' argument from the table.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 14:10 UTC (Tue) by roblucid (guest, #48964) [Link]

Exactly "On the value of EXPORT_SYMBOL_GPL()" http://lwn.net/Articles/154602/ covers that point.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 14:33 UTC (Tue) by PaXTeam (guest, #24616) [Link] (17 responses)

> It certainly removes the 'It never occured to us it could be a derived work' argument from the table.

not really as you don't need to read (and consequently know about) the EXPORT_SYMBOL_GPL line of code to be able to find a reference to the actual symbol somewhere on the net in some example/tutorial/whatever. now if the symbol's name *itself* had a _GPL or similar suffix then it'd be an argument to make but that's not the case now.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 14:41 UTC (Tue) by nmav (guest, #34036) [Link] (16 responses)

The EXPORT_SYMBOL_GPL is not for the developer to see. It is for the linker to deny access to the symbol if the module being compiled is not under GPL. So finding the symbol somewhere on the net and using it in your non-GPL module wouldn't work.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 15:32 UTC (Tue) by slackwill (guest, #85173) [Link]

Perhaps on NVIDIA's train of thought, I wouldn't want a surprise linker failure for a critical interface to my module either. I would say it's certainly for the developer to see and take heed of well before they begin a project.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 22:27 UTC (Tue) by PaXTeam (guest, #24616) [Link] (14 responses)

the linker (e.g., GNU ld) doesn't know about EXPORT_SYMBOL_GPL.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 22:59 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (13 responses)

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.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 17:06 UTC (Tue) by zlynx (guest, #2285) [Link]

Sure unless people keep diluting it until it means nothing. Keep marking basic functions as GPL only and soon it is useless.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 19:22 UTC (Tue) by airlied (subscriber, #9104) [Link]

But it doesn't anymore if the symbols are diluted to the set of all new symbols, a court would realise there was no process to distinguish or thought given when _GPL was appropriate!

Questioning EXPORT_SYMBOL_GPL()

Posted Jul 15, 2014 20:40 UTC (Tue) by garyamort (guest, #93419) [Link]

" it makes it *very* clear of the author's opinion of the status of derived works"

Actually, based on the discussion here, due to the method it is being applied it doesn't make it at all clear of the authors opinion.

The authors opinion was apparently quite clear, the patches did not include those flags. It was requested to be added after the fact by the maintainer and by now the discussion has had negative impact - all it would take is printing out the discussion and submitting it as evidence that the author was coerced into making the change and it is quite reasonable to assume that the flag is not a technical indicator, but merely a social statement.

Note: I think Greg is quite justified in making a technical decision that he feels it should have that flag and then discuss it with the author - at the same time making it quite clear that the author is the one who will make the final call and that he will accept whatever decision they make. That would provide strength to the use of this flag as far as court cases are concerned.

He is also quite justified to reject the changes because he doesn't feel comfortable with them not having that flag.

I'm simply pointing out that the debate weakens the effectiveness of this flag as the debate is quite clearly not based solely on technical grounds, but includes ideology - which is very human and important and certainly welcome - it just does not and should not have any impact on legality.

Questioning EXPORT_SYMBOL_GPL()

Posted Jul 16, 2014 19:07 UTC (Wed) by psusi (guest, #95157) [Link] (1 responses)

No, it can not. The court does not give a damn about the opinion of the author, nor whether the accused was or was not aware of that opinion. The only thing it cares about is whether the driver is a derived work or not, and it clearly is not, otherwise we would not have any open source Windows software or drivers because they too would be derived works violating Microsoft's copyright. "Derived work" means either a modified version of the kernel, or an aggregate that contains the kernel. It does NOT mean a program made to interact with the kernel.

There is also nothing to stop them from setting the flag declaring the module to be GPL when it isn't.. it isn't like defining a linker symbol is a legally binding license, so this whole GPL nonsense is a pointless waste of breath.

Questioning EXPORT_SYMBOL_GPL()

Posted Jul 16, 2014 20:55 UTC (Wed) by tao (subscriber, #17563) [Link]

However: once an infringement has been established, the court will take into account whether such infringement can be seen as intentional or not. If the symbols used were marked as "If you use this symbol you're very likely to be creating a derived work", then this makes it a bit hard for the driver writer to claim that the infringement wasn't intentional.

Questioning EXPORT_SYMBOL_GPL()

Posted Jul 9, 2014 20:52 UTC (Wed) by nix (subscriber, #2304) [Link]

EXPORT_SYMBOL_GPL() was never meant to be 'DRM', though: it's trivial to turn it off locally, and not illegal in any way.

What it was meant to be was a marker of *opinion*: 'it is my opinion that using this symbol makes a work so deeply intertwined with the kernel that it must necessarily be derived from it'.

Whether it means anything at all to have non-lawyers making such determinations is one matter. Whether it means anything at all when some people adding symbols clearly believe that *everything* should be so marked and that asking what time it is makes you a derived work... that's the issue here. I mean, sheesh, if turning on lock debugging makes you a derived work, suddenly, without changing a single bit of your code, what on earth message does that send, other than 'this mechanism is ridiculous'?

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 23, 2014 23:28 UTC (Mon) by bug1 (guest, #7097) [Link] (11 responses)

"I cannot believe that anyone seriously thinks that getting the time is a Linux-specific concept"

A concept is not copyrightable (it might be patentable), this issue is just about copyright.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 7:15 UTC (Tue) by geertj (guest, #4116) [Link] (10 responses)

> A concept is not copyrightable (it might be patentable), this issue is just about copyright.

The reasoning is that if something is *not* a Linux specific concept, that an implementation using it should not be considered a derivative work under copyright, and hence the GPL does apply to it.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 10:07 UTC (Tue) by dlang (guest, #313) [Link] (9 responses)

the thing is that copyright covers only the implementation, not the idea. so as long as the implementation is linux specific, anything using that implementation is a derivitive of linux.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 11:34 UTC (Tue) by neilbrown (subscriber, #359) [Link] (2 responses)

I thought that copyright only covered novel creative expression.

So if there is something novel and creative in the interface which the module needs to use, then the module would be derived. But if the interface uses terminology and formats which are common in the literature, or obvious and purely functional, then it is hardly novel or creative.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 14:06 UTC (Tue) by roblucid (guest, #48964) [Link]

Yes, and whilst (INAL disclaimer applies) furthermore the term "Derivative works" are intended to give copyright protection to a creative work based on another, with legal systems trying to protect both.

It's not the scenario people are thinking of when they assume derivation as a negative to be feared, but something more like the Android scenario, which may distribute GPL code with it's copyrights protected, be a derivative work, yet have other parts protected.

So, it can be argued even if some blob is "derivative", that doesn't mean the code legally should be GPL-ed. The key is whether it is distributing a modification of GPL-ed code, a hard argument to make if no modificaiton is required to load a binary blob no matter what symbol is used, even if it modifies the non-redistributed memory copy of the kernel that is not breaking GPL. Hence the legal justification of shipping of blobs seperately from distro's but making them available for seperate distribution by repo.

Seems to me, the whole EXPORT_SYMBOL_GPL idea is relying on a need to make insufficiently creative modifications to the GPL source, in order to circumvent it, for instance in the "GPL Condom" design pattern.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 29, 2014 5:01 UTC (Sun) by fergal (guest, #602) [Link]

Patents require novelty because you're patenting the idea, which is a general thing and you get to assert rights over all implementations of that idea. Copyright applies to a specific expression of an idea and only requires novelty in terms of not directly copying something that exists already.

A simple photo of a building can be copyrighted, there is no novelty there.

Anyway the question is not what is copyrighted but what makes a derived work.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 12:36 UTC (Tue) by oshepherd (guest, #90163) [Link] (5 responses)

Utter nonsense!

Because the Linux implementation of POSIX is Linux specific, any app using POSIX interfaces on Linux is a derivative of Linux?

I think what you intended to say is more along the lines of "As long as the interface is linux specific, anything using that implementation is a derivative of linux"

Yet I could go and re-implement that same interface for, say, FreeBSD. Is the driver still a derivative of Linux, when that same interface exists on another platform? Of course not.

The only real circumstance in which some code could be classified as a derivative of Linux, IMO, is quite simple: When the code is inextricably tied to the internals of Linux. When it dives right into the implementation of Linux, when it is so inextricably tied to Linux that any "compatibility layer" would be a derivative work of Linux.

Saying that a fence interface - of which many can be found in the wild - is in some way a derivative work of Linux is utter tripe and nonsense.

The whole EXPORRT_SYMBOL_GPL thing is really quite silly.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 14:46 UTC (Tue) by nmav (guest, #34036) [Link] (4 responses)

Yes it is. The only reason you don't have to GPL your userspace code, is the fact that the Linux kernel provides an exception for using its interfaces in userspace programs (see the kernel code license at https://www.kernel.org/pub/linux/kernel/COPYING).

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 15:43 UTC (Tue) by sfeam (subscriber, #2841) [Link]

That is not "the only reason". It is "one sufficient reason [among others]".

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 29, 2014 22:08 UTC (Sun) by dvdeug (guest, #10998) [Link] (2 responses)

If I write ISO standard Fortran 77, you can hardly claim that that that is a derivative of the Linux kernel. Nor if I write for the JVM not using any interface that is Linux specific can you claim that it is a derivative of the Linux kernel. If I should distribute my code and my users should chose to use it on Linux of all the systems they could choose, I hardly see what that would be my problem.

Note also that this is not an argument we should be making. GCC has some Windows-specific code, as does many, many other programs. If works written for Linux would be GPL except for that clause, then Windows could declare that GPL code can't legally be written for Windows.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 30, 2014 2:10 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (1 responses)

It could still be derivative depending on how strongly you depend on the API Linux provides. If you have a core which is cross platform and adapt that to kernel X, the shim is definitely derivative, but the core would not be (as I see it).

A thought experiment: If a BeOS driver layer were implemented for Linux, would all historical BeOS drivers suddenly become Linux-derived when loaded?

Questioning EXPORT_SYMBOL_GPL()

Posted Jul 3, 2014 14:07 UTC (Thu) by nye (subscriber, #51576) [Link]

No need to carry out a thought experiment, given the existence of NDISwrapper.

Questioning EXPORT_SYMBOL_GPL()

Posted Jul 12, 2014 17:21 UTC (Sat) by mina86 (guest, #68442) [Link]

You, my friend, are spreading FUD. If you want to access CLOCK_MONOTONIC use getnstimeofday. If you want CLOCK_MONOTONIC_RAW use getrawmonotonic. Often all you need is jiffies. There are plenty of ways to get time, and likely reason for ktime_get being EXPORT_SYMBOL_GPL is that it returns time in ktime_t.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 7:56 UTC (Tue) by kugel (subscriber, #70540) [Link] (18 responses)

> I also dislike the fact that the lobby groups don't just bring violators to court.

Right, all the _GPL talk is entirely moot if there's never a reaction to actual infringment.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 13:21 UTC (Tue) by spender (guest, #23067) [Link] (17 responses)

Exactly. A few months ago I had directly mailed Linus, Dave Miller, Greg KH, and Al Viro about a company shipping binary-only kernel modules that a disassembly proved were using internal kernel headers. They were also shipping kernel RPMs without an associated SRPM. In several cases, what they did was take a GPL kernel module, link it with a license time bomb, and then label the entire module as "proprietary." None of the developers I mailed even responded.

Empty threats only makes the problem of enforcing the GPL more difficult for the rest of us. I found that a multi-billion dollar company had been shipping my software in their devices sold around the world for several years -- all without any customer knowing they had purchased a product using free software. There was no corresponding source shipped with the devices, nor any written offer for any source. They had actually developed an entire packaging system around my RBAC system, too, so it wasn't any kind of casual use but an integral component of the product.

Since I don't have millions of dollars to throw away on legal fees, I learned that it's basically impossible to take these guys to court. The only way I could have gotten a lawyer in the US to take on the case on a contingency fee would be if they could make enough guaranteed money on it to cover their costs. As I (and most other) developers haven't filed for formal copyright registration, we aren't entitled to statutory damages in court for copyright infringement. The lawyers also would have an uphill battle in court proving monetary damages as the software is given away for free. More than that, though very unlikely, there was a chance if taken to court, I could be held responsible for the court fees of the infringer! Ultimately they were not able to take the case because of these things -- apparently the justice system in this country is only accessible by rich companies. I have not received even a single penny from the company in question, and yet they're profiting massively from it as it's a key component of their products' PCI compliance. Think about that whenever you swipe your credit card at some store virtually anywhere in the world.

If nobody actually enforces the GPL, we might as well rename it to BSD, because that's how companies are using it. Begging companies to obey the willfully-ignored license of software they're profiting off is not enforcement. Why should a company have to come up with a legitimate business plan around GPL'd software when companies can just wrap that GPL'd software with a license time bomb to force customers to keep paying for its use, in broad daylight, without any affected developers saying a peep about it?

-Brad

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 13:45 UTC (Tue) by Funcan (guest, #44209) [Link] (9 responses)

Were any of the several GPL enforcement groups in the US able to help you? They reason d'etre is to provide assistance in such cases, and have a reasonable history of getting settlements

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 15:10 UTC (Tue) by spender (guest, #23067) [Link] (8 responses)

No, because their idea of enforcing the GPL is just getting them to comply with the license after their willful infringement. I had contacted Harald Welte too but he didn't respond to my mail. The lawfirm he works with could have pursued the case in Germany (I contacted the law professor directly), but with the way the courts work there it's easier to "win" GPL cases, but there's still really no punishment -- the company just gets forced to comply with the GPL after the fact. I contacted the SFLC too but it was an entire month before I heard anything back, and that was only in response to a mail I sent to the busybox developers to let them know the copyright on their work had been infringed too -- my first mail to the SFLC had apparently been ignored.

-Brad

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 16:18 UTC (Tue) by krake (guest, #55996) [Link] (6 responses)

> No, because their idea of enforcing the GPL is just getting them to comply with the license after their willful infringement.

How is getting license compliance a bad thing?

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 16:51 UTC (Tue) by spender (guest, #23067) [Link] (5 responses)

Consider the case I was in: the company was shipping products which due to their nature are difficult to reverse-engineer: there's physical anti-tamper, etc on them. One day a hacker breaking apart one of the devices managed to pull up a service menu item that dumped the kernel log, which happened to contain a message making it clear they were using my software. So because no one knew it was using my software in the first place, they were able to benefit and profit from using it for years. What good does compliance now that they've been caught in their willful infringement do in making any kind of disincentive for other companies against just ignoring the GPL until you get caught? If the people "enforcing" the GPL keep settling out of court for just compliance, this kind of corporate culture is just going to continue.

-Brad

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 18:20 UTC (Tue) by smurf (subscriber, #17840) [Link] (2 responses)

So what else do you want? Them to cough up money? To whom and for what, if no actual monetary damages can be demonstrated?

Typically, resolution of these cases doesn't just result in "we'll comply with the license in the future". It also results in am (undisclosed) donaion to free software companies, and a promise of substantial pain to the infringer (as in "an injunction against selling these devices in $COUNTRY") should they continue not to comply with the license.

This result may not be what you want, but it's the best we can get – and it's much better than letting it slide, not getting source, and encouraging the next infringer (or the next product of this company) to also not publish any sources. :-(

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 19:25 UTC (Tue) by spender (guest, #23067) [Link] (1 responses)

I just don't get this very passive view where a company can just steal code and profit off it without obeying the rules of the license. If I wanted 13 years of effort to be exploited for some other company's benefit, I would have BSD-licensed my code. But I didn't BSD-license it -- it's GPL for a reason. They can't have it both ways; if they don't like the license then they shouldn't be using the software.

What we really need to be telling developers is to formally register their copyright. While people are quick to point out that you have the copyright when you create a work, this causes people to assume they get all the rights involved with having a copyright along with that. If you want to do anything other than meaningless, ignored threats, you need to register your copyright. It's the only way you can sue for statutory damages and attorney's fees. Registering a copyright is very cheap and doesn't need to be done by a lawyer:
http://www.copyright.gov/circs/circ61.pdf

-Brad

Questioning EXPORT_SYMBOL_GPL()

Posted Jul 3, 2014 10:44 UTC (Thu) by Wol (subscriber, #4433) [Link]

> What we really need to be telling developers is to formally register their copyright.

And if you're not a USAian? I don't want anything to do with the American Legal System. That rule is just yet another example of the US using its legal system to rip off the rest of the world's IP ... :-(

Cheers,
Wol

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 25, 2014 6:52 UTC (Wed) by krake (guest, #55996) [Link] (1 responses)

> So because no one knew it was using my software in the first place, they were able to benefit and profit from using it for years.

That's true for any kind of unlawful behavior, isn't it?

Neither law nor exemplatory brutal punishment make unlawful behavior go away.

What kind of verdict do you think a court could reach in a GPL infringment case that would be more benefitial than what you can reach in a settlement?

Questioning EXPORT_SYMBOL_GPL()

Posted Jul 9, 2014 7:29 UTC (Wed) by rich0 (guest, #55509) [Link]

The purpose of punishment isn't really to fix the case you brought to court, but to deter others from doing the same.

Scenario A:
If you violate the GPL there is a 5% chance that you'll be asked to stop violating the GPL or there will be a court case which has a 30% chance of forcing you to stop violating the GPL.

Scenario B:
If you violate the GPL there is a 5% chance that you'll be asked to pay a $10M settlement or you'll sued with a 30% chance of having to pay $100M in addition to being forced to stop violating the GPL.

In scenario A the cost of non-compliance followed by immediate acquiescence is zero, so there is no incentive to follow the license.

In scenario B the cost of non-compliance followed by immediate acquiescence is $500k on average. A manager making the decision to violate the GPL has to factor a $500k hit into his budget, recognizing that he is rolling the dice.

Companies are out to make money. A "risk" to them is something that could cost them money. Right now GPL enforcement creates no real risk to a company - they get the benefits of violating the GPL and the only real downside is that they might or might not get to do it forever.

Questioning EXPORT_SYMBOL_GPL()

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

AFAIK, SFLC ceased doing GPL enforcement a long time ago, so I'm not surprised at their response. The fact that they didn't tell you Conservancy was enforcing the GPL for Linux as well as BusyBox was somewhat disingenuous of them. If you don't already know, I was the primary person doing the GPL enforcement work at SFLC, and I have not worked there for many many years, in large part because my boss there didn't like enforcing the GPL. I do GPL enforcement at Conservancy now.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 15:49 UTC (Tue) by etienne (guest, #25256) [Link]

> a multi-billion dollar company ... license time bomb ...

They don't do bombs, they help to catch terrorists by helping to do total surveillance - following secret laws.
For that reason, they are protected by the government and you can't touch them (good investment for the company).
One day, one of these company will take some bad decision and nearly go bankrupt, the public will then be informed that this company is "too big to fail".
You are probably not allowed to put a "software bomb" in your own code to detect them and erase yourself, due to these secret laws.
Would be nice to live in a democracy, wouldn't it?

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 16:47 UTC (Tue) by SEJeff (guest, #51588) [Link] (1 responses)

Brad, perhaps you should talk to Harald? He has been quite successful at forcing companies to comply with the GPL:

http://gpl-violations.org/index.html

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 16:53 UTC (Tue) by spender (guest, #23067) [Link]

See my comment here:
http://lwn.net/Articles/603338/

-Brad

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 20:47 UTC (Tue) by kugel (subscriber, #70540) [Link] (1 responses)

I wonder why you don't name the company? Do you have any reason to play nice with them?

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 21:35 UTC (Tue) by spender (guest, #23067) [Link]

I don't really have any reason -- the company is VeriFone. Their code center (http://www.verifone.com/support/code-center/) is surely still not in compliance; they're just linking to upstream versions of code, despite the fact that they've modified it (like mine). More than that, it's years old and full of dead links to code that doesn't exist anymore because they're using years-old versions of some software. I am not really interested in paying them money to acquire one of their products to find out if they're still failing to provide a written offer for the source code they don't provide with the product itself.

Having already explored every option already, even if I were to find that they're still not providing the written offer or any source code, there's nothing I can do about it. The only thing I can do is post the source code I demanded from VeriFone's Director of Engineering which is now already out of date:
https://grsecurity.net/~spender/vos-2-6-31-grsec2-1-14.tgz
https://grsecurity.net/~spender/petro-grsecurity-20140211...

-Brad

Questioning EXPORT_SYMBOL_GPL()

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

I suggest that you send violation reports on Linux to <compliance@sfconservancy.org>, to report them to the GPL Compliance Project for Linux Developers. As far as I am aware, this is the only group of Linux copyright holders actively doing enforcement on Linux (now that Harlad Welte has moved on to other things).

Questioning EXPORT_SYMBOL_GPL()

Posted Jul 3, 2014 10:40 UTC (Thu) by Wol (subscriber, #4433) [Link]

> and yet they're profiting massively from it as it's a key component of their products' PCI compliance.

Whether it'll be any help to you I don't know ...

But in the UK try making a formal criminal complaint. Copyright violation is a criminal offence when committed for monetary gain (or something like that). The bar is moderately steep but it's an option. It might be worth it ...

Cheers,
Wol

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 25, 2014 2:10 UTC (Wed) by KaiRo (subscriber, #1987) [Link]

There's the common German idiom of "Wer A sagt, muss auch B sagen" - "they, who say A, have to say B as well". If *you* define something as EXPORT_SYMBOL_GPL(), then *you*m have to care that it's only used in compliance with that. If you can't, then defining it this way was probably useless as well.

It's about the USERS

Posted Jun 25, 2014 9:24 UTC (Wed) by dgm (subscriber, #49227) [Link]

If it's about forcing evil corporations will, or about satisfy developer's ego, then I think EXPORT_SYMBOL_GPL() would have no value.

Where it has a great deal of value is on future-proofing user's investments on hardware. If the devices I choose to buy use those symbols I have a good chance of fixing their drivers, should I need to in the future. This is a deal breaker for me, as we are all very aware that kernel interfaces are not set in stone, as per Linus' current policy.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 26, 2014 12:42 UTC (Thu) by mlankhorst (subscriber, #52260) [Link]

The problem is that the original fence code can still be called from !GPL modules by using the android sync code, which has normal exports and in the patch series is going to use dma-fence. This means that using EXPORT_SYMBOL_GPL changes very little.

Questioning EXPORT_SYMBOL_GPL()

Posted Jun 27, 2014 0:20 UTC (Fri) by gerdesj (subscriber, #5446) [Link]

"Perhaps one could argue that EXPORT_SYMBOL_GPL() is a classic example of an attempt at a technical solution to a social problem."

As an end user and sysadmin of GPL software, I have no problem with devs attempting to push their sociological agenda through their own works. I can always pay to have a corporation's own desires foisted on me instead if I disagree with them.

In general I find that people who write software for libre usage have fewer intrusive demands on me, my wallet and my life whilst delivering far more value in many ways than the alternatives.

_GPL could be seen as a diluted mechanism and somewhat devisive in some areas but the original reasons for its existence are still valid and I would far rather deal with some lack of functionality than lose yet more rights to use my device as I see fit.

One day perhaps even the binary blob might be a thing of the past - it bloody wont be if we cave in completely and _gpl is a small part of that overall dream.

Cheers
Jon