Dropsafe

by Alec Muffett

The Lean and Hungry Nature of GPL Addicts…

Via Joerg came this link to Adam Leventhal, regarding Sun’s Open-Sourced “DTrace” software, and Linux, and what happens when some in the Linux community runs headlong into some desirable technology which is not apparently “ritually clean” enough for them to adopt:

Last week at OSCON someone set up a whiteboard with the heading “Tools We Wish We Had”. People added entries (wiki-style); this one in particular caught my eye:

dtrace for Linux
or something similar
(LIKE SYSTEMTAP? – jdub)
(NO, LIKE dtrace – VLAD)
(like systemtap, but not crap)

So what exactly were they asking for? […] Most simply (and least humbly) DTrace lets you express a question about nearly any aspect of the system and get the answer in a simple and concise form. And — this is important — you can do it safely on machines running in production as well as in development. […]

So is SystemTap like DTrace?

…and the posting continues, outlining the history of SystemTap and the stated “knockoff” qualities of it with respect to the cleanliness and elegance of DTrace.

What I find fascinating is the comments to the posting; to give him his due Matthew Garrett – a respected Linux guy – is toeing the party line on how the GPL works and from that the painfulness of adding DTrace to Linux, and therefore couldn’t Sun just relicense DTrace (or perhaps OpenSolaris) under the GPL and have done with it all?

The majority of core Linux contributors believe (based on legal advice) that it’s impossible to produce a loadable Linux kernel module without it being a derivative of the kernel code to some extent, and therefore having to fall under the GPL due to the GPL’s restrictions on derivative works. It’s not a situation that’s ever been tested in court, and clearly not everyone agrees – however, it’s plausible enough that there’s basically no chance of code being added to the core kernel for no purpose other than facilitating a set of non-GPLed kernel modules.

Really, the only way that you could guarantee a port of dtrace to Linux would be for it to be relicensed under a GPLv2 compatible license as well as the CDDL. Otherwise it’s likely to have to be a reimplementation.

Posted by Matthew Garrett on August 02, 2007 at 05:34 PM PDT #

…and he further does agree:

You’re right, though. The CDDL itself doesn’t make it impossible to port DTrace to Linux – the union of the GPL and the CDDL make it a problem.

…but continues:

Given that Linux has been under the GPLv2 for longer than DTrace has existed, though, it shouldn’t come as a surprise to anyone that the Linux community don’t feel able to take advantage of the code Sun have supplied.

…which argument <dig class=humour>also perhaps helps explain the dreadful state of Linux NFS.</dig>

Of course I am biased – or perhaps I just have an opinion? – but my opinion was not formed by my working for Sun.

Back in 1991, I had an exchange with RMS himself because I had released Crack, and therein was a potential source for a GNU implementation of the Unix password hash algorithm, crypt().

In a series of staccato e-mails, Richard wanted to know who were the authors of my “fcrypt” implementation, whether it was free, and whether he could ask us to do the FSF thing – the GNU copyleft notice, etc… He was most polite about the whole thing – at worst I would say a little abrupt, which is a common trait amongst programmers – yet the entire exchange left me feeling a little, I dunno, “collectivist”? Like I was being urged to join a church?

The result was that I was put-off GNU to the point of adopting the Artistic License instead, and was very happy with the results; but today I still hear the same echoes, that the GPL is the true book and anything which does not mesh with it is of itself in error…

I still don’t agree.

I’m also amused by the presumption that “if Sun want DTrace in Linux…” – of course I do not speak for the company as a strategic thinker on matters of open-source, but it strikes me that there’s a pretty obvious gap between Sun corporately wanting something, versus being perfectly happy for it to occur.

Not seeing the difference is presumably a consequence of believing that you are on the one true path.

⊞

Comments

