Mixing GPL and BSD code just takes care

Mixing GPL and BSD code just takes care

Summary: If you can keep someone on your team who is obsessive compulsive to ride herd on those with attention deficits, you're far less likely to find your whole team in court later on.

SHARE:

Theo de Raadt, from WikipediaThe Software Freedom Law Center has released a set of guidelines for projects that need to mix BSD and GPL code.

This follows a highly-publicized dispute over Atheros driver code for the Linux kernel, during which OpenBSD head Theo de Raadt and other OpenBSD leaders got, shall we say, testy. And you don't want to get a Canadian testy. Especially one who has lived in the Yukon. (That's de Raadt, right, from Wikipedia.) I know I don't.

The issue in the Atheros case were changes to an OpenBSD driver aimed at enabling 802.11 under a GPL license, which de Raadt called a "stealing our code thing." The SFLC decided that the new files were separately copyrighted works, but SFLC head Eben Moglen convinced most to release the code so it could be re-incorporated in OpenBSD.

Most, but not all. At this writing de Raadt has not publicly responded to the SFLC paper, which seemed to blame developer Nick Kossifidis' poor revision history for the Ath5k-branch at MadWifi-SVN being available only under the GPL.

Moglen did, however, win a key concession. "The Linux Wireless Team, along with some Madwifi developers, have indicated a desire to collaborate with the OpenBSD team working on ar5k," he wrote. Some Madwifi developers apparently remain mad.

The developer guidelines should be more important in the long run. In them, the SFLC urges developers to preserve all copyright notices in their code so the code's prevenance can be traced. It then set out a five-step process for making sure you stay out of trouble:

  1. Identify all contributors.
  2. Identify which contributions create a copyright interest.
  3. Secure permissions from current copyright holders.
  4. Create a system for tracking permissions on future contributions.
  5. Publicize the new licensing policy.

It all sounds pretty good, but let me add one very important addition. If you can keep someone on your team who is obsessive compulsive to ride herd on those with attention deficits, you're far less likely to find your whole team in court later on. Or on Theo de Raadt's bad side.  

Topics: Software, Open Source, Operating Systems, Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

4 comments
Log in or register to join the discussion
  • Who's stealing what?

    Before De Raadt compains about GPL boys "stealing" code, he better review his license. Don't proprietary companies "steal" BSD code when they make proprietary programs from BSD code? If that's allowed by the license, then why are the GPL people to be blamed for doing re-licensing the changes under another license?

    If anyone or anything should be blamed, it should be the permissive terms of the license. Other open source licenses don't allow code to be "stolen" in the same way. If De Raadt doesn't like he way BSD-licensed code is being re-licensed, then he should use a different license with stricter terms.
    mannyamador
    • The de Raadt complaint

      What de Raadt is complaining about is that OpenBSD code was placed into a GPL licensed program, and OpenBSD could no longer get access to it. Because that would be a GPL violation.

      What the SFLC is saying here is document everything to make sure we can sort it out later. And they seem to have negotiated a settlement under which most of the code at issue is again available under OpenBSD.

      Sorry about any confusion.
      DanaBlankenhorn
      • OK, I get it

        That was quick! Thanks!

        I've been going over some of the threads and it looks like much of what I was thinking has been covered.

        I wonder, though, about works derived from BSD code (with new code, enough to make a copyright cliam) but placed under a proprietary license: I guess that wouldn't make De Raadt too happy. The license, however, allows it. Perhaps this is what may have caused the GPL people to react negatively to De Raadt. They may have felt unfairly treated.

        It seems, though, that the SFLC's advice to document everytthing is good advice. If the "paper trail" is there, at least things can be worked out.
        mannyamador
  • One correction, one addition

    As one of the members of the MadWifi project I would like to correct one aspect of the article, and add some information on another.

    [i]Some Madwifi developers apparently remain mad.[/i]

    The reason SFLC only talks of "some MadWifi developers" here is that not all project members were involved in ath5k development at the beginning. So "some MadWifi developers" refers to those who have actively contributed code to ath5k, as those had to declare whether they would be willing to license their changes under the more permissive ISC license.

    Concluding that (some of) the other members don't want to colaborate with the OpenBSD developers is wrong.

    [i]... the Ath5k-branch at MadWifi-SVN ...[/i]

    Since it's mentioned here: we are currently discussing how to clean the situation about the ath5k branch. The discussion is still going on, but as it stands now we most probably remove the branch, restructure the Subversion repository a bit and then restart the "ath5k branch". That "branch" is intended to provide easier access to ath5k for people who don't want to mess with git and/or wireless-dev to test-drive ath5k. The branch is not meant for active development, but to mirror the development that takes place in wireless-dev.

    Bye, Mike
    otaku42