Questioning EXPORT_SYMBOL_GPL()

Posted Jun 24, 2014 10:07 UTC (Tue) by dlang (guest, #313)
In reply to: Questioning EXPORT_SYMBOL_GPL() by geertj
Parent article: Questioning EXPORT_SYMBOL_GPL()

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.