DISQUS

anonymous · 2 years ago

I applaud you sir. Well said. Here here.

Dan Weber · 2 years ago

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.

Jason · 2 years ago

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.

Thomas Ptacek · 2 years ago

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.

Thomas Ptacek · 2 years ago

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.

anonymous · 2 years ago

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.

Thomas Ptacek · 2 years ago

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.

anonymous · 2 years ago

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.

Jason · 2 years ago

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).

Bamm · 2 years ago

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

alan shimel · 2 years ago

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.

Thomas Ptacek · 2 years ago

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?

Thomas Ptacek · 2 years ago

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?

alan shimel · 2 years ago

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.

Thomas Ptacek · 2 years ago

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.

ivan · 2 years ago

"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?

newsham · 2 years ago

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.

Jeff Nathan · 2 years ago

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.

Jeff Nathan · 2 years ago

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.

dragonfrog · 2 years ago

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.

Ryan Russell · 2 years ago

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.)

Thomas Ptacek · 2 years ago

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.

Ryan Russell · 2 years ago

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?

Thomas Ptacek · 2 years ago

What license is that? Snort ships with the GPL. You can't "strip" the GPL off of Snort to go to "vanilla GPL".

dragonfrog · 2 years ago

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.

Ryan Russell · 2 years ago

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?

Ryan Russell · 2 years ago

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.

Thomas Ptacek · 2 years ago

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.

Ryan Russell · 2 years ago

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..."