9 responses to “The Lean and Hungry Nature of GPL Addicts…”

  1. Stephen Usher

    I’ve found this doctrine an annoyance as well. More of a religion than a logical reasoned debate.

    How dare you say anything against the one true license.. or is GPLv2 the new false license seeing as GPLv3 is now the one true doctrine. Heretic! Burn him! Burn him! 🙂

    As for the “If X wanted Y in the linux kernel then they should release it under the one true license” argument, well that’s just silly. Why *SHOULD* X care if it’s in the Linux kernel. It’s an idea of grandeur many Linux-ites have. Linux isn’t the ultimate OS.

    The arguments which really get me annoyed are the two stupid ones which are rolled out when the subject of a stable, well defined API for drivers comes up:

    (1) “We need to have a the ability to change the API at a whim so that we can constantly improve it and add new features for new hardware.”

    To which I answer, you should have thought harder about the logical abstraction first, then you wouldn’t have to constantly re-think things later.

    (2) “We need to be able to change the API to prevent closed source vendors from poluting the kernel with binary-only drivers.”

    This is really an ideological foot shooting contest.

    Reply
  2. Mikael Gueck

    I don’t really care who got there first, and who was following whom. I care of what value we can create.

    Reply
  3. alecm

    @Mikael: that sounds nice; alas not everybody works like that, and there is no requisite reason which forces them to try…

    Reply
  4. Matthew Garrett

    Oh, I don’t believe there’s any inherent superiority in the GPL over the CDDL (personally I’ll tend to use the GPL, but that’s a personal preference thing rather than anything else). The problem is the repeated implication by Solaris guys that the Linux community is actively rejecting DTrace, rather than the more straightforward reality that there are significant legal hurdles to manage before it would be practical.

    I’d tend to agree about RMS. I think he’s contributed a great deal of value to the world, but he’s also managed to turn a great many people away from GNU and any GPLed codebase.

    Of course, you’re right that there’s a difference between Sun being happy to see a port of DTrace and actively wanting to – but the fact that Sun employees repeatedly talk about how Linux could take advantage of the existing DTrace code makes it sound like there’s some desire there, even if it’s not any sort of official corporate policy. Sun owes Linux nothing, and they’ve contributed a great deal – I don’t expect them to relicense DTrace, but it would also be nice if people would accept that there are good reasons why people aren’t working on porting it.

    Reply
  5. Tel

    This strange feeling keeps coming to the surface that the Linux community somehow enjoy Puritanism and make a game out of being strict with license requirements.

    Let me tell you, nothing could be further from the truth. Copyright law is strict. Go away and read a Microsoft EULA and then study the implications of each and every paragraph that you are signing you name to and to a risk analysis of what could go wrong (in a legal sense). It’s a non-trivial exercise. Copyright law can come down on your head like an axe and there are plenty of folks out there who would just love to see it happen to the GPL community.

    Engineers want to create working machines, they don’t want to waste their lives as pseudo-lawyers. What the GPL provides is a guarantee that for all those who are happy to stick with the GPL, they are always safe sharing code with other members of the GPL community. They don’t have to study yet another complex set of licensing requirements for yet another useless minor variation on a theme because that is a total waste of time… time that should be spent writing code or doing something useful.

    The fact that Sun does not release DTrace under GPL is a clear indication that they have no interest seeing it get into Linux. Trying to force it into Linux is just a recipe for legal turmoil and big problems later on.

    Thus, if Linux needs similar capabilities (I’m not convinced it does) then reimplementation (possibly using a different mechanism to obtain a similar result) is the only answer — simple. Don’t waste time thinking out the detailed legality of license compatibility, spend the time thinking about the technical issues and making things work.

    Reply
  6. Adam Conrad

    You seem to fail spectacularly to actually get the point. It’s not about the One True License. The Linux kernel has been GPLv2 for eons, and it can’t BE relicensed, so that’s a reality we have to deal with. If you don’t like the GPL and the FSF, that’s your call.

    I’m more of an MIT/X11/BSD laissez-faire sort of guy myself, but you can’t just plug your ears and run around screaming “La, la, la, if you don’t want to port our incompatibly-licensed code to your kernel, it’s because you’re ideological nitwits, I CAN’T HEAR YOU,” and completely ignore the legal aspect of mixing code that’s incompatibly licensed.

    Matthew’s point is a valid one. If the Powers That Be who own the copyright want to see DTrace in Linux, they’ll drop it with a license that allows that. If not (and it would seem they don’t care, currently, which is fine), they won’t.

    Taking us to task for then not much caring about cleanrooming the kernel bits all over again so we can implement a feature because *you* tell us we should desperately want it (you’d think if we really, really wanted it, maybe it’s an itch we’d scratch?) is rather presumptuous on your part.

    Reply
  7. Stephen Usher

    Adam, I take your point on the GPL’d status of the Linux kernel and agree with it. It’s more the bitching and indignance by certain members of the Linux community when someone produces something useful and dares to not GPL it.

    The problem comes when certain kernel maintainers seem to try their hardest to break/hinder shims for device drivers. The shims themselves are GPL’d as required by the kernel but implement an interface which isn’t, and hence a non-derived work, should be able to link with it. (I know there are people who believe that even this is illegal but that would mean that the GPL was truely viral and would make any Windows wireless driver used via ndiswrapper covered by the GPL, which is, as you would probably agree, just silly.)

    The upshot of this idiological stupidity is that there is a great deal of work which has to be done retro-fitting all the affected kernel device drivers which, in turn, could add bugs and is anyway a waisted effort. It also means that orphaned drivers stop working pretty soon after the maintainers go away, negating one of the long-time trumpetted advantages of Linux, the ability to use old hardware. As I said, an idiological foot shooting contest.

    Ideally, for reasons of clean coding and reliability as much as the above, the maintainence of the core kernel and the drivers should be separated totally with a well defined set of documented programming interfaces on both sides which wouldn’t change within a major kernel version (and preferably have backward compatability with one previous version of the API). Other operating systems can do this and still innovate so why can’t Linux? I’m not talking about binary compatability here, ‘cos that’s a bit of a problem with different compiler versions, merely the API so that the source can be compiled.

    Reply
  8. Matthew Garrett

    Oh, I don’t believe there’s any inherent superiority in the GPL over the CDDL (personally I’ll tend to use the GPL, but that’s a personal preference thing rather than anything else). The problem is the repeated implication by Solaris guys that the Linux community is actively rejecting DTrace, rather than the more straightforward reality that there are significant legal hurdles to manage before it would be practical.

    Of course, you’re right that there’s a difference between Sun being happy to see a port of DTrace and actively wanting to – but the fact that Sun employees repeatedly talk about how Linux could take advantage of the existing DTrace code makes it sound like there’s some desire there, even if it’s not any sort of official corporate policy. Sun owes Linux nothing, and they’ve contributed a great deal – I don’t expect them to relicense DTrace, but it would also be nice if people would accept that there are good reasons why people aren’t working on porting
    it.

    Reply
  9. Matthew Garrett

    [duplicate posting elided]

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts