Snort mailing list archives

Re: [Bleeding-sigs] RE: What's up with Snort's license?


From: "Alan Shimel" <alan () stillsecure com>
Date: Thu, 19 Jul 2007 07:20:28 -0600

Hopefully this will not bounce, as I registered this email address on
the list.

 

With all of the back and forth regarding these issues I would like to
invite Marty, Matt Jonkman, Victor and maybe some of the other folks who
have written to appear on my podcast that I do weekly.  We can do it
with either with live call ins for questions or have people submit their
questions.  I think it will be a great chance to clear the air and give
everyone their say and then hopefully put these issues to bed once and
for all.  Marty, Matt, Victor, et al, what do you say?  Would you be
willing to get on a panel and discuss these issues?

 

Let me know

 

alan

 

StillSecure
Alan Shimel
Chief Strategy Officer

O 303.381.3815
C 516.857.7409
F 303.381.3881

<http://feeds.feedburner.com/StillsecureAfterAllTheseYears>   

  <http://feeds.feedburner.com/~r/StillsecureAfterAllTheseYears/~6/1> 

www.stillsecure.com
The information transmitted is intended only for the person
to whom it is addressed and may contain confidential material.
Review or other use of this information by persons other than
the intended recipient is prohibited. If you've received
this in error, please contact the sender and delete
from any computer. 

________________________________

From: snort-users-bounces () lists sourceforge net
[mailto:snort-users-bounces () lists sourceforge net] On Behalf Of Matt
Jonkman
Sent: Wednesday, July 18, 2007 10:48 PM
To: Martin Roesch; Snort Users
Cc: Bleeding Sigs
Subject: [Snort-users] [Bleeding-sigs] RE: What's up with Snort's
license?

 

Appreciate the reply Marty. I'm the person who said you'd slipped this
in on 
a Friday before a long weekend. I mentioned that because that's what 
happened the last time SF did something and then didn't communicate with
the 
community for weeks afterwards. 3.0 license release I think it was
maybe? I 
forget. But had someone mentioned that you had to do this in a rush
because 
of outside factors we'd have known different.... 

And that time, and the time before, (and probably the time before that
IIRC) 
you said SF was in the wrong by not putting out a note that something
was 
changing right away, or even that you had to do something and would be 
explaining it shortly. When SF goes into a communication blackout it's
quite 
obvious. The "I'm too busy" thing frankly doesn't sound plausible. Over
two 
weeks is more than enough time for anyone to send out an email that says

"We're aware of the situation, we'll update you shortly". If you were 
spending the time waiting for legal review then say so. And let us know
up 
front that's what we're waiting for. Otherwise you just foment the 
conspiracy theories and undermine the corporate confidence that snort
will 
remain stable and community oriented. But I think we've had this 
conversation before, so I won't beat the dead horse any longer. 

I haven't a problem with you protecting code and your rights, but the 
willy-nilly changing of others copyright is not something that should
happen 
by accident. That's not like changing the colors on a website, that's
sacred 
ground. Rushing through that was a huge hit to trust. 

So my questions: 

Will the coders that have more than trivial portions of code in snort be

receiving a proportional chunk of the money you make when on relicensing

Snort under the commercial license? Future and historical contracts?
That 
seems a fair thing to do, unless you intend to buy out their copyright? 
That'd be fair as well. But in protecting the authors of Snort (yourself
and 
others), you've got to consider all of them when the money flows. 

If they're not to be reimbursed under your relicensing revenue, do they
then 
also have the right to sell snort under a commercial license of their
own? 

Why's CVS down still? Why was it down in the first place? 

Have you had the time now to identify exactly what issues in GPLv3 are
an 
issue for SF? I've seen talk of the patent prohibition stuff as being a 
possible issue. Is that what's a concern for SF? 

To be clear: I do appreciate your stewardship of Snort. Better
communication 
would not put so many into a default hostile and suspicious stance. 

Matt 

 

-----Original Message----- 
From: snort-users-bounces () lists sourceforge net 
[mailto:snort-users-bounces () lists sourceforge net] On Behalf 
Of Martin Roesch 
Sent: Thursday, July 19, 2007 4:49 AM 
To: Snort Users 
Subject: [Snort-users] What's up with Snort's license? 

-----BEGIN PGP SIGNED MESSAGE----- 
Hash: SHA1 

Hi everyone, 

I posted this message on my blog a few minutes ago, please read it  
and let me know what you think if you're interested in Snort  
licensing issues. 

- -- 

There have been a lot of questions and speculation about the things  
we (Sourcefire) have been changing in Snort's licensing recently and  
it needs to be addressed so that we can clear the air. 

There are three things that people have been asking questions about  
or having issues with. 

1) GPL v2 lock that we put in place on June 29th. 
2) "Clarifications" in Snort's license language (Snort 3.0). 
3) "Clarifications" with regard to assignments of ownership for  
contributed code (Snort 3.0). 

Let me address these issues in order. 

1) GPL v2 lock. 

Here's what happened. About 3 weeks ago I got a heads up that under  
GPL v2, a licensee can choose to use GPL v3 if we don't specify what  
version of the GPL to use; conceivably we could have people forking  
and changing license on us. Seeing as GPL v3 didn't even 
"ship" until  
June 29th we didn't feel like we were going to be able to make any  
decision on the language that was contained in the new version until  
we'd had some time to perform a formal legal review. It also didn't  
help that they decided to release on the last day of the quarter.  
Another contributing factor to the decision for me was that Linus  
decided to keep the Linux kernel at GPL v2, that in itself 
was enough  
to get me to hit the pause button and take some serious time  
reviewing this new license before making any decision. Linus himself  
said "I'm not arguing against the GPLv3. I'm arguing that the GPLv3  
is wrong for _me_, and it's not the license I ever chose." It's not  
the license we chose either and we're not moving to it without a  
conscious decision to do so. 

If we didn't want the code base moving to the new version then what  
could we do? The simplest thing given the time constraints that we  
were working within was just to change the language in the source  
file header preambles (and not the license itself) noting that we  
were specifying Snort at GPL version 2 until we could make a solid  
and informed decision about how we wanted to treat GPL v3. 

For those of you with wholly contributed source files where the file  
headers were changed, many (most/all?) of them referred to "the  
program" as being under an indistinct version number (not just your  
source files) and so rather than try to track everyone down in the  
time frame we had to work with *I* made a unilateral decision 
to just  
move forward with it and we'd clean up the mess afterwards. 
I'm sorry  
for the "bull in the china shop" routine but we felt like we needed  
to have this language out there before GPL v3 shipped at noon EDT on  
June 29th. Clearly there were some mistakes made, obviously we  
shouldn't have changed things like the BSD license on the 
strl* files  
and so on, we'll fix that too. As Victor observed, this was done in  
something of a hurry. BTW, we didn't try to "slip it out on a 
Friday"  
per the note on some blog, Friday was the deadline and we had to move.


Where do we go from here? We're going to examine the language in the  
new license and decide if we want to move forward with it. This is  
going to take a while but we'll make an announcement when we 
make the  
final decision. For those of you who have wholly authored source  
files that would like the language changed for your source 
files back  
to the original, with the provision that the language reflect that  
you're just referring to your file and not the entirety of the  
program, just let us (me) know and send us the verbage you want and  
we'll make the change. For those of you who object to this sort of  
thing all together that would like to maintain your code as an  
external patch set for Snort instead of in the main source 
tree, give  
us the heads up and we'll pull your code from the source trees. Once  
again, this is with the provision that we may reimplement the  
capabilities that your code offers as Sourcefire-authored code if it  
happens to be something that we consider important to the project. 

If anyone has any other input I'd be happy to hear it. Contrary to  
what several groups with vested interests seem to be promoting,  
Sourcefire isn't interested in closing Snort's source code or making  
this a closed-source project. The community continues to be 
important  
to us and we have no plans on that ever changing. 

2) Snort 3.0 "clarifications" and the GPL 

There has been a fair amount of opinion being put forth by people in  
the blogging world that Snort 3.0 will no longer be "open 
source" due  
to the clarifications that we put in place. This is just plain wrong. 

Sourcefire produces Snort as an open source project. My interest as  
the guy who started this whole thing and who has worked on and  
advanced this project for closing in on 9 years now has always been  
how good we can make the technology and how well we can serve the  
needs of the community. Now that Snort has my company behind it, the  
priorities really haven't changed but there's an interesting dynamic  
out there with companies that are using Snort as a part of their  
product or service offering. Many of them seem to expect us to work  
on this technology and improve it continuously so that their 
offering  
is cutting edge but contribute nothing to the project and complain  
bitterly whenever we do something that might cost them some money to  
continue to use a best-of-breed technology like this. 

It's Free as in "Free Speech", not Free as in "Free Money" people!  
Companies that use Snort as part of a service or product seem to be  
having a tough time accepting this. The goal of the new licensing  
language is to define what we consider to constitute 
conditions under  
which something built on or around Snort is a derivative work 
subject  
to the stipulations of the GPL (i.e. putting the derivative code  
under the GPL license). Despite all the gnashing of teeth that has  
resulted from this clarification, what we've really done is take  
about the most "open" stance you can with a GPL project and put it  
out there, true open source champions should be applauding us 
for our  
position. 

That didn't happen. Instead we've gotten a litany of grousing from  
the blogerati, primarily because we've offered a commercial license  
for people who don't want to play by the rules of the GPL in their  
product and service offerings that will (*gasp*!) cost money. If  
you're licensing technology from Sourcefire (which all of you using  
the GPL version of Snort are doing) and you don't wish to live under  
the terms of that license, we're giving you another one to choose  
from. If you don't like having world-class security technology  
available for a fee because it affects your cost structure, that's  
not my problem. If you want to use it for free then you have to live  
by the license but people always seem to interpret the GPL in ways  
that are optimally advantageous to them (if they don't just take the  
code directly and bury it in their product). The clarifications we  
put into Snort 3 are there to get us all on the same page and 
to make  
sure that commercial users of the technology understand that we're  
not a "venture technology" company, giving them technology for free  
to enable their business models which frequently compete against us  
in some regard. There's nothing wrong with using Snort as a part of  
your commercial offering as long as you adhere to its 
license. If you  
can't do that then we need to talk. 

At the same time we've taken many measures to ensure that the end  
users of the technology are unaffected. Want to integrate Snort or  
part of Snort into your open source project? No problem, it's free.  
Want to deploy 100 home-made Snort sensors in your non-profit/ 
enterprise/government organization ? Go for it. Want to learn how  
these systems work at the code level? No problem, it's all there.  
Want transparency of your security technology and the content that  
drives it? It's all there, as it should be. Want to have access to  
the internals to extend or correct or add your own value to the  
project or just your operational environment? All part of the open  
source concept, make it happen. Want to fork and make your own IPS  
project built on the code-base? You can do that, just make sure you  
understand what you're doing in maintaining proper licensing for the  
forked project and respect our IP. 

I personally have *always* been the biggest advocate for the 
users of  
Snort since the day this company was formed and I always will be. 

3) Snort 3.0 and IP assignments 

This is the most controversial provision of the clarifications that  
we put into the Snort 3.0 license. Basically what it says is: 

* 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. 
* Snort will always be available Open Source, but this is important 
* because the inability to relicense code has caused devastating  
problems for 
* other Free Software projects (such as KDE and NASM). We also  
occasionally 
* relicense the code to third parties as discussed above. If 
you wish to 
* specify special license conditions of your contributions, just say  
so when 
* you send them. 

So what's that mean? If you send a patch to the mailing lists or to  
Sourcefire, if you contribute code to the Snort project we consider  
that code and it's IP to be "assigned" to us. The reason for doing  
this should be pretty clear, we don't feel that contributing 
a 3-line  
patch to a 200k+ LOC codebase means that the contributer has  
copyright claims over Snort at that point. In the early years there  
were many people who contributed (in any way) to Snort but over the  
years since Sourcefire was incorporated the total contribution by  
these external contributers has decreased substantially. After that,  
Sourcefire developed more and more of the code, especially the core  
functionality of the detection engine and preprocessors, not to  
mention tons of the rules as well. I have felt for a long time that  
we need to have a sense of proportionality about this and we should  
also have the ability to be flexible with the code base in terms of  
licensing without needing to approach every contributer individually  
to get sign-off on any changes that we make. That's why we've put  
this provision into Snort 3.0. 

This "assumptive assignment" is exactly what projects like Nmap use.  
Perhaps we should take the next step and use the FSF's model where  
contributers to projects like GCC need to sign a legal document  
explicitly to contribute to the project. The FSF does this because  
they need to have flexibility but also because they need to get out  
from under any potential problems that may occur due to someone  
inappropriately contributing IP from a 3rd party. I don't like that  
concept because of the overhead associated with interacting with the  
project, Snort's not a huge project like GCC so I've liked that  
people can contribute as they see fit. The FSF does take one  
additional step, they guarantee that the projects that people make  
assignments to will be available as open source projects in  
perpetuity. I think that maybe we need to make a statement like that  
but quite frankly it's always been our position that Snort will  
always be available as Free Software and we have no intention to  
change our position ever. 

I think that the part of this provision that people have had 
the most  
trouble with is that we also retain the right to relicense the  
contributed code under alternative licenses. We have to be 
able to do  
that if we're going to offer alternative licenses to Snort,  
maintaining a "patch free" code branch and a "patch tainted" branch  
doesn't make any sense to me and probably not to you either. The  
assignment doesn't mean we're going to "steal" your code and  
"disappear" it CIA-style. It means that we need to be able to retain  
the right to offer it under our commercial license. The code you  
contribute will always be available to you and everyone else in the  
open source code base, we're not going to steal it but we are going  
to make it available to our commercial users. If you've got a 
problem  
with this, don't contribute the code to us, maintain it as an  
external patch. 

That's about it. I'm sorry we haven't been as communicative with the  
OSS community as we probably should be, I personally have a lot of  
demands on my time and I'm the person at SF who's the most familiar  
with the totality of the Snort project so I have a lot of input into  
the process here and I'm also fairly parochial regarding  
communicating concepts like this to the user community. In 
the future  
I'll try to be more forthcoming with all of you and I hope you'll  
continue to be patient with both me and Sourcefire; our 
hearts really  
are in the right place with the users of this technology but we also  
have to be pragmatic about how all of this is going to work 
given all  
of the commercial use that Snort sees. 

We're trying to be pragmatic about these issues, I hope that people  
can feel comfortable with the direction that we're taking things. I  
look forward to reading people's responses. 

      -Marty 

- -- 
Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616 
Sourcefire - Security for the Real World - http://www.sourcefire.com 
Snort: Open Source IDP - http://www.snort.org 




-----BEGIN PGP SIGNATURE----- 
Version: GnuPG v1.4.5 (Darwin) 

iD8DBQFGnmCYqj0FAQQ3KOARAr6wAJ9H4EKBvqQIBsI7dx+H7bFb6hnvVACeICZu 
kqjs5CsDqD8cQhP2LA9hUpM= 
=BWUO 
-----END PGP SIGNATURE----- 

-------------------------------------------------------------- 
----------- 
This SF.net email is sponsored by DB2 Express 
Download DB2 Express C - the FREE version of DB2 express and take 
control of your XML. No limits. Just data. Click to get it now. 
http://sourceforge.net/powerbar/db2/ 
_______________________________________________ 
Snort-users mailing list 
Snort-users () lists sourceforge net 
Go to this URL to change user options or unsubscribe: 
https://lists.sourceforge.net/lists/listinfo/snort-users 
Snort-users list archive: 
http://www.geocrawler.com/redir-sf.php3?list=snort-users 


_______________________________________________ 
Bleeding-sigs mailing list 
Bleeding-sigs () bleedingthreats net 
http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs 

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date:
7/18/2007 3:30 PM
  

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users

Current thread: