What if there were a port of DTrace to Linux?
What if there were a port of DTrace to Linux: could such a thing be done without violating either the GPL or CDDL? Read on before you jump right to the comments section to add your two cents.
In my last post, I discussed an attempt to create a DTrace knockoff in Linux, and suggested that a port might be possible. Naively, I hoped that comments would examine the heart of my argument, bemoan the apparent NIH in the Linux knockoff, regret the misappropriation of slideware, and maybe discuss some technical details — anything but dwell on licensing issues.
For this post, I welcome the debate. Open source licenses are important, and the choice can have a profound impact on the success of the software and the community. But conversations comparing the excruciating minutia of one license and another are exhausting, and usually become pointless in a hurry. Having a concrete subject might lead to a productive conversation.
DTrace Port Details
Just for the sake of discussion, let’s say that Google decide to port DTrace to Linux (everyone loves Google, right?). This isn’t so far fetched: Google uses Linux internally, maybe they’re using SystemTap, maybe they’re not happy with it, but they definitely (probably) care about dynamic tracing (just like all good system administrators and developers should). So suppose some engineers at Google take the following (purely hypothetical) steps:
Kernel Hooks
DTrace has a little bit of functionality that lives in the core kernel. The code to deal with invalid memory accesses, some glue between the kernel’s dynamic linker and some of the DTrace instrumentation providers, and some simple, low-level routines cover the bulk of it. My guess is there are about 1500 lines of code all told: not trivial, but hardly insurmountable. Google implements these facilities in a manner designed to allow the results to be licensed under the GPL. For example, I think it would be sufficient for someone to draft a specification and for someone else to implement it so long as the person implementing it hadn’t seen the CDDL version. Google then posts the patch publically.
DTrace Kernel Modules
The other DTrace kernel components are divided into several loadable kernel modules. There’s the main DTrace module and then the instrumentation provider modules that connect to the core framework through an internal interface. These constitute the vast majority of the in-kernel DTrace code. Google modifies these to use slightly different interfaces (e.g. mutex_enter() becomes mutex_lock()); the final result is a collection of kernel modules still licensed under the CDDL. Of course, Google posts any modifications to CDDL files.
DTrace Libraries and Commands
It wouldn’t happen for free, but the DTrace user-land components could just be directly ported. I don’t believe there are any legal issues here.
So let’s say that this is Google’s DTrace port: their own hacked up kernel, some kernel modules operating under a non-GPL license, and some user-land components (also under a non-GPL license, but, again, I don’t think that matters). Now some questions:
1. Legal To Run?
If Google assembled such a system, would it be legal to run on a development desktop machine? It seems to violate the GPL no more than, say, the nVidia drivers (which are presumably also running on that same desktop). What if Google installed the port on a customer-facing machine? Are there any additional legal complications there? My vote: legit.
2. Legal To Distribute?
Google distributes the Linux kernel patch (so that others can construct an identical kernel), and elsewhere they distribute the Linux-ready DTrace modules (in binary or source form): would that violate either license? It seems that it would potentially violate the GPL if a full system with both components were distributed together, but distributed individually it would certainly be fine. My vote: legit, but straying into a bit of a gray area.
3. Patch Accepted?
I’m really just putting this here for completeness. Google then submits the changes to the Linux kernel and tries to get them accepted upstream. There seems to be a precedent for the Linux kernel not accepting code that’s there merely to support non-GPL kernel modules, so I doubt this would fly. My vote: not gonna happen.
4. No Source?
What if Google didn’t supply the source code to either component, and didn’t distribute any of it externally? My vote: legal, but morally bankrupt.
You Make The Call
So what do you think? Note that I’m not asking if it would be “good”, and I’m not concluding that this would obviate the need for direct support for a native dynamic tracing framework in the Linux kernel. What I want to know is whether or not this DTrace port to Linux would be legal (and why)? If not, what would happen to poor Google (e.g. would FSF ninjas storm the Googleplex)?
If you care to comment, please include some brief statement about your legal expertise. I for one am not a lawyer, have no legal background, have read both the GPL and CDDL and have a basic understanding of both, but claim to be an authority in neither. If you don’t include some information with regard to that, I may delete your comment.
15 Responses
Well, you could also check what’s happening in FreeBSD:
http://marc.info/?l=freebsd-current&m=117469583227359&w=2
Apparently there is a debate whether it is legal to link BSD code in the kernel with the CDDL headers of the module and keep the result distributable under BSD.
As a result of this debate, they won’t ship DTrace as part of FreeBSDv7..
So the licensing issues are not restricted to Linux 🙁 and no IMNL either, so I can’t comment..
Hello,
first, my legal background:
I’ve been working for two years in the free software office of my college reviewing the impact of free software license, open content license and open documents in the academic use, specially the impact of those license in final projects and how to handle the copyright requirements for it in that context.
I’ve been also cooperating with the Foundation for a Free Information Infrastructure to spread the word about the impact of free software patents among the college community.
Nowadays I’m working in the Sun Ray group assisting the opensource of APOC.
I’m not a lawyer anyway, but I have some knowledege regarding licensing.
Kernel modules are loaded with a simple ldload, which basically means, that once loaded, they linked on the same address space than the rest of the kernel.
From the FSF, we can read:
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.
Proprietary, in this context, means GPL incompatible code.
As an example of this interpretation, the Trolltech business model is exactly based on that clause, they have a dual license, GPL, if you want to do GPL compatible programs/libraries, and for the rest you have to pay developer license.
Regarding the nVidia violation, yes, they’ve violated the license. But that doesn’t mean that it’s legal, it only means that none has sued them yet about it.
Does that means that we should do the same wrong thing or pretend it to be right?
Now, a possibility might be a patchset and build-by-your-own model, that is factible and doesn’t violate the license as long as people don’t redistribute the binaries. But that would prevent the use of DTrace on lots of scenarios, and it wouldn’t be available on distributions, which would prevent the “DTrace everywhere” goal to happen, in fact, I think that it would delay it.
At some point someone has to relicense its software, either the linux kernel, or the dtrace/zfs/opensolaris code, and I can understand why people don’t believe us when we say “we want DTrace/ZFS everywhere” right two years after of choosing a GPLv2 incompatible license when the biggest market that we want to target is using that license
That doesn’t mean that CDDL is a bad license, neither GPLv2 is a perfect license, but is just hard to understand us when we have made the choices that we have made.
As I said in the previous post, both projects going to GPLv3 is the only exit that I see to have everyone happy, but I don’t know if that would be possible on the Linux front.
I have to disagree about your assessment that making changes and then not releasing the source is morally bankrupt. This is falling into the open source license trap, that somehow the goal is to produce opensource software, rather than to get work done. Both the GPLv2 and CDDL are very explicit on this point. Neither applies any restriction to derivative works that are created for your own use and not re-distributed. In fact, if Google wanted to port DTrace to Linux for use on its own servers, then the conflict between GPL and CDDL would not be a barrier at all and they would not have to resort to the “clean room” efforts you described. Only if it decided to distribute the result would there be a problem.
Sure, it would be nice for anybody that makes an improvement to any open source program to release that improvement to the world, but the freedom to modify a program to make it more useful to *you* was the driving force behind the original opensource movement. I find the statement that it is morally bankrupt to modify a open source program and not release the changes as source code even though you have not released the resulting executable to be tantamount to the idea that it is morally wrong to release your own programs without releasing the source code.
renoX,
It’s the opinion of Sun that the legality of what the BSD folks are trying
to do is clear and legitimate. My understanding is that they’re getting some
conflicting advice from the legal team at NetApp.
Alberto,
How exactly has nVidia violated the GPL? They release an independent binary,
but they haven’t incorporated it into a work covered by the GPL. Can you
explain your interpretation a bit more? Also, who would have the legal
standing to sue them and on what grounds?
Brian,
Perhaps I was being overly glib, but I do think it runs contrary to the spirit
of open source to make major advancements and then not release them back to
the community — especially if it actually were a company like Google who
professes great affection for
open source.
I am not a lawyer.
And I don’t think I should _need_ one to use open source code.
One question, though….
Why doesn’t Sun port DTrace to Linux?
John,
I guess the business case isn’t there for Sun to port DTrace to Linux. We’re not a big seller or deployer of Linux — someone in that space is most likely be keen to fund a port.
(FWIW, I have both @sun.com and @member.fsf.org email addresses).
Alberto, your understanding of both the GPL and of software licencing is slightly off in places, e.g.:
"This General Public License does not permit incorporating your program into proprietary programs."
This is wrong. The GPL explicitely grants a *blanket* useage licence. You may use GPLed code in ANY way you want, without restriction. Including incorporating GPLed code into your proprietary (or otherwise GPL incompatible) code.
The GPL restricts *REDISTRIBUTION* – this is a key point you seem to be unclear on, and a crucial distinction.
"Regarding the nVidia violation, yes, they’ve violated the license. But that doesn’t mean that it’s legal, it only means that none has sued them yet about it."
If no one has sued them, if no court has ever ruled on this, how can you state with such certainty that it is a licence violation? You are almost certainly not fully-informed for a start-off. E.g. you don’t know what is in the blob – by some accounts that’s code that was developed on Windows originally, or how that code was developed – likely the code in the blob is developed in such a way that NVs’ legal counsel considers sufficiently walled-off to be a copyright barrier. Finally, presuming NV aren’t deriving from GPLed Linux code (and there’s no evidence of such), as Adam replied, NV arent distributing anything but their own code – so they can’t be subject to the GPL through redistribution either. Many people may dislike binary-blob driver situations, but that no Linux developer has sued perhaps suggests none of them has ever received /real/ legal advice that they have any grounds to sue..
"Now, a possibility might be a patchset and build-by-your-own model,"
Eh, what about Adam’s suggestion? "Reimplement the kernel code (likely has to be anyway) and re-use the userspace code"? Copyright does not prevent cloning of interfaces, indeed isn’t Linux a perfect example of that?
My vote is that Adam’s analysis is spot-on. The Linux community, despite the hoopla some make about legality of non-GPL kernel modules, seem quite willing to make it easy for /users/ to combine their GPL kernel with GPL-incompatible kernel modules (and such combination is quite within users rights under the GPL!). I.e. I bet various Linux distributions "non-free" repositories would carry CDDLed DTrace kernel module packages..
Why does not Sun dual license DTrace under both CDDL and GPL and let the Linux guys do the port? May be GPL+exception that all GPLed changes be also dual licensed? Why not the same about ZFS? Sure enough Sun did GPL Java without worrying about forks etc.
Mayor West,
That’s been discussed at some length elsewhere, and is off-topic for this post. If you’re going to continue to comment, be sure to include some declaration of your background on the matter (posting under a pseudonym is fine).
[Legal Background. Similar to Adam, developer that has been exposed to much but more with a focus on export/import control due to my security interests ]
With respect the dual licensing. My personal stance is that dual licensing is the worst possible outcome in almost every case. Licenses such as the CDDL and GPL (all versions) are complex enough to understand on either own, it becomes very complex to understand how derivative works and merge and remerge under a dual licensing case. In my experience Dual licensing tends to result in two outcomes, forks to one of the licenses (thats a really bad outcome and is the same as having only used one license initially). The other is all contributions are made under both licenses, which in my opinion negates the whole reason for having to distinct liceneses. The upshot is that the only reason dual licensing for two OSI approved licenses appears to exists is to deal with assembly into a larger system and this can be solved in other ways.
Personally I think in this particular case the best way forward is for a Linux port to "just appear", once the code exists ways around the licensing debates will be found as it becomes clear that DTrace is what is reallly needed. Of course that requires someone to dedicate the time to do the port.
One of the linux community’s concerns with zfs is that of patents, and the same would likely apply to dtrace. Is there any reason to belay this concern?
My background – OSS developer who has studied OSS licenses for greater understanding and decision making on licensing my code.
Darren Said –
"Of course that requires someone to dedicate the time to do the port."
Most Linux developers’ license of choice is GPL (v2 to be specific) and unless they are certain that the work they are doing can be GPLed without any doubts, I bet you 1000 USD – no one will come forward and do the port.
Even companies like Google who were quick to kick off the ZFS/Fuse port since there were no license issues, will not even think of touching CDDL’ed (or for that matter any other GPL incompatible) code.
And even if someone did it, it would not be in mainline Linux kernel for sure and it will suffer from quality and maintenance problems just like any other out-of-tree Linux driver does – the pace of development/changes is so enormous that one would be totally wrong to even attempt to maintain any significant and non-trivial out-of-tree code that’s expected to integrate and function well with Linux kernel.
So what you are discussing here is totally vaporware – not realistic.
@Darren Moffat: I don’t understand how you can brush off dual licensing as if it had not interest, don’t you understand that there can be historical reason for which two existing set of code have different incompatible license and you want to release some code for both?
Relicensing the existing set of code as you suggest may not be possible for various reason.
Plus I agree with Adam West that a port is unlikely to appear in Linux, as the port wouldn’t be accepted in the main Linux kernel tree and wouldn’t be used by Linux distribution either (except maybe Gentoo where users are used to recompile their own kernel so it would be legal), so unless the port was made mainly for ‘private’ needs, it wouldn’t be interesting:
only users willing to recompile their own kernel could use the patch AND the one who does the port is stuck maintaining it out of tree..
Disclaimers: IANAL & IAAPPP (I’m a P*ss poor programmer 😉
I don’t know how hard it would be to do so, but couldn’t Linux developers just re-implement the kernel parts of DTrace (therefor eliminating any licensing issues), and then just port the userland bits?
Would it be a tremendously difficult task to just relicense the DTrace kernel bits under the BSDL or something?
Awful lot of fuss to move code from one free/open system to another =/