| |||||||||||||
Yaghmour: Extending Android's HALYaghmour: Extending Android's HALPosted Jul 14, 2012 7:17 UTC (Sat) by paulj (subscriber, #341)In reply to: Yaghmour: Extending Android's HAL by karim Parent article: Yaghmour: Extending Android's HAL
Android uses user-space .so "modules" to interface with hardware. Such files, per the kernel's own licensing, are off-limits to the GPL The kernel's licence does not say such files are off-limits - this belief of yours is completely unfounded. The Linux COPYING says that "user programs that use kernel services by normal system calls" are not subject to the kernel's licence.
(Log in to post comments)
Yaghmour: Extending Android's HAL Posted Jul 14, 2012 12:20 UTC (Sat) by karim (subscriber, #114) [Link]
So, just to make sure I understand your point of view, are you saying:
a) that user-space libraries are not "user programs"? or b) the use of std fileops to talk to hardware from user-space makes callers of said fileops subject to the kernel's license? or c) that somehow the kernels used in Android devices expose new APIs not already exposed by the kernel? (keeping in mind that the Android kernel add-ons have now been merged into mainline) or d) something else I'm missing? or e) a combination of the above?
Thanks in advance for clarifying this for me.
Yaghmour: Extending Android's HAL Posted Jul 14, 2012 16:24 UTC (Sat) by paulj (subscriber, #341) [Link]
I'm saying your comment seemed to suggest that you thought that the kernel licence automatically granted *any* user-space code a get-out from the kernel GPL licence, but that such an interpretation is not justified by the actual licence. The kernel licence foreword clearly constrains the exception to apply only to userspace programmes that use "normal system calls".
Now, whether some specific bit of user-space code does or does not meet the criteria, I don't know. I couldn't tell you either with any authority. You should consult a good lawyer specialising in this kind of thing, if there is doubt that matters to you. ;)
Yaghmour: Extending Android's HAL Posted Jul 14, 2012 16:53 UTC (Sat) by karim (subscriber, #114) [Link]
Ah, it all makes sense now. For a second there it seemed to me like you were playing lawyer yourself and branding the Android HAL as somehow contravening to the kernel's license :)
We're all safe, then, no lawyers needed here ;)
Yaghmour: Extending Android's HAL Posted Jul 15, 2012 8:00 UTC (Sun) by cmccabe (guest, #60281) [Link]
> I'm saying your comment seemed to suggest that you thought that the kernel
> licence automatically granted *any* user-space code a get-out from the > kernel GPL licence, but that such an interpretation is not justified by > the actual licence. The kernel licence foreword clearly constrains the > exception to apply only to userspace programmes that use "normal system > calls".
The note is there to clarify that userspace programs are not derived works of the kernel. This would have been true even if the note hadn't been posted, but the intention was to make it clear.
The recent Google vs. Oracle case should lay to rest any doubts about whether APIs are copyrightable (such as the API between the kernel and user space). The answer is no. Copyright doesn't flow through APIs. I think it's irresponsible to suggest that this issue is uncertain.
Yaghmour: Extending Android's HAL Posted Jul 15, 2012 8:57 UTC (Sun) by paulj (subscriber, #341) [Link]
No, it's not possible to say that the Linux GPL foreword is a clarification of what would already be true. While it almost certainly would be true for any app using widely implemented Unix APIs, it still would not be universally true for all userspace apps on Linux.
Also, I think you've taken too broad an implication from the Google v Oracle case. Just because an API is not copyrightable, does not mean that an API is automatically a boundary for copyright derivation.
Yaghmour: Extending Android's HAL Posted Jul 15, 2012 13:24 UTC (Sun) by nix (subscriber, #2304) [Link]
Quite. An extreme case that should demonstrate it: you write a (probably useless in practice) FFI that exports arbitrary kernel function calls into userspace, so userspace can make a function call, it's translated into some ioctl() by a library and then back into the function call on the kernel side. Something using this machinery in userspace would, one hopes, be considered a derived work of the kernel, or the concept is meaningless.
Yaghmour: Extending Android's HAL Posted Jul 15, 2012 14:34 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
Well, SystemTap allows to do exactly this. I'm using it to hook into the OOM killer: http://serverfault.com/questions/381759/how-to-find-which... Does that make it a derived work? Probably. But what if I've used a static tracepoint instead?
PS: to guys who unexported the 'kallsyms_lookup_name' function. I hate you.
Yaghmour: Extending Android's HAL Posted Jul 15, 2012 17:28 UTC (Sun) by butlerm (subscriber, #13312) [Link]
>Something using this machinery in userspace would, one hopes, be considered a derived work of the kernel, or the concept is meaningless.
The idea that using _any_ kind of interface that does not involve incorporating actual code makes something a derived work is somewhere between an exercise in wishful thinking and a legal fantasy. Who came up with this idea? It is positively preposterous.
The legal definition of a derived work is simple. A new work is a derived work if it is "based on" a prior work - meaning it incorporates content from the prior work, content that merits copyright protection in the first place. A fork of the kernel is a prototypical example of a work "based on" the kernel. _Nothing_ that merely talks to the kernel that does not itself contain substantial content copied from the kernel is based on the kernel.
Works that communicate with the kernel might be said to be based on kernel interfaces, but in America at least, courts are wise enough to know that extending copyright protection to interfaces would lead to no end of absurdities. Linux would be illegal, Microsoft would retain a copyright interest in all Windows applications, drivers would require licenses from hardware manufacturers, executables would require licenses from processor manufacturers, and on and on.
There wouldn't be any faster way for the free software movement to commit suicide than to get the idea that functional interfaces are deserving of copyright protection enshrined into law.
Yaghmour: Extending Android's HAL Posted Jul 15, 2012 19:09 UTC (Sun) by bjartur (guest, #67801) [Link]
The theory is that bundling works that would be useless without the others makes the bundle a derived work of the components.
I reckon that GPLv2 triggers only on "distribution," (whatever that means) and thus this should only be a concern for software vendors (including vendors of hardware that contains Linux).
Yaghmour: Extending Android's HAL Posted Jul 16, 2012 6:26 UTC (Mon) by butlerm (subscriber, #13312) [Link] The theory is that bundling works that would be useless without the others makes the bundle a derived work of the components.That is an interesting theory, but the status of a composite work (such as a distribution) is a separate question. The question at hand is whether mere functional compatibility makes component A a derivative work of component B. There certainly isn't a trace of that in the definition:
A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a “derivative work”. (17 USC 101) Oddly enough whether a work is usable or not has nothing to do with it. It isn't an issue that copyright law touches on at all.
Yaghmour: Extending Android's HAL Posted Jul 17, 2012 16:01 UTC (Tue) by bjartur (guest, #67801) [Link]
What if the components are a novel and annotations? Or a textbook and errata? Or a kernel and an extra driver?
I believe the errata in and of it self to be an original work. But when bundled with the textbook, the composition surely must constitute a derived work. Annotations are usually useless without the annotated work. This article does, on the other hand, not forbid reviews, for example.
Drivers bundled with a kernel can similarly be considered as "elaborations, or other modifications which, as a whole, represent an original work of authorship."
Obviously, IANAL. Additionally, I don't speak English natively, and am in fact quite uncertain as to whether I'm interpreting the last sentence of your quotation of 17 USC 101 correctly.
Yaghmour: Extending Android's HAL Posted Jul 15, 2012 22:30 UTC (Sun) by paulj (subscriber, #341) [Link] A new work is a derived work if it is "based on" a prior work - meaning it incorporates content from the prior work, content that merits copyright protection in the first place. … _Nothing_ that merely talks to the kernel that does not itself contain substantial content copied from the kernel is based on the kernel. I'm not a lawyer, and I don't want to play one on TV either. However, I'm reasonably sure the above is quite incorrect, from my layman's understanding of corporate legal advice as well as >15 years of following free software. For one thing, there is US case law showing that copyright derivation can occur without any literal copying at all. As an aside: One thing I've learned is that programmers' often make the mistake, when it comes to legal issues, of approaching the law as if it were a precise machine, with deterministic outcomes. This is far from the case. Further, with respect to copyright issues and derivation particularly, programmers often assume that the technical boundaries they are familiar with (APIs, function calls, memory address spaces, sockets, networks) must have legal meaning and map clearly to legal boundaries (I used to think that way). However, that isn't the case. The legal space can completely ignore such technical boundaries quite easily, if it wishes, and perhaps focus instead on apparently abstract, subjective details. Basically, what have I learned is that programmers often suck at legal issues. Particularly wrt copyright derivation issues: you'll be very hard pressed to get precise, objective guidance from a lawyer on when exactly a work does and does not derive from any other. Which means programmers should probably be wary about attempting to give such guidance.
Yaghmour: Extending Android's HAL Posted Jul 16, 2012 6:52 UTC (Mon) by butlerm (subscriber, #13312) [Link]
I am not making a positive argument here, I am making a negative one. In other words, I don't have to prove anything except to point out that others are spreading legal rumors without any justification. If this ridiculous conception of a derivative work has any basis in fact, let them bring forth their citations and their legal arguments rather than propagate an imaginary conception of copyright law on a wide audience.
Yaghmour: Extending Android's HAL Posted Jul 16, 2012 11:19 UTC (Mon) by paulj (subscriber, #341) [Link]
Well, start by noting that the laws were discussing tend not to contain any mention of functions, kernels, userspace, etc. Further, the case law on this, that has defined how copying and derivation should be judged are extremely abstract (google for "abstraction filtration comparison test" and have a look at the wording for what is a deriving work). Indeed, they may have developed in the context of cases to do with non-technical copyrighted works, and so clearly will not make any reference to computer technicalities. I.e. the law on this operates at a much more abstract level.
The FSF and the SFLC also seem to disagree with your claim. E.g. there would be no need for the LGPL if your claims were correct. Using the GPL on libraries would be effectively the same as the LGPL in your view, if "interfaces"[1] automatically were a barrier to copyright derivation, or if the mechanics of DLLs somehow meant one code linking to another did not "incorporate"[1] the other (and thus, can't derive as you seem to claim).
Basically, it is your claims that appears the unusual one, at odds with years of practice across the Free Software world, and in software generally. It's also at odds with my personal knowledge of actual legal advice (which is hearsay to you, admittedly). It is your claim that needs to be substantiated.
The best advice, if this kind of thing matters to someone, is to go ask a good lawyer about the specifics of a case.
The worst thing to do, if you have code that calls other code, is to assume that because you as a programmer can see a clear distinction between the 2 (e.g. because of function calls, or IPC, or XML-RPC, etc), that therefore your code can not be subject to the licence of the other. Or, to listen to legal advice from anonymous commentators on technical forums to the same effect… ;)
1. What does this mean exactly? I bet you can come up with a technical definition, but that doesn't mean it has any legal meaning.
Yaghmour: Extending Android's HAL Posted Jul 16, 2012 13:52 UTC (Mon) by fuhchee (subscriber, #40059) [Link]
"it is your claims that appears the unusual one, at odds with years of practice across the Free Software world"
Note that the FSF has an interest in broadening the application of their policies/licenses, so a public relations overreach in this direction would not be hard to fathom.
"and in software generally"
How so? Can you point to situations where e.g. extension / patch for some proprietary software was deemed "derivative" in the copyright sense?
Yaghmour: Extending Android's HAL Posted Jul 16, 2012 20:12 UTC (Mon) by rqosa (subscriber, #24136) [Link] > there would be no need for the LGPL if your claims were correct Not in the case of statically-linked binaries — because those include copies of parts of the static library, they are clearly derived works of the library, so the LGPL's "linking exception" is necessary there. There's also the case of libraries with header files that contain actual code (e.g. preprocessor macro functions or C++ template functions), not just interface definitions.
Yaghmour: Extending Android's HAL Posted Jul 17, 2012 1:37 UTC (Tue) by butlerm (subscriber, #13312) [Link]
>The FSF and the SFLC also seem to disagree with your claim. E.g. there would be no need for the LGPL if your claims were correct.
On the contrary, distribution of GPL/LGPL software requires compliance with the terms of the license. If the license said (for example) you cannot jointly distribute this item with anything that we frown upon, you would have to follow those rules or lose the right to distribute completely.
The issue with derivative works governs only those who distribute independently. If the secondary work is not a derivative work, the producers of the original work have no copyright interest in it. The authors of the secondary work can distribute it however they feel like unless they require a license to the original work. If they do require such a license, the licensors can make them do practically anything - from standing on their heads every morning to providing free technical support.
Yaghmour: Extending Android's HAL Posted Jul 16, 2012 7:25 UTC (Mon) by cmccabe (guest, #60281) [Link]
Unfortunately, your "extreme case" completely misses the point.
It's true that if you apply a patch to the running kernel from userspace, that patch is probably a derived work of the kernel. And if you have some debugger-like interface that allows you to make arbitrary function calls, your debugging script may also be a derived work.
But neither of those things is an API. An API is a stable interface that abstracts away the implementation of the functionality.
If FreeBSD added some of the same system calls that Linux has, that wouldn't make it a derived work of Linux, any more than Linux is a derived work of SysV UNIX because it implemented most of the SysV system calls. That is the meaning of the Oracle vs. Google ruling.
We should all be thankful that this is the case. Otherwise open source and free software would become impossible. Let's be done with this issue.
|
|||||||||||||