Alan Shimel Should Stop Talking About Snort’s Licensing.

Thomas Ptacek | May 11th, 2007 | Filed Under: Industry Punditry, Uncategorized

Somewhere in a hypothetical world, where the streets are paved with taco shells and birds poop garnets onto unsuspecting passers-by, there’s a coder working on a brand new, non-buffering SMB/DCE/CIFS decode engine for Snort. She’s part of a team planning to build an open-source Windows desktop firewall product, under the terms of the GPL. This hypothetical person, who has halogen desk lamp bulbs instead of eyeballs, has standing to complain about licensing changes in Snort.

She wrote a really kick ass blog post about her concerns, but we can’t read it. We live in our world, where birds poop bird poop. But even in our world, there are people who feel they have cause to complain when SourceFire amends their license text. The difference is, in our world, those people aren’t open-source developers; instead, they’re companies that repackage GPL Snort and sell it for over $20,000 a pop [*]. I don’t know what they have instead of eyeballs.

Some context.

Snort is the most successful GPL security product ever produced. What does GPL mean? It’s pretty simple: you can download the source code to Snort for free and you can sell it to other people. What’s the catch? You have to publish your code, too. Any programs you publish that even touch Snort have to be GPL’d. The GPL “infects” code. That’s good, because it produces more open source code.

It’s worth restating: the only obligation the GPL imposes on a vendor who uses Snort is to publish their source code. The GPL does not mean you have to pay SourceFire to use Snort in your product.

Here’s a dirty secret of the industry: a lot of security vendors use Snort, as a kind of “instant IPS” product. There are tens of products that claim to block attacks coming over the network. No exaggeration: most of them probably exploit Snort.

This is not really a problem. You’re happy they do, because if they had to build that engine themselves, they’d screw it up. Marty screwed it up repeatedly while building Snort, and Marty’s leads a pretty smart team. People re-using Snort is good for the industry.

But there is a problem. Many of the companies re-using Snort aren’t honoring the license.

The GPL requires these companies to publish their source code. Not just the source code to Snort —- Marty does a fine job of publishing that code himself. They’re not allowed to keep their own code secret.

This is a good thing. Snort starts the open-source ball rolling. In exchange for being able to take an IPS product to market in 3 months instead of 24, other vendors keep it rolling. The community gets more and more open source security code to play with.

Companies that don’t do this are cheating.

It gets worse. Some of these companies compete directly with SourceFire. Sales of their products into SourceFire prospects make it harder for SourceFire to sell Snort. SourceFire makes less money, and has fewer resources to dedicate to Snort. All because these other companies, who don’t fund Snort, take Snort and sell it themselves.

Here is one totally fair reaction to this problem: revoke the GPL from future releases of Snort, and move to a proprietary license that forbids derivative products. It’s been done before. It sucks for all of us, because we lose the freedoms the GPL guarantees. But it saves developers from being strangled by their own code.

That’s not what SourceFire did. Instead, SourceFire simply reminded the community what the GPL means. Products derived from Snort are themselves GPL’d, whether the authors like it or not. What does “derived” mean? SourceFire says, you’re “derived” from Snort if your product:

  1. Integrates source code from Snort. For example, by fishing out and repurposing the Snort TCP reassembly engine or the Microsoft CIFS/SMB decode.

  2. Includes Snort copyrighted data files. For example, by using Snort’s signature database with your own intrusion detection engine.

  3. Integrates/includes/aggregates Snort into a proprietary executable installer, such as those produced by InstallShield. For example, by creating a desktop IPS product that relied on Snort.

  4. Links to a library or executes a program that does any of the above where the linked output is not available under the GPL. For example, by fishing out and repurposing the Snort TCP reassembly engine into a new program, itself GPL’d, and then using that program as the engine for a third proprietary product.

There is nothing controversial about this definition. To put it into context, replace “Snort” with “MySQL”, and ask if you can:

  1. Embed MySQL into a commercial Microsoft Access clone which is not itself GPL’d.

  2. Copy MySQL’s SQL documentation into the help text for that commercial Access clone.

  3. Quietly install MySQL alongside your commercial Microsoft Access clone when you run its installer.

  4. Use the “mysql” command line console to communicate with MySQL when users type queries into your commercial Microsoft Access clone, so as to avoid “embedding” MySQL.

Apparently, this stuff is not well understood to Alan Shimel of StillSecure. Alan claims that SourceFire’s “clarification” changes the GPL. He claims that if he wanted, he could “fork” the Snort project, from the last release under the “original” license, and ignore SourceFire’s definition of “derivative works”. I claim that Alan is smoking something strange. The meaning of the GPL is clear.

Alan links to an article that attempts to “clarify” this subject. This article is crazy talk. It says, in part,

2) The meaning of derivative work will not be broadened to include software created by linking to library programs that were designed and intended to be used as library programs. When a company releases a scientific subroutine library, or a library of objects, for example, people who merely use the library, unmodified, perhaps without even looking at the source code, are not thereby creating derivative works of the library.

This directly contradicts the GPL. You cannot take a GPL’d library and “call into it” from non-GPL’d code. This is so well understood that there’s even a whole seperate license, the “Lesser” GPL (LGPL), that specifically allows you to link your code to an LGPL’d library without falling under the terms of the GPL. Lots of very important libraries, like “readline”, famously refuse to use the LGPL. You can’t use them in non-GPL’d code. If this wasn’t the case, Sleepycat, the authors of Berkeley DB, would have had no company, and Oracle certainly wouldn’t have paid tens of millions of dollars for them.

Why am I pointing this out? To be honest, I’m not sure. If StillSecure has modified Snort, or built code that links to Snort, or that executes Snort, and they haven’t GPL’d and published all of that code, StillSecure is violating SourceFire’s copyright and it liable for damages. SourceFire doesn’t need me to point this out. They have a legal department.

I think what it is is, this pisses me off. Set aside the license for a second. Building a commercial product that uses Snort as its engine and not compensating SourceFire or the community is unethical. If you build on Snort, pay SourceFire, or GPL your code, so you’re giving back to the community you’re taking from.

[∗]

Where does $20k+ come from? For starters, take the maintenance price of the box and divide by 15%.

[Update 4:10EST]

A commenter rightly points out the fork-and-exec exception in the GPL: linking to Snort code is covered by the GPL, but simply executing Snort or one of its programs isn’t.

Viewing 29 Comments

    • ^
    • v
    I applaud you sir. Well said. Here here.
    • ^
    • v
    I must say that this is probably *is* a change in the GPL; or, at the very least, a re-interpreation.

    They say a derived program is one that:

    "[E]xecutes a program that does any of the above where the linked output is not available under the GPL."

    This is classicly allowed under the GPL; I can have a closed-source program that calls "bc" and displays the output just fine. Don't believe me, check with GNU: http://www.gnu.org/licenses/gpl-faq.html#MereAg...

    Don't misunderstand me: I think SourceFire is 100% allowed to release Snort 3.0 under whatever license they wish to. They can define "derived product" in any way they like, including the versions pasted above.

    But that's not the GPL.
    • ^
    • v
    The GPL FAQ also has:


    I would like to bundle GPLed software with some sort of installation software. Does that installer need to have a GPL-compatible license?

    No. The installer and the files it installs are separate works. As a result, the terms of the GPL do not apply to the installation software.


    which makes me think that the 'clarification' with regards to including in an installer needs further clarification.
    • ^
    • v
    Dan you're obviously right. Sorry, I posted a correction.

    Note that I'm going much farther than saying that Marty has a right to change the 3.0 Snort license (which he hasn't /really/ done). I'm saying: if you can't abide by the terms Marty and his team set up for Snort 3.0, don't ship Snort in your product. At all.
    • ^
    • v
    I hate that you're right about this, Jason,

    What set me off about this post was Shimel's link to an article claiming you could link to GPL'd libraries without incurring the GPL. Nonsense.
    • ^
    • v
    Also there has been talks about anything that parses Snorts output would potentially be GPL'd as well.

    I dont think that sounds reseasonable under GPL either as for example any program that then reads from syslog on a *nix system has now been GPL'd.Nor do I think SF would want to really interperet it this way either as there proprietary programs such as RNA that read open sourced banners(like Apache) would technically be GPL'd.
    • ^
    • v
    I doubt that "things that parse Snort output" can be GPL'd, but will point out that because SourceFire owns copyrights to both Snort and RNA, nothing they do can make RNA "accidentally" become GPL'd.
    • ^
    • v
    Actually, point of clarification. Sourcefire owns a decent portion of Snort's sourcecode. Not all of it is ownd outright by Sourcefire. As such, if portions of Snort that were not completely owned by Sourcefire in RNA, then RNA would be GPLed by virus licensing.
    • ^
    • v
    The Nmap license has the following 'clarification' of what constitutes a derivative work:


    Executes Nmap and parses the results (as opposed to typical shell or execution-menu apps, which simply display raw Nmap output and so are not derivative works.)


    Such an addition to the Snort license could cause problems for Snort integrators that otherwise meet the conditions of the GPL (but the problem can be solved with an appropriate license arranged with Sourcefire, so its not the end of the world).
    • ^
    • v
    Jason wrote:

    I must say that this is probably *is* a change in the GPL; or, at the very
    least, a re-interpreation.

    They say a derived program is one that:

    “[E]xecutes a program that does any of the above where the linked output is
    not available under the GPL.”

    This is classicly allowed under the GPL; I can have a closed-source program
    that calls “bc” and displays the output just fine. Don’t believe me, check
    with GNU: http://www.gnu.org/licenses/gpl-faq.html#MereAg...>




    Aren't licenses fun? As was pointed out to me, this is part of the GPL too:

    Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.

    So, the output of a program can be restricted, depending on what the program does. For example, if I create a text editor then its output is directly contributed by me. The program itself is really only helping me manage my input (owned by me) and the output continues to be "owned" by me.

    Snort and Nmap on the other hand are gathering input independent of the licensee. The application is processes that input, and the application generates an output based on the work of the application, therefore, that output is licensed the same as the application. So, the theory is (and from what I understand, the FSF has supported this) any application that processes the GPL'd output must be GPL compatible.

    Bammkkkk
    • ^
    • v
    Thomas - here we go again. Don't blame me for what that lawyer wrote in his article. He wrote it, I merely point it out. However, frankly as an attorney with the OSI (which in the past you have told me controls, but does not own open source), I have to give his interpretation of the law a little more weight than yours. Yes maybe in your perfect world it works the way you say, but in the real world. What is derivative is not that easy to say and I frankly think this "clarification" is overly broad, as some other commentators have mentioned.

    As to what StillSecure has or has not developed, I can promise you that we will comply with whatever the law says we should do regarding proper licenses.
    • ^
    • v
    Your "lawyer for the OSI" invalidated Sleepycat's whole business model. Sleepycat was not a low-profile open source company.

    I really don't get why you feel comfortable talking about Snort's licensing, when companies like yours are basically the whole reason there's controversy about Snort licensing. What are you giving back to the community in exchange for forcing SourceFire (and Tenable) to be defensive about their licensing?
    • ^
    • v
    Also: if you think Marty's being too harsh with his licensing, why did StillSecure come up with its own fauxpen-source license, which prohibits commercial redistribution altogether?
    • ^
    • v
    Thomas - now you are finally understanding why we did what we did with our "fauxpen-source license". I don't think Marty is being to harsh at all. In fact I am very interested in working out a license agreement with Sourcefire. The GPL is all messed up when it comes to derivative though. This is the reason we did what we did. We could have used the GPL, but thought it would generate too much controversy over what we were trying to do. Better to use our own and say exactly what we mean and not let there be any controversy about it. At the end of the day, what we are saying with Cobia is very similar to what Marty wants with Snort, if you use it for your own use and don't seek to make a profit from it, it is free and have the source code too. If you profit from it, we want to profit from it as well. Dual license models.

    On selling products that have GPL software, Thomas the market regulates itself. If they did not think that there was any value in what we produce over and above Snort, they would not buy it.
    • ^
    • v
    It's not that it would "generate too much controversy". There's nothing controversial about your stance. You want people who use StillSecure source code to pay for the privilege, but you want to use SourceFire's code for free.

    What does this have to do with me? Well, as a result of your stance, vendors who could simply ship GPL software now have to contort their licensing to defend against companies like yours.

    The market will "regulate itself" the same way it "regulates" against spam. Unpleasantly.
    • ^
    • v
    "On selling products that have GPL software, Thomas the market regulates itself. If they did not think that there was any value in what we produce over and above Snort, they would not buy it."
    Oh well, when a discussion reaches the free market (or the "hitlerism") argument we all know it's time to walk away and go grab a beer.
    The very fact that an exec from one security vendor is "discussing" the changes to a license that a competing vendor made to *their* code -which the first vendors uses either for free or paying for it- is indicative of some business views within the security industry.
    @Alan: If you wrote your own code you wouldn't care about your competitor's license changes would you? If the new terms don't please you then get rid of Snort code in your product and write your own (code not just your own license), otherwise you'll have to continue living of Snort and paying the price. Or do you fear the market will "regulate you" if you do otherwise?
    • ^
    • v
    immoral: yup.
    illegal? Not so sure. GPL does in fact say you cannot link against it, but has this ever been tested in court? What are the odds that it would hold up? I'm skeptical (but not a lawyer).
    Not everything that is written by a lawyer is law.
    • ^
    • v
    Not to point out the blatantly obvious, but IPC over a named pipe or similar seems to eliminate the need for linking against a library (assuming one librarized Snort - I did at one point, but there's no good reason to)

    That being said, it's a sad but true fact that the vast majority of open source users contribute nothing back to the projects whose source code they're using. I'm not sure this is an important measuring stick, as seemingly legitimate as it might be.

    If anyone is genuinely surprised by a license change in a wildly successful piece of open source that has time and time again been poached in a predatory manner for incorporation in the most thinly veiled attempt at a security product, they need to get their head examined.
    • ^
    • v
    To clarify my first statement above, to avoid the problem of code taininting one can create an open source program that they link to an open source library then passes data via IPC using a named pipe or domain socket to a closed source program and avoid tainting. In the case of Snort, there's already a domain socket output plugin. But, it's probably easier for some to simply work on marketing than come up with non-tainting ways of using open source software in an appliance.
    • ^
    • v
    As others have pointed out, executing and interpreting output of GPL'ed programs really can't "infect" code. Otherwise you'd get into the absurd situation of being unable to do the following

    (non-GPL-shell-prompt)$ (GPL-program) | (non-GPL-grep) (regex)

    without first negotiating with the authors of either (GPL-program) or both (non-GPL-shell) and (non-GPL-grep).

    The interesting thing to me is the question InstallShield type installers. That's one where it's not clear there's an obvious way to work around the issue. That is, assuming that Sourcefire's (and apparently Fyodor's) interpretation of the GPL is correct on that front.

    This would also hit a lot of big companies. Checkpoint is one I can think of offhand - they distribute some small GPL programs (a whois client, and I think a few other things) along with their very large proprietary stuff, and roll it into one installer. I'm sure they aren't trying to do dodgy things with licenses, or prevent people getting the source for the GPL stuff they distribute.
    • ^
    • v
    Jeff:

    So how do you reconcile "open source users contribute nothing back to the projects" and SourceFire owning the GPL'd codebase, and being able to license it commercially? As in, I can contribute, but I have to grant a license to SourceFire? Because otherwise, they can't go licensing out my GPL code, right?

    There was a point after SourceFire was formed, where I offered up a plugin sample and some docs, and Andrew just kept putting me off about it. Now likely, it just sucked, and they didn't want it. But I have to consider the possibility that the SourceFires and Nessus' of the world at some point realized that they really didn't want anyone else's code in there, because then they couldn't re-propritize it.

    That kind of activity strikes me as just as much against the spirit of the GPL as playing games with how code is linked. Putting that in the license IS a GPL change. If they are offering a commercial license, then I can't contribute code and have it stay GPL. How is that GPL license? It's a freaking read-only GPL license.

    (Note: any reference to "my GPL code" is referring to the hypothetical decent programmer who might contribute, not me personally. Any help I gave the Snort guys is absolutely minimal, and they are welcome to have it to license as they please. SecurityFocus donated a few days of my time to go through the rulebase and do cleanup work way back when, for example.)
    • ^
    • v
    Anybody who uses or develops for Snort *can* fork a GPL'd clone of Snort that can't be made proprietary. That's what's generous about SourceFire continuing development under the GPL.
    • ^
    • v
    What license goes with it when I fork? The one that says SourceFire can sell a commercial license to my fork? Or do I get to strip SourceFire's changes and go to vanilla GPL?
    • ^
    • v
    What license is that? Snort ships with the GPL. You can't "strip" the GPL off of Snort to go to "vanilla GPL".
    • ^
    • v
    Sorry if I'm bringing up a settled question here, but I really am curious about this business with binary installers that are themselves proprietary, but bundle GPL software; or that install both GPL and proprietary software, regardless of the license of the installer.

    Lots of companies do this - MySQL is commonly bundled this way (bad example perhaps, as many companies also have separate licenses for MySQL. But it's one that springs to mind) as a DB back-end for otherwise proprietary packages. Also, what about firmware images for various pieces of equipment that include the Linux kernel, BusyBox, and a proprietary web configurator? Some of these images are distributed as self-extracting or even self-tftping executables. (eugh)

    In all those cases, an conscientious vendor will offer the source for the obviously GPLed pieces of the installer / firmware binary, but not the proprietary bits, which they may not even own. To my mind, there are two questions this brings up.

    1 - under GPLv2, would the vendor properly be required to open up the whole installer, and any proprietary software that's included in the binary blob (and to refrain from thus packaging software to which they don't own copyright)? What about the GPLv3 drafts?

    2 - is the above a desirable property for the GPL to have or not?

    Of course question 2 is fairly subjective, but 1 might well have a clear-cut answer.
    • ^
    • v
    Tom: (current) Snort no longer ships under the vanilla GPL. It ships "under the terms and conditions of the GNU General Public License as published by the Free Software Foundation; Version 2 with the clarifications and exceptions described below."

    Hence, this whole current discussion, right?

    So if I grab the current Snort and fork it, what LICENSE file do I have to distribute with it?
    • ^
    • v
    So, looks like I'm having a low reading comprehension week. Marty already answered my biggest question in the license:

    "Source code also allows you to port Snort to new platforms, fix bugs, and add new features. You are highly encouraged to send your changes to roesch@sourcefire.com for possible incorporation into the main distribution. By sending these changes to Sourcefire or one of the Sourcefire-moderated mailing lists or forums, you are granting to Sourcefire, Inc. the unlimited, perpetual, non-exclusive right to reuse, modify, and/or relicense the code."

    The point of the GPL, as RMS describes is, it to have your code always be free (as in GPL). So yes, if I ever get my Snort changes near SourceFire, they get to sell it in closed-source stuff.

    I'm going to have to call that "not GPL."

    I think the forking right question is still open. As in, do they get to do the same thing as above if I try to fork?

    If I can't write code that touches Snort and force every vendor who uses my code to give me back their source, then it's not GPL anymore.
    • ^
    • v
    If you don't want to grant Marty the right to resell your code, don't send your code to roesch@sourcefire.com. He can't simply take your code and change its license. No license could actually assert that.

    I'm having a hard time understanding how Snort could be MORE GPL --- maybe if he didn't declare InstallShield wizards derivative works? That's about the only thing.
    • ^
    • v
    Did you read the bit I posted? They are trying to claim that if I post my code to a mailing list that SourceFire runs, then they will simply take my code and change its license. The license is actually asserting that. It might not fly in court, but I'm a little offended by them trying.

    So now I have to fork Snort, AND the mailing lists, and take extra care who I pick to moderate?

    It could be MORE GPL by removing the section that begins "with the clarifications and exceptions..."

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus