ipf
Theo de Raadt
tree since it does not meet our freedom requirements, as have been
outlined in policy.html and goals.html since the start of our project.
we will have to work on an alternative.
Theo de Raadt
> > sometime in the next 20 hours, i will be removing ipf from the source
> > tree since it does not meet our freedom requirements, as have been
> > outlined in policy.html and goals.html since the start of our project.
[...]
> Unfortunately, ipfilter and OpenBSD go very well together (aside from niggling
> ideological differences that could probably be solved by working TOGETHER
> instead of fighting) and you're doing a TREMENDOUS disfavor to your user
> community [1] by pulling out ipfilter without a replacement system that works
> as fantastically well as the tight ipf/OpenBSD integration, or without coming
> to an aimicable solution, which you probably *could have accomplished* by
> sending patches back to Darren.
Clearly you didn't read the web pages up above. What do they say? They say
that the code must be free. We asked Darren. What did he say? He said that
ipf will never be completely free.
So that's it.
What's your problem? I can't tell if it is poor reading skills or if
it is a more basic problem in comprehension.
> Of course, it's too late now.. Everyone's resorted to peeing on each others
> shoes over the issue, and thus, another NetBSD/OpenBSD battle ensues...
>
> *sigh*
If only it were. Thanks for comparing it to something it has nothing
in common with. Oh wait, it does not. It's got people who don't read
calling it the next Armageddon.
Thanks. You're such a help.
> [1] Yes, we're all aware that you work on OpenBSD for yourself and to hell
> with a user community...
Actually, ipf is being removed because many vendors who sell products
with modified ipf just got fucked.
I will let them speak up themselves, but some of them might now be
afraid of being sued by a certain Australian.
> [2] Personal opinion based on statements I've read on the ipfilter list..
> May not actually be correct.
Wow, thanks for making assumptions. Thanks. Really. You are such a
help.
Chris Hedemark
Why? Why not just build from the last known "free license" version of the
software?
Theo de Raadt
> ideological differences that could probably be solved by working TOGETHER
> instead of fighting) and you're doing a TREMENDOUS disfavor to your user
> community [1] by pulling out ipfilter without a replacement system that works
> as fantastically well as the tight ipf/OpenBSD integration, or without coming
> to an aimicable solution, which you probably *could have accomplished* by
> sending patches back to Darren.
IPF IS NOT FREE
Theo de Raadt
ipf isn't in the tree for the same reason that qmail
cannot be in the main source tree.
If you don't understand that, please save us all a lot of grief and do
research on the topic OUTSIDE OF OUR LISTS.
Theo de Raadt
Because Darren has *very clearly* said that the old versions are not
free either.
kspi...@students.uiuc.edu
> software?
I understand it as there never was a "free license" version of the
software. The change made to the license was merely a clarification of
what had been implied all along.
-Kent R. Spillner
Chris Hedemark
> Because Darren has *very clearly* said that the old versions are not
> free either.
But wait... you can't retroactively change the license on a piece of
software that you have already distributed and the user has already
accepted. If the OpenBSD team has been developing against software
developed under one set of terms, can't development continue from that point
ignoring the later versions coming from the official maintainer under new
terms?
Is this not similar to the genesis of OpenSSH?
Brian West
totally agree with him on it. But my concern is what are we going to
replace it with? Theo, Any ideas on what is going to replace ipf? And is
ipf going to go into 2.9 or not?
Thanks,
Brian
Theo de Raadt
Darren has *very clearly* stated that the code was never free as we
thought; and basically that means that our belief that it was
free-enough was false.
Thus, we cannot use it. Really, the 2nd line in goals.html is for
everyone's benefit. It is the application of that same basic rule at
a California Campus a decade and a half ago that led to what we are
doing.
> Is this not similar to the genesis of OpenSSH?
No.
Bob Beck
Translation, by distributing ipf, we are *violating Darren's
License Terms* - this is a really shitty thing to do. Out of respect
to Darren, we should not be distributing modified versions because the
author doesn't want us to. It's that simple. I'd love for it to be
different, but to redistribute code against the author's license
conditions, would make us like, oh, say, people who use the Gnu MP
stuff in commercial products and ignore the GPL. Whether or not you
agree with the license, you have to respect the author's right to
license their code however they wish, and respect those wishes.
-Bob
Bob Beck
>software?
Look here, and read up before posting again on this topic
Todd C. Miller
so spake Erik Fichtner (emf):
> Something that doesn't bugger up cvs updates, perhaps?
Oh come on, this is just silly. There's nothing preventing you
from running 2.9 or 2.9-stable. The developement source tree is
just that--you track it at your own risk. Anyone who gets "burned"
by this can simply check out a copy of the tree before ipf was taken
out; it still lives in the cvs repository.
For that matter, there's no reason a user can't just take Darren's
standard ipf distribution and use that on OpenBSD. That's what
people who have wanted to run the bleeding edge ipf have done in
the past.
- todd
Theo de Raadt
Some people are looking at ipfw as a starting point. That leaves
quite a few gaps at first, but we'll see what happens. Others are
looking at other ideas. We'll see.
Chris Hedemark
> Thus, we cannot use it. Really, the 2nd line in goals.html is for
> everyone's benefit. It is the application of that same basic rule at
> a California Campus a decade and a half ago that led to what we are
> doing.
You're right. That puts it in a much better perspective.
Wish I could contribute some code but about the best I can do is prepay for
a pizza for the poor bloke who is going to work out an alternative.
kspi...@students.uiuc.edu
> software that you have already distributed and the user has already
> accepted. If the OpenBSD team has been developing against software
> developed under one set of terms, can't development continue from that point
> ignoring the later versions coming from the official maintainer under new
> terms?
The license didn't change. Only a clarification was added, to indicate
what had been intended all along (that modifications to the source were
not allowed without the authorization of the author).
This has already been said before and pointed out elsewhere. I suggest
you go through the archives of the ipf mailing list and browse the
comments made by the author himself at the OpenBSD Journal on this issue
for further clarification.
-Kent R. Spillner
Nick Holland
to go with the jump in the one's digit... Gotta be careful what you
ask for! 8-)
Theo and crew, best of skill and luck to you on this. I would guess
that you will maintain the standards we have all been spoiled by in
whatever direction you go on this. I'm going to treat this as a new
learning opportunity, and from what I have seen of the issue, you have
my full support (whatever that's worth).
Nick.
Travis Cole
The crux of the mater is Darren claims his original license did not
grant anyone (OpenBSD included) the right to modify ipfilter.
Its not a retroactive change. No one was ever supposed to modify
ipfilter without permission, but for some reason that has not been clear
until now.
> Is this not similar to the genesis of OpenSSH?
Nope. ssh had a less restricted license on an old version. Ipfilter
never did but it seems no one realized that until recently.
please see: http://www.deadly.org/article.php3?sid=20010527142347
If you wade through the crap and the flames, there are a few intelligent
comments in there.
--
-Travis <ke...@nihilist.org>
Bob Beck
>software that you have already distributed and the user has already
>accepted. If the OpenBSD team has been developing against software
>developed under one set of terms, can't development continue from that point
>ignoring the later versions coming from the official maintainer under new
>terms?
Legally in a court of law, this "changed interpretation" might
not stand up, but it's not about that.
1) Darren's interpretation of his license is that modified
versions are not allowed and that they *never were*. while legally we
might get around that we should respect that, if we wanna be nice
guys and do the right thing.
2) Since we have to be able to distribute modified versions
(according to our project goals at http://www.openbsd.org/goals.html)
it's not going to work, having that code there taints the tree. Both
OpenBSD and other vendors can't both respect Darren's wishes and
distribute the code with our kernels in a manner that makes users
believe the whole thing complies with our stated license policy. If
we dodge the issue and distribute it, all it means is more people
think the ipf code is free, because it's in our kernel, when free
versions of ipf aren't what the author wants. It's a disservice
to our users and disrespectful to the author.
I'm sure that development of appropriate replacements under
a BSD licence won't be an issue for next release in any case.
-Bob
Heikki Korpela
of course, you're a lawyer). I'm sure you'll all capable of doing
Google, some of you maybe even seeking legal counsel in one form
or another. :-)
On Tue, 29 May 2001, Chris Hedemark wrote:
> But wait... you can't retroactively change the license on a piece of
> software that you have already distributed and the user has already
> accepted.
Darren isn't changing anything. He has all rights reserved, whether
or not he states it or not. He has never given up those rights.
> If the OpenBSD team has been developing against software
> developed under one set of terms, can't development continue from that point
> ignoring the later versions coming from the official maintainer under new
> terms?
> Is this not similar to the genesis of OpenSSH?
No. Please reread the SSH 1 license. :-)
<!-- ---------------------- 72 characters -------------------------- -->
Heikki Korpela -- he...@saitti.net
Nicholas Janzen
that way it would be part of OpenBSD, and no-one could ever take that away
from us.
Jeff Bachtel
functional, stable packet filter implementation is non-trivial,
especially one that is high-peformance.
Not to belittle the amount of work that anyone on any project has
done, but OpenBSD started with the NetBSD codebase, and OpenSSH
started with an older ssh release. And a _hell_ of a lot of work was
done to get the two projects to the points they are at today.
If there was an older version of ipfilter that was free, then
conceivably an OpenFilter could be created in 6 months. As it is ipfw
or Drawbridge [1] are the only two IP packet filters I could find
easily with BSD-style licenses. I don't even have an inkling how
hard ipfw would be to modify, however the fact that it doesn't have a
seperate project page and diff tarball is not encouraging.
jeff
[1] ObPlug: http://drawbridge.tamu.edu/ . Yes, its missing important
features, such as stateful inspection. Yes, it is very much targeted
at FreeBSD. However, as far as packet filters running on PC hardware
go, its probably one of the fastest out there. Might be worth looking
at, at any rate.
Michael Samuel
It would be a major security advantage to have the packet filter
chroot()ing, then dropping root priveleges. Not to mention the
flexability of being able to write a packet filter in any language you
choose...
--
Michael Samuel <mic...@miknet.net>
Jeff Bachtel
strings, or execve() programs, they filter. And thats it.
The reason you _don't_ put a packet filter in userspace is that a
context switch is added for each packet that traverses the firewall.
And the only language to choose for a BSD packet filter is C. That is,
if you want it to be capable of handling linespeed.
(in short, the only thing userland about a firewall should be the
control programs)
jeff
Damien Miller
> What would be the security advantage? Packet filters don't parse
> strings, or execve() programs, they filter. And thats it.
>
> The reason you _don't_ put a packet filter in userspace is that a
> context switch is added for each packet that traverses the firewall.
Not necessarily. If you are making your accept/reject decisions on
'connections' rather than packets, then user-space policy becomes more
manageable and much more desireable.
-d
--
| Damien Miller <d...@mindrot.org> \ ``E-mail attachments are the poor man's
| http://www.mindrot.org / distributed filesystem'' - Dan Geer
Jeff Bachtel
are you?
What you are talking about is an API for a policy daemon to feed
dynamic rules to a kernelspace packet filter. Similar to ipf -F a -f
/etc/ipf.rules -E, but running constantly, and somehow "smarter".
jeff
> > The reason you _don't_ put a packet filter in userspace is that a
> > context switch is added for each packet that traverses the firewall.
>
> Not necessarily. If you are making your accept/reject decisions on
> 'connections' rather than packets, then user-space policy becomes more
> manageable and much more desireable.
>
> -d
>
> --
> | Damien Miller <d...@mindrot.org> \ ``E-mail attachments are the poor man's
> | http://www.mindrot.org / distributed filesystem'' - Dan Geer
>
--
Jeff Bachtel (root@ISC,TAMU) http://www.cepheid.org/~jeff
[finger je...@cepheid.org for PGP key]
Michael Samuel
> What would be the security advantage? Packet filters don't parse
> strings, or execve() programs, they filter. And thats it.
Well, in this day in age, people like to do other things than just
block according to the ip header details. Searching a packet data is
a popular request nowadays for people in search of a filewall.
> The reason you _don't_ put a packet filter in userspace is that a
> context switch is added for each packet that traverses the firewall.
Is the overhead of a context switch that much nowadays? If so, then
that's another area of work. The only real problem I see is the extra
copy of the packet in memory, which could be solved with an mmap()ed
interface (right??).
> And the only language to choose for a BSD packet filter is C. That is,
> if you want it to be capable of handling linespeed.
[ I won't bite on the language flamewar ]
> (in short, the only thing userland about a firewall should be the
> control programs)
I understand where you're coming from, but then again, your reasoning
is the same as Microsoft's reasoning for putting SMB into the NT kernel.
--
Michael Samuel <mic...@miknet.net>
David Gwynne
"no-one could ever take [that] away from us", but something that EVERYONE
can have. http://www.openbsd.org/goals.html states "We want to make
available source code that anyone can use for ANY PURPOSE, with no
restrictions."
Sorry if i seem pedantic or something.
As far as implementing a (free) alternative to ipf is concerned, it seems
the only options are to start a packet filter from scratch (yay
OpenFilter/OpenIPF (OpenFirewall has a bad ring to it, you tend to want
firewalls to be fairly tight, not open :) ) or to use an existing peice of
software. The immediate choice would be IPFW used by FreeBSD, but personally
(my personal opinion doesn't count for much in this situation) I don't like
this idea. I prefer configuration files, not configuration scripts.
I'm sure with a bit of poking around several alternatives could be found
like Drawbridge. Another that popped up on #openbsd earlier was Click
http://www.pdos.lcs.mit.edu/click/ ), which looks like it either is or has
the potential to be very powerful and extensible.
Personally I would like to see and OpenFilter or OpenIPF done, but like I
said before, my personal opinion doesnt count much in this situation.
I will trust Theo and the rest of the OpenBSD developers to provide a secure
and safe implementation, and I will be using it. I put a greater level of
trust in this projects ideals and goals than i do in some others (no names
mentioned).
Until a new filter is in place, I'l stick to my current set up (early 2001
snapshot of 2.8).
Thus ends my rambling.
Jeff Bachtel
Christ, people. A packet filter, the evening's topic of conversation,
filters based on TCP, UDP, and IP headers. In the more complicated
revision, it also maintains TCP connection state, and pseudo-state for
UDP "connections".
If you want to do Layer 7, or pseudo-Layer 7 inspection of packets,
then you are talking about an application proxy firewall, more or
less. In which case YES, you can have the target of a packet rule be a
socket to a user-mode daemon upon certain criteria (ie, connection
setup or teardown or for all packets).
But I would _still_ advise people in search of that functionality to
look at FWTK.
Yes, context switches ARE that expensive, when you get over a certain
number of packets per second.
We are still speaking, correct, of a packet filter? One that must work
with saturated 100mbit links? At the _very_ least?
As for SMB in the kernel, remember that some idiots [1] strapped HTTP
into a linux kernel. That is MUCH closer an analogy. Anything for
performance tests, right?
jeff
[1] I say idiots, because the concept is mind-boggling to me, but by
all accounts you have to be pretty clever to pull that off. So lets
say "loonies".
Darren Bolding
I am a bit curious about what OpenBSD specific changes have
been made and if they have been passed on to Mr. Reed.
I usually built ipf anyway, and the lack of an OpenBSD target isn't
a problem, but it would be nice.
I don't get the impression the relationship between the people who
have contributed the effort towards OpenBSD mods to ipf and Mr.
Reed has been soured- or has it?
Curious,
--D
obecian
> Hmmm.
>
> I am a bit curious about what OpenBSD specific changes have
> been made and if they have been passed on to Mr. Reed.
A CVS tag would change his source and infringe
>
> I usually built ipf anyway, and the lack of an OpenBSD target isn't
> a problem, but it would be nice.
As Darren, after all it is HIS source.
> I don't get the impression the relationship between the people who
> have contributed the effort towards OpenBSD mods to ipf and Mr.
> Reed has been soured- or has it?
If you haven't figured it out from 20+ emails, all the news stories,
80-90 comments on OpenBSD Journal -- you're simply never going to get it.
--
Mark Grimes <obe...@openbsd.org>
Joseph W. Shaw II
> 1) Darren's interpretation of his license is that modified
> versions are not allowed and that they *never were*. while legally we
> might get around that we should respect that, if we wanna be nice
> guys and do the right thing.
>
> 2) Since we have to be able to distribute modified versions
> (according to our project goals at http://www.openbsd.org/goals.html)
> it's not going to work, having that code there taints the tree. Both
> OpenBSD and other vendors can't both respect Darren's wishes and
> distribute the code with our kernels in a manner that makes users
> believe the whole thing complies with our stated license policy. If
> we dodge the issue and distribute it, all it means is more people
> think the ipf code is free, because it's in our kernel, when free
> versions of ipf aren't what the author wants. It's a disservice
> to our users and disrespectful to the author.
I completely agree.
Take a look at the bottom of the ipfilter page (for those who don't know,
it's located at http://coombs.anu.edu.au/ipfilter/). That last line kind
of leaves a bad taste in my mouth, but certainly makes me appreciate the
BSD license for what it is.
"This product includes software developed by the University of California,
Berkeley and its contributors."
While I appreciate Darren's work and have used ipf as included with
OpenBSD for some time now, it seems kind of hypocritical for Darren to
benefit from BSD code in IPF, yet not extend others the same liberty with
his own code. But he can do what he likes, and godspeed to him. I just
hope he remembers where part of his codebase has come from.
For those casting doom and gloom on the lack of a firewall in OpenBSD,
this does not mean you cannot use ipfilter on OpenBSD. It will just no
longer be a part of the kernel. You can still install ipfilter if you
like, and can build firewalls for customers and what not if you like with
no problems as long as the version you're installing is a release
version. The only problem is that you cannot modify the source code as it
exists from the distribution if your needs are different than the current
source allows for. I certainly will move to another firewall if it can
compete competantly, but until such a beast exists, I'll be sticking with
ipf.
To those working on a replacement for ipf, I'll gladly donate what I
can. Good beer, pizza, hardware, or whatever else it takes that I can
provide.
Regards,
--
Joseph
Angelos D. Keromytis
>What would be the security advantage? Packet filters don't parse
>strings, or execve() programs, they filter. And thats it.
Flexibility.
>The reason you _don't_ put a packet filter in userspace is that a
>context switch is added for each packet that traverses the firewall.
Turns out this is not really an issue; in the distant past, I did work on a
user-level firewall. Not only it was fast enough, it was trivial to develop as
well. More recently, I've done the same for some research at UPenn. If you
combine it with an in-kernel rule cache it gets even faster.
There are reasons against doing this of course; however, *if* we decide to
roll out something from scratch, a userland firewall may be a very reasonable
first step simply in terms of development ease (it also makes it very natural
to modularize it).
-Angelos
Peter Galbavy
> sometime in the next 20 hours, i will be removing ipf from the source
> tree since it does not meet our freedom requirements, as have been
> outlined in policy.html and goals.html since the start of our project.
>
> we will have to work on an alternative.
While it will be a shame and some major impact, I fully support Theo
in not giving in to "retroactive" licensors.
rgds,
--
Peter Galbavy
Knowtion Ltd.
http://www.knowtion.net/
will backman
beyond "hello world."
What can non-programmers do to help.
Does the OpenBSD team need anything to help this process along?
What can I do to help?
I'll be quiet now.
Will
Tony Lambiris
everyone you know how great OpenBSD is and get them excitied enough to
purchase a CD and try it out, buy a few tshirts or posters.... you can do a
lot to help out.
John Lockard
license. I'm thinking that Darren, however good a programmer
he might be, just doesn't understand English. How does saying
'Redistribution in source and binary forms is permitted as
long as the license file is preserved and due credit is given
the original author' [paraphrase], equate to "Yes, this means
that derivitive or modified works are not permitted without
the author's prior consent." [Exact License quoted below]
To tell people in one line that redistriubution is allowed
and then in the next line say that it isn't allowed is
a contradiction. Darren stands on the soapbox saying that
the two lines that he added have always been implied in the
original license. I think he must be either be on drugs,
uses english as a 4th language or has no grasp of what the
language of the license really means.
He claims that he's not worried about being taken to court on
this one, because he knows that he'd win, because the language
was always implied by the original license. I think if he
went to court on this, he'd have no legs to stand on.
Here's Darren's original license:
/*
* Copyright (C) 1993-2000 by Darren Reed.
*
* The author accepts no responsibility for the use of this software and
* provides it on an ``as is'' basis without express or implied warranty.
*
* Redistribution and use in source and binary forms are permitted
* provided that this notice is preserved and due credit is given
* to the original author and the contributors.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*
* I hate legaleese, don't you ?
*/
Here's Darren's new license:
/*
* Copyright (C) 1993-2001 by Darren Reed.
*
* The author accepts no responsibility for the use of this software and
* provides it on an ``as is'' basis without express or implied warranty.
*
* Redistribution and use in source and binary forms are permitted
* provided that this notice is preserved and due credit is given
* to the original author and the contributors.
* Yes, this means that derivitive or modified works are not permitted
* without the author's prior consent.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*
* I hate legaleese, don't you ?
*/
--
--jlockard - Everyday I beat my own previous record for number of
consecutive days I've stayed alive.
-------------------------------------------------------------------
John M. Lockard | U of Michigan - School of Information
Sys Admin III | 400 West Hall - 550 E. University. Ave.
jloc...@umich.edu | Ann Arbor, MI 48109-1092
www.umich.edu/~jlockard | 734-615-8776 | 734-764-2475 FAX
-------------------------------------------------------------------
Valentin Nechayev
> I'm confused (as many probably are) in how Darren changed the
> license. I'm thinking that Darren, however good a programmer
> he might be, just doesn't understand English. How does saying
> 'Redistribution in source and binary forms is permitted as
> long as the license file is preserved and due credit is given
> the original author' [paraphrase], equate to "Yes, this means
> that derivitive or modified works are not permitted without
> the author's prior consent." [Exact License quoted below]
Because original license does not say anything to permit _modification_.
Permission to modify is omitted. Compare with OpenBSD:
=== ... cut ... ===
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
=== end cut ===
This license explicitly allows modification. ipfilter's one - doesn't.
Yes, one section in logical chain is silently omitted, but IMHO you
cannot say that it does not exist.
/netch
Jeff Bachtel
Examples will suffice. Read all the way through, the final will be
comprehensive for this course.
And HERE is a BSD License:
/*
* Copyright (c) 1993,1994,1995,1997,1998
* Texas A&M University. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by Texas A&M University
* and its contributors.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE UNIVERSITY AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE UNIVERSITY OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* Developers:
* Russell Neeper, David K. Hess, Douglas Lee Schales, David R. Safford
*/
Now the pop quiz: Is saying "with or without modifications" in the
paragraph above required. The answer: almost certainly "yes", as it
grants a part of the copyright, and unless otherwise noted a copyright
is held intact.
SO, basically, Darren withheld 4 words and kept IPF unmodifiable. So
be it, etc.
jeff
Paul M. Hirsch
> He claims that he's not worried about being taken to court on
> this one, because he knows that he'd win, because the language
> was always implied by the original license. I think if he
> went to court on this, he'd have no legs to stand on.
That is probably right, however the issue is not of legality, but
of the wishes of the author. OpenBSD is not about court battles
and corporate style politics, and if I am not mistaken, Theo writes
better code than legal briefs. IPF is not worth the potential
lost development time and project money to fight over in court.
The OpenBSD project has chosen the honrable thing to do, and just
as the OpenSSH project eclipsed the package it started out to
replace, I have a feeling that within a couple releases no one
will be complaining about the loss of IPF. (Assuming the
proper ammount of extra resources are available.)
-Paul
--
/Paul M. Hirsch /
/elektr...@voltagenoir.org/
/GPGPGPkeyID: 0xD11A250E /
will backman
amounts of cash.
I was hoping there might be some specific items needed to test firewall
software, such as crypto cards, gigabit stuff.
I assume the testing phase will require some high speed networking equipment,
disks, and processors. Do we want to donate non-free OS licenses for
testing. For example, I hear that Windows NT always sets the URG flag. How
about some other firewall/IPSEC products and hardware for compatability
testing?
Moritz Grimm
> Theo said:
> > we will have to work on an alternative.
> Why? Why not just build from the last known "free license" version of the
> software?
If you want the short version of this mail, read what Heikki Korpela
said and/or Jeff Bachtel's comparison between the BSD license and Darren
Reed's.
Because I make music and release it for free on the internet, I studied
the (German) copyright law in order to know how all this works. The
following explanations refer only to the German law, but according to
Darren's statements it seems that this is very similar to Australian law
(and even US law and that of other countries). I won't give any warranty
on my explanation since I am no lawyer, but since I also invested quite
some time into this topic, I'm quite positive that most of the following
is correct.
The copyright law doesn't distinguish between different kinds of
authors, so this applies to both composers and writers of lyrics,
software and so on.
Every author exclusively has *all* rights concerning his work the moment
he starts to work on it (the so-called "exclusive rights"). Only he may
modify it, give it to others for free or sell or license it, and so on.
This means that, if one would compare it to an ipf ruleset, it would
look like that by default (from the public's viewpoint):
block in from any to any
block out from any to any
#EOF
Only those rights he *explicitly* grants to the public may be used by
the public and nothing else. If he used a BSD license or similar, this
license would have done this job for him, but as we can see he wrote his
own. Those rights he grants to the public are "simple rights", which
means that nobody of the public may grant any (or more) of these rights
to others - only Darren may do that.
" * Redistribution and use in source and binary forms are permitted
* provided that this notice is preserved and due credit is given
* to the original author and the contributors. "
Here, he allows the redistribution and *use* of his source code and the
binaries that are compiled from it. "use" means "use", and not "modify",
"sell", "hire", "lend" or anything else. The "due credits" also don't
imply that one may create derivative works provided that those credits
are given. Those credits have to be given when someone from the public
redistributes his code or uses it (in an unmodified form!) within
another product, e.g. OpenBSD, or as a precompiled RPM package etc.
Unfortunately, selling OpenBSD on CDs already infringes Darren's
copyrights in two ways - it is both sold and modified.
Everything that someone writes, be it software or artistic stuff like
music, is proprietary by default and protected by (inter)national
copyright laws. The authors have to explicitly grant every single right
they want others to have, especially if something is supposed to be Open
Source in the common sense (GPL, etc.), or even public domain (BSD
license). ipf is "Freeware", which means that it can be obtained and
redistributed for no money, but it is not "Open Source" (it's irrelevant
whether the source code is actually available or not). Usually, just
like in this case with ipf, Freeware may not be sold together with other
products for money, e.g. on a CD that comes with a magazine, even if the
price only covers the expenses the redistributor had. Why? Because
Darren didn't allow it.
My very personal opinion is that Darren cannot be blamed for anything.
He never changed his license to anything more proprietary than before,
and he only did what is his highly deserved right. The two lines he
added to his license really only clearified things. The only thing one
might blame him for is to assume that everybody actually understands his
license... but this has nothing to do with the license itself. In order
to prevent those misunderstandings, big companies that allow their
proprietary software or drivers to be downloaded for free hit you with a
license agreement that fills three or more screens at font size 1 -
everybody skips over it and clicks 'agree', but also everybody knows
"okay, i can download but i may do shit with that thing". So, if someone
feels ass-raped now, this is the problem of the respective person, and
not Darren's. But that's just my $.1.
Concerning OpenBSD, this is a big bummer. When I first installed it, I
instantly loved it, no matter what problems I had in the beginning. It
was the first OS I ever used that was actually fun to configure. :) IPF
highly contributed to my positive feelings towards OpenBSD - everything
OpenBSD related I know of is logical, effective, dedicated and still
understandable at the same time. A possible way out of this misery would
be, IMHO, to friendly try to convince Darren to grant a few more rights
to make his great product as free as necessary to allow it to stay with
OpenBSD, or even switch to a GPL-like license (this would ensure that
only he may allow someone, for monetary compensation, to use IPF or
parts of it within another proprietary, closed-source product). The
benefits would be a continuing large (and growing) userbase for both IPF
and OpenBSD and less trouble on every side (be it OpenBSD, companies
that use it and IPF, or even Darren's). Otherwise, I understand that IPF
may not stay with OpenBSD, as it really doesn't comply with OpenBSD's
goals and philosophy with its current license. Again, just my $.1, makes
$.2 on the whole.
Moritz
P.S.: Darren Reed really doesn't have to fear anything in court. His
case will be closed within moments and he'd have won.
P.P.S.: If I got something wrong, please let me know - I am interested
in this topic and if there's something I can learn from it, I'm happy to
do so.
Matt
M.
John Verne
> of the wishes of the author. OpenBSD is not about court battles
> and corporate style politics, and if I am not mistaken, Theo writes
> better code than legal briefs. IPF is not worth the potential
> lost development time and project money to fight over in court.
> The OpenBSD project has chosen the honrable thing to do, and just
> as the OpenSSH project eclipsed the package it started out to
> replace, I have a feeling that within a couple releases no one
> will be complaining about the loss of IPF. (Assuming the
> proper ammount of extra resources are available.)
>
personalities), and not necessarily about legalities.
There is certainly enough precedence to case doubt on the statement by the
author of ipf that it was never free to distribute or modify. It is also
disingenuous to make a small modification to a license and then claim it has
always "meant the same thing". Any good lawyer could skewer this argument
easily. I hope Mr. Reed has good counsel, because if a Big Bad Company
wanted to take his code in exchange for a few pieces of silver, he'd find it
very difficult to say "no".
However, as has been pointed out by others, no matter how uncooperative an
author is, we should take the high road and honour this "new" license. Not
to mention that it does nobody any good to get into a legal battle over
this.
Finally (and most important to this discussion), Theo and the OBSD team have
to adhere to their own philosophy about OpenBSD -- one that has served us
well for many years. I cannot support the inclusion of software into the
OBSD tree that does not allow for a full audit, including modification (if
necessary).
Has Mr. Reed done himself a disservice introducing a new license prohibiting
modification and stating it has always been this way? Yes.
Should Theo pull ipf from the OBSD tree? Of course.
Unfortunately, I cannot help with this effort much beyond standing on the
sidelines and shouting "go team!". My TCP/IP experience is firmly user-land
administration, and is going to stay that way, if I can help it.
That's my $1.49 (CDN). Flames cheerfully ignored with the help of my +1
Ring of Fire Protection.
jdv
Joseph W. Shaw II
Buy a release CD, t-shirt, poster, donate hardware, donate money, write
documentation, and any other number of countless small or large bits that
help out. While code is certainly at the heart of the OpenBSD project,
and you'll hear "show me code or shut up" a lot, there are a lot of jobs
that the guys who can code shouldn't have to and don't need to do if
volunteers help. Since my time is limited these days, I help out by
buying releases and t-shirts (from Theo himself at USENIX last summer in
San Diego where he seemed a lot more personable than via e-mail :) as well
as donating hardware when and where I can.
There are tons of things you can do to help. Think of one, and get it
done.
Regards,
--
Joseph
Gary Buckmaster
donate writing time assuming there was a list of wants and needs somewhere
to work off of.
Lipscomb, Al
> (and perhaps
> personalities), and not necessarily about legalities.
>
> There is certainly enough precedence to case doubt on the
> statement by the
> author of ipf that it was never free to distribute or modify.
In the long run what do you gain by fighting with the author?
You end up with a fork in the code and the new maintainers must
live with the notions of the original author. Work will be duplicated
as both sets of code must be maintained etc.
It will be good to have firewall software that follows the BSD goals,
free for everyone.
Tony Lambiris
> You end up with a fork in the code and the new maintainers must
> live with the notions of the original author. Work will be duplicated
> as both sets of code must be maintained etc.
>
> It will be good to have firewall software that follows the BSD goals,
> free for everyone.
Yeah, why dont you talk to Darren about that one. No one is fighting with
anyone. Darren was asked to license IPF under the BSD license, he said no,
so OpenBSD took it out of their OS _because it conflicts with OpenBSD's
license_.
John Verne
> > statement by the
> > author of ipf that it was never free to distribute or modify.
>
> You end up with a fork in the code and the new maintainers must
> live with the notions of the original author. Work will be duplicated
> as both sets of code must be maintained etc.
>
> It will be good to have firewall software that follows the BSD goals,
> free for everyone.
>
This quote of mine is a little out of context. I agree with this statement.
In fact, I said as much in the original posting.
By mentioning the legal issues concerning the availability of ipf, I was
merely "comparing and contrasting" the legal issues with the philosophical
issues.
I never suggested that "we" (whomever that is) should start a legal battle
with the author of ipf. I just suggested that the author may be on shaky
legal ground if he should ever be challenged by some other parties with
respect to ipf. At least, in the way he states it on the ipfilter mail
list.
Obviously, litigation will not solve anything in this case, and was never a
suggestion of mine.
I expect this is the last I have to say on the subject.
Thank you,
jdv
John Vernier Simon
contest" describes the situation. Oh well, I am saddened to see Darren's IPF
source removed from the OpenBSD tree. I can understand Darren's point of view,
a lot of people seem to be abusing his code and giving very LITTLE back. Oh
well the few spoil the cream for the many. Hopefully everyone will come to
their senses and Theo will put the source back, as IPF was a really big chunk
of OpenBSD's great security.
John
Tony Lambiris
"pissing
> contest" describes the situation. Oh well, I am saddened to see Darren's
IPF
Open your ears instead of your mouth. Do you seriously think Theo is going
to go against OpenBSD's license and policy for a piece of software? NO. It's
too simple: Darren's license conflicts with OpenBSD's... END OF STORY.
> source removed from the OpenBSD tree. I can understand Darren's point of
view,
> a lot of people seem to be abusing his code and giving very LITTLE back.
Oh
> well the few spoil the cream for the many. Hopefully everyone will come to
> their senses and Theo will put the source back, as IPF was a really big
chunk
> of OpenBSD's great security.
The _only_ way it will see it's way back into OpenBSD's code is if Darren
releases IPF under the BSD license (or something very similar which states
you can modify IPF anyway you want).
Big chunk of OpenBSD's security?? So what you are saying is now that IPF has
been taken out of the core OS, all the team's auditing and fixing bugs
doesn't equate to anything anymore? Are you mad? Does this mean that because
they took out IPF, I can no longer encrypt my swap space, or use blowfish to
hash my passwords? Pffff.
William Yodlowsky
[snip]
> well the few spoil the cream for the many. Hopefully everyone will come to
> their senses and Theo will put the source back, as IPF was a really big chunk
> of OpenBSD's great security.
Um, no, the security permeates the OS. This was only an IP filter +
NAT.
John Vernier Simon
to play ball like that, his call. I think it is a mistake, sure the license
conflicts, and I am sure you and the lawyers and Theo and Darren and everyone
can argue licening till the freaking cows come home. My point is that removing
IPF is NOT helping OpenBSD, or the Open Source communities image. Big buissness
frowns on this kinda bickering, and seeing this I am sure a lot of large corps
will shy away from OpenBSD, even though it is the best and most secure OS. Oh
well, have fun, I will be running IPF on Solaris till things get resolved.
John
John Vernier Simon
damn nice stateful packet filter in one package was what made OpenBSD for me, guess
I can't speak for everyone.
John Vernier Simon
Source image, sure people who switch are stupid, blah blah blah. But you have to remember
that the people who control the purse strings and the decision making abilities in large
companies are not the most tech savvy, and they see these little "hackers" arguing over
licensing and go somewhere a bit more stable. Logical or not this is not a good political
move, in other words it looks bad to people on the outside. Any body know a good spin
doctor, cause OpenBSD needs one.
InSaNe wrote:
> People can still download and install IPF. It isn't that difficult. It
> is just no in the source or shipped with it due to licensing reasons, that
> doesn't stop someone like you from downloading and installing it. A small
> inconvienience.
>
> If IPF being removed makes anyone switch from OpenBSD, then I consider
> that person an idiot, I don't want to use IPF anymore because of the
> license either.
Angelos D. Keromytis
>Sure security permeates the OS, but the fact that you had the most secure OS,
>and a
>damn nice stateful packet filter in one package was what made OpenBSD for me,
>guess
>I can't speak for everyone.
If you don't like it, don't use it. Otherwise, write code.
STOP WASTING OUR TIME ON tech@ -- take this elsewhere.
-Angelos
a...@eltex.ru
I am afraid that is only possible if Darren will re-license OpenBSD branch
under BSD license (as he probably has done for FreeBSD if i understand
`granted permission' correctly). And that is unlikely to happen because of
conflict escalation we observed here on the lists :( Too bad, but there is
the `old BSD way' to grab ipfilter distribution separately and to install
it on your system. It is somehow time-consuming if there are some port
problems with latest release but it is better than nothing :(
About `code abusing' by OpenBSD.. There was public cvs and there was always
a way to back-port any OpenBSD changes back into main ipf tree. What's wrong
with it?
> I think Theo isn't being really cool about this one, I think the term "pissing
> contest" describes the situation. Oh well, I am saddened to see Darren's IPF
> source removed from the OpenBSD tree. I can understand Darren's point of view,
> a lot of people seem to be abusing his code and giving very LITTLE back. Oh
> well the few spoil the cream for the many. Hopefully everyone will come to
> their senses and Theo will put the source back, as IPF was a really big chunk
> of OpenBSD's great security.
_ _ _ _ _ _ _
{::} {::} {::} CU in Hell _| o |_ | | _|| | / _||_| |_ |_ |_
(##) (##) (##) /Arkan#iD |_ o _||_| _||_| / _| | o |_||_||_|
[||] [||] [||] Do i believe in Bible? Hell,man,i've seen one!
John Vernier Simon
> nuqneH,
>
> About `code abusing' by OpenBSD.. There was public cvs and there was always
> a way to back-port any OpenBSD changes back into main ipf tree. What's wrong
> with it?
I don't think there is anything wrong with it, I jsut know of a few commercial
products that use IPF, and I don't think they really kickback funds where it counts.
Not that they have to, and I may be totally wrong, maybe everyone who has used IPF
for profit has given back in time/money/or hardware. Just sad to see this kinda
thing happen, ya know?
John
jon
thread.
Enough already?
Jon
--
A farmer using BSD, eh!
Simply put, facts and lessons from this incident are:
- Any software with no explicit permissions for modifications, change,
and re-distribution should never be integrated in OBSD in the first
place, no matter how good and popular they are. DJB stuff is another
example.
- Show time for "secure by default" implementation.
- Time to kill the wide-spread and often-ill-intended idea of OpenBSD
being a free firewall, rather than a fully-fledged, top-notch,
high-quality OS.
- illustration of the effect of "usage habbit breeds taken-for-granted
attitude" by using software benevolently integrated into OBSD.
In anology to your statements, a lot more people have been "abusing"
OpenBSD code and giving very little back. Does that make OpenBSD team
change their initial promise and commitment? They did not start this
project and produce a quality free OS just to drug people into their
paid-per-view "show me the money" new versions. You are way far from
home. Here is a different bunch.
=============
On Wed, 30 May 2001 15:18:28 -0500
John Vernier Simon <john....@central.sun.com> wrote:
> I think Theo isn't being really cool about this one, I think the term "pissing
> contest" describes the situation. Oh well, I am saddened to see Darren's IPF
> source removed from the OpenBSD tree. I can understand Darren's point of view,
> a lot of people seem to be abusing his code and giving very LITTLE back. Oh
> well the few spoil the cream for the many. Hopefully everyone will come to
> their senses and Theo will put the source back, as IPF was a really big chunk
> of OpenBSD's great security.
>
> John
>
> Tony Lambiris wrote:
Chuck Yerkes
Some kernel mods (a .o file for use using non-opensource OSs)
and a userland processed that made decisions.
Times have moved on, but the context switch rates are pretty
much moot for anyone using a post-1997 machine to firewall
a T1.
Quoting Jeff Bachtel (seba...@irelandmail.com):
> Then you're not exactly putting your _packet filter_ in _userspace_,
> are you?
>
> What you are talking about is an API for a policy daemon to feed
> dynamic rules to a kernelspace packet filter. Similar to ipf -F a -f
> /etc/ipf.rules -E, but running constantly, and somehow "smarter".
>
> jeff
>
> > > The reason you _don't_ put a packet filter in userspace is that a
> > > context switch is added for each packet that traverses the firewall.
> >
> > Not necessarily. If you are making your accept/reject decisions on
> > 'connections' rather than packets, then user-space policy becomes more
> > manageable and much more desireable.
ppruett
create another mail list
for usefull email discussions
so on
http://www.openbsd.org/mail.html
ipf
Topics for OpenBSD developers concerned with an alternative to ipf
tech
Technical topics for OpenBSD developers and advanced users. Please direct
'new user' and installation-related questions to misc. Please do not
cross-post to both misc and tech
...and maybe the mail lists.....
ipf-bitch
Topics for OpenBSD users pissed off at the author of IPF and/or Theo
-:)
then use a script on the mail list server move all discussion after the
first 100 posts that has "ipf" in the header...
... seriously all...
If we must talk about ipf, talk about the finding an alternative,
talk about if short term it is feasible having in ports if appropriate
and not against authors wishes.... etc
Rather than having the discussion going non-tech, because by now
I imagine many readers will start deleting emails with
the subject "ipf" ...
Steve Shockley
> I imagine many readers will start deleting emails with
> the subject "ipf" ...
I started ignoring messages with a subject of 'ipf' until I installed a
recent snapshot and ipf stopped working. Oops! <g>
Brett Glass
>IPF IS NOT FREE
I agree, Theo. It may also be worth pointing out, at
this juncture, that GCC is not either. Stallman may call GPLed
software "Free Software," but in fact it's also un-free in a
way that burns commercial developers. (As the late Doug Adams
so glibly put it, "Capital letters were always the best way of
dealing with things you didn't have a good answer to.")
--Brett
Rob Funk
>At 08:28 PM 5/29/2001, Theo de Raadt wrote:
>>IPF IS NOT FREE
>
>I agree, Theo. It may also be worth pointing out, at
>this juncture, that GCC is not either. Stallman may call GPLed
>software "Free Software," but in fact it's also un-free in a
>way that burns commercial developers.
As long as the software you're developing is not gcc itself, then gcc
doesn't burn commercial developers. You don't have to GPL software
just because you used GPL software as part of the development process
(e.g. compiling, editing, etc).
--
==============================| Guildenstern: "So there you are."
Rob Funk <rf...@funknet.net> | Rosencrantz: "Stark raving sane."
http://www.funknet.net/rfunk |(Tom Stoppard, Ros. & Guil. Are Dead)
Brett Glass
>As long as the software you're developing is not gcc itself, then gcc
>doesn't burn commercial developers.
Sure it does. It has destroyed the market for commercial compilers
and has also forced projects (such as OpenBSD) who would prefer
to distribute only truly free software to use it.
--Brett
Jack J. Woehr
Richard Stallman's monomaniacal crusade for his vision of Free Software
led to the cornucopia of open source software of all descriptions and has
benefitted even projects which disagree on many details of Stallman's
vision.
The battle of Waterloo was won on the playing fields of Eton,
and the battle for public acceptance of Linux, BSD, SourceForge,
Apache, etc., was won in the GNU golden age.
It's easy to bark at Stallman, who is a truly impossible human being.
But few who do the barking have accomplished for open source and
free software 1/1000th of what Stallman has accomplished.
We should stand on the shoulders of the pioneers, rather than trying
to bite them on their kneecaps.
--
Jack J. Woehr # Ceterum censeo
PO Box 51, Golden, CO 80402 # in herbas belli
http://www.softwoehr.com # ab idem desistamus.
Damien Miller
I'll take gcc with its annoying licence to the days of Unix vendors
charging thousands for compilers. Some markets are better dead.
-d
--
| Damien Miller <d...@mindrot.org> \ ``E-mail attachments are the poor man's
| http://www.mindrot.org / distributed filesystem'' - Dan Geer
Artur Grabowski
> I think Theo isn't being really cool about this one, I think the term "pissing
> contest" describes the situation. Oh well, I am saddened to see Darren's IPF
> source removed from the OpenBSD tree. I can understand Darren's point of view,
> a lot of people seem to be abusing his code and giving very LITTLE back. Oh
> well the few spoil the cream for the many. Hopefully everyone will come to
> their senses and Theo will put the source back, as IPF was a really big chunk
> of OpenBSD's great security.
Gee. You really can't listen don't you? Or don't you just understand what's
being said?
We can't put IPF back into our tree unless the license changes. IS IT SO
HARD TO UNDERSTAND? How many times do we have to repeat it?
THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
Get it? Or do we have to repeat again and again and again and again?
THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
It's as simple as that. If Darren changes the license, then we can put it
back. Darren doesn't intend to change the license. So until he does,
STOP WASTING OUR TIME on tech@. Take your opinions to Darren or someone
else. Because OpenBSD will not change it's licensing policy.
It's not a pissing contest. It's just a simple realization that we made a
mistake. When adding IPF into the kernel everyone thought that the license
was compatible with the licensing policy, but it's not. Since we've realized
that now after Darrens clarifications, we have removed the code from the
OpenBSD tree because we don't want to break the law. And by asking us to
include IPF in the kernel you are asking us to break the law. understand?
Or do you want this explained with pictures?
//art
Philipp Buehler
> We can't put IPF back into our tree unless the license changes. IS IT SO
> HARD TO UNDERSTAND? How many times do we have to repeat it?
What I don't get in this part, is why Daren didn't say anything in
advance. I think, it's safe to asume that he knew that OpenBSD was
changing the source and also redistributing that.
Some SSH/OpenSSH memories come alive ..
And the stuff about "dont giving back changes" .. erm, he could
fetch the changes (which are not allowed in advance!) from CVS at
any time.
For the tech-relevance, I would prefer to see a (personal) solution
between darren and the OpenBSD team. As the license says that *with
permission* it's possible.
Now pushing ressources into a new packetfilter or using ipfw as a code
basis wastes time like hell (like these mails, sorry). Which could
be better used for integrating new stuff (SMP ;) ) or fixing new
drivers (i82652 :>).
> THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
It would allow it, if darren would give a permission to openbsd ..
ciao
--
Philipp Buehler, aka fips | sysfive.com GmbH | BOfH | NUCH | <double-p>
#1: Break the clue barrier!
#2: Already had buzzword confuseritis ?
Joseph W. Shaw II
> > THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
> It would allow it, if darren would give a permission to openbsd ..
That's one of my concerns. Darren obviously did know that OpenBSD
included ipf as part of the distributions because it's listed on the
ipfilter home page! I know Darren has commited code and changes to the
FreeBSD CVS, so I'm wondering if he's granted them permission to change
his work. I'm not sure if he has or has not, because as far as I know
he's done all the work himself. This is based off Darren's own postings
to the ipfilter mailing list.
How are the NetBSD folks handling ipf? I'm not sure if it's part of their
kernel or not. If they are finding themselves in the same dillemma, might
it be time for an extending of the olive branch and trying to work on a
new packet filter if that is what is ultimately required? This could turn
into a good thing down the road while it may suck in the short term.
Also, I think it prudent that we move any actual constructive conversation
on the subject to misc@ instead of tech@. Many are becoming annoyed with
the low signal to noise ratio, myself included. Until we have technical
details to talk about, let's take the proposals and other stuff off this
list.
Just my $.02 USD.
--
Joseph
Any incoherence is the result of sleep deprivation.
Theo de Raadt
> > We can't put IPF back into our tree unless the license changes. IS IT SO
> > HARD TO UNDERSTAND? How many times do we have to repeat it?
>
> What I don't get in this part, is why Daren didn't say anything in
> advance. I think, it's safe to asume that he knew that OpenBSD was
> changing the source and also redistributing that.
For five years already.
> Some SSH/OpenSSH memories come alive ..
> And the stuff about "dont giving back changes" .. erm, he could
> fetch the changes (which are not allowed in advance!) from CVS at
> any time.
> For the tech-relevance, I would prefer to see a (personal) solution
> between darren and the OpenBSD team. As the license says that *with
> permission* it's possible.
I am getting tired of you people who can't read term #2 of
http://www.openbsd.org/goals.html. Are your english skills not good
enough to understand what the word "any" means? It does not mean "some".
It means "all".
> > THE LICENSE ON IPF DOESN'T ALLOW OPENBSD TO INCLUDE IT IN THE KERNEL.
> It would allow it, if darren would give a permission to openbsd ..
And to companies who use OpenBSD? There are perhaps 10 of them who use
modifications, that I know of so far. Do they all need to ask too?
And what if Angelos adds the same rules to the ipsec code?
And Niklas to the isakmpd daemon?
And Markus to OpenSSH, so that Apple has to ask for permission before
including it?
You may be thinking of only yourself, but I am thinking of ANY people
(that means "all")
Peter N. M. Hansteen
Well, it all boils down to a matter of honesty. Free software like
OpenBSD can not afford to include components which are somehow not
legally kosher. The wording of the ipf license was close enough to
a crucial part of the BSD license that non-lawyers were lead to believe
that it was the same. Essentially, the OpenBSD team did this "in good
faith" (I believe that is the legalese term). Well, then it turns out
that license to modify ipf was not granted after all, at any time.
This came as a surprise to most people, but with Darren's clarification
in hand, a "good faith" defense for keeping ipf in OpenBSD was no longer
possible, and ipf had to be removed from the main source tree.
It is possible that a measure of diplomacy could make Darren grant
OpenBSD permission to distribute a modified version of ipf. At the
moment OpenBSD does not have that permission, and from the various
reports it seems that Darren is not interested in working with the
OpenBSD project.
If what you are saying is that you volunteer to act as a mediator in
order to try to get negotiations started, I'm sure it would be appreciated.
Especially if it is kept off the tech list. (** YES! KILL THIS THREAD
IN tech NOW! MOVE TO misc! **)
- Peter
--
Peter N. M. Hansteen pe...@datadok.no http://www.datadok.no
Datadokumentasjon A/S, Bredsgaarden 2, N-5003 Bergen, Norway
Tel: +47 55 32 08 02 Fax: +47 55 32 14 95
Artur Grabowski
> It would allow it, if darren would give a permission to openbsd ..
No. Only if he would give permission to _everyone_.
OpenBSD strives to make a system that doesn't necessarily have to be an
end user product. It must also be possible to take OpenBSD, build upon it
and redistribute the derived work as a separate product.
//art
Brett Glass
>I'll take gcc with its annoying licence to the days of Unix vendors
>charging thousands for compilers. Some markets are better dead.
I disagree.
First of all, GPLed software is not free -- either by OpenBSD's definition
or by any commonsense definition of the word. OpenBSD should use a truly
free compiler. Second, the GPL's explicitly stated goals are to destroy
consumer choice and programmers' livelihoods. OpenBSD should not participate
in such a malicious agenda. Finally, GCC is only a mediocre compiler. Alas,
because the GPL precludes commercial programmers from being rewarded for
making incremental improvements to it, and GCC destroys the market for
other compilers, we are stuck with this mediocrity. OpenBSD and all other
software compiled with GCC suffers as a result.
OpenBSD should stick to its priniciples and use a truly free compiler.
--Brett
Pedro Almeida
This subject already sucks!
BTW, last 9889897 posts are realy off-topic on te...@openbsd.org
Pedro
Wouter Clarie
> >charging thousands for compilers. Some markets are better dead.
>
> I disagree.
>
>
> --Brett
any suggestions?
Brad
// Brad
br...@comstyle.com
br...@openbsd.org
Jonathan Walther
Is Darren pissed because he wasn't given commit access to the OpenBSD
tree? Given his actions wrt ircd back in 83-84, I don't blame the
OBSD team. Still, if people decide to trust him *cough* maybe that
is a coin Mr Reed is interested in being paid in; given exclusive
control over how his source is integrated with OBSD.
Jonathan
On Thu, 31 May 2001, Joseph W. Shaw II wrote:
> That's one of my concerns. Darren obviously did know that OpenBSD
> included ipf as part of the distributions because it's listed on the
> ipfilter home page! I know Darren has commited code and changes to the
> FreeBSD CVS, so I'm wondering if he's granted them permission to change
> his work. I'm not sure if he has or has not, because as far as I know
> he's done all the work himself. This is based off Darren's own postings
> to the ipfilter mailing list.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQCVAwUBOxZZn8K9HT/YfGeBAQGcGAP/W3h6Cjwy53frUG1om7cNha19UNCNyCmm
UFSJkKuzNRAaCmm9KlPOGrgUCxqJn9ytY4r+UPSvKsUagg1r5pjhI6RfGjw1sfc+
os/mmyr2yk7VN8wRemFQ5aSKajMsMFvFgn2ZGYzVfDyiXBnd7mMIfWjPjWjDDHLI
1fhNqnKWuck=
=mSkS
-----END PGP SIGNATURE-----
Theo de Raadt
We are very happy that Brett has started work on alternatives, and even more
pleased that there will be a quiet period until such time as he has one in
beta test.
jason
Jason
On Thu, 31 May 2001, Pedro Almeida wrote:
> Date: Thu, 31 May 2001 15:42:24 +0100 (BST)
> From: Pedro Almeida <pe...@qui.uc.pt>
> To: te...@openbsd.org
> Subject: Re: ipf & gcc
drea...@dreamwvr.com
kj
ports(?) Just not in the base OS, which is fine.
K.J.
On Wed, May 30, 2001 at 03:38:18PM -0500, John Vernier Simon wrote:
> Sorry dude, but what you say sounds like one huge pissing match, if Theo wants
> to play ball like that, his call. I think it is a mistake, sure the license
> conflicts, and I am sure you and the lawyers and Theo and Darren and everyone
> can argue licening till the freaking cows come home. My point is that removing
> IPF is NOT helping OpenBSD, or the Open Source communities image. Big buissness
> frowns on this kinda bickering, and seeing this I am sure a lot of large corps
> will shy away from OpenBSD, even though it is the best and most secure OS. Oh
> well, have fun, I will be running IPF on Solaris till things get resolved.
>
> John
Daniel Corbe
considering the first version wasn't released until 1988.
--
Daniel Corbe <co...@corbe.net>
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS dpu s+:+ !a C++++ UBL++++$ P- L++++$ E--- W+ N++(--) o? K- w---(++++)$
O- M-- V PS(+) !PE !Y PGP- t+ 5-- X- R(+) tv+ b+ DI+ D+ G++ e* h! r-- y+**
------END GEEK CODE BLOCK------
Wes Peters
>
> Brett Glass wrote:
> >
> >OpenBSD should stick to its priniciples and use a truly free compiler.
>
Has anyone from OpenBSD contacted the OpenWatcom folks and expressed
an interest? They haven't yet posted any code, or any details of the
"open source" license they will use, but it might help them to know
there are "open source" operating systems other than Linux.
I haven't used a Watcom compiler for many years now, but they used to
have a reasonably good reputation.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters <w...@dobox.com> System Architect
http://www.dobox.com/ DoBox Inc.
Monty Brandenberg
> I'll take gcc with its annoying licence to the days of Unix vendors
> charging thousands for compilers. Some markets are better dead.
Or as I like to look at it: a parasite of a parasite is a
symbiont. Be a symbiont.
--
Monty Brandenberg, Software Consultant MCB, Inc.
mcb...@world.std.com P.O. Box 426188
mcb...@ne.mediaone.net Cambridge, MA 02142-0021
617.864.6907
Brett Glass
>Ya and that's a little hard when there are no good/useable FREE compilers.
Here are the two most promising opportunities to create one.
The first is TenDRA, which is licensed under what is basically a BSD license.
It's already in FreeBSD's collection of ports. The nice thing about TenDRA
is that it has a robust intermediate representation which encapsulates a
lot of the semantics of the higher-level code. This facilitates both
optimization and portability.
The second is OpenWatcom (http://www.openwatcom.org). This is the Watcom
compiler, which has been around literally for generations. (I used WATFOR,
an optimizing FORTRAN compiler for the IBM 360, back in 1976.) Sybase,
which now owns the compiler, wants to make it open source. (See
http://www.openwatcom.org/in_press1.html
on their Web site.) Watcom's latest C/C++ compiler already generates highly
optimized code, and the linker can output COFF and ELF. (It has to, because
it supports QNX.)
The OpenWatcom project has not yet chosen a license but is strongly
considering the BSD or Artistic License. If folks from the various BSD
projects say that they will adopt the compiler and contribute to its
continued development if one of these licenses is used, they are likely
to take these offers quite seriously. If Theo were to approach them, and/or
if other members of BSD projects did, they'd likely go for it.
--Brett
Artur Grabowski
> Is Darren pissed because he wasn't given commit access to the OpenBSD
> tree? Given his actions wrt ircd back in 83-84, I don't blame the
> OBSD team. Still, if people decide to trust him *cough* maybe that
> is a coin Mr Reed is interested in being paid in; given exclusive
> control over how his source is integrated with OBSD.
If it's not a license giving the same rights to everyone in the world we're
not interested.
//art
Wes Peters
>
> http://www.openwatcom.org/in_press1.html
>
> The OpenWatcom project has not yet chosen a license but is strongly
> considering the BSD or Artistic License. If folks from the various BSD
> projects say that they will adopt the compiler and contribute to its
> continued development if one of these licenses is used, they are likely
> to take these offers quite seriously. If Theo were to approach them, and/or
> if other members of BSD projects did, they'd likely go for it.
The latest postings in their contributor newsgroup suggests they are
leaning towards a Mozilla-ish license. This would be acceptable, would
it not?
--
Boats love me
Sails fear me
Brett Glass
>The latest postings in their contributor newsgroup suggests they are
>leaning towards a Mozilla-ish license. This would be acceptable, would
>it not?
Depends on the details of the license.
Based on my conversations with the people involved, my take is
that they'd actually prefer a BSD-ish license. The Mozilla license
is designed to allow Netscape to producing their own special version
of the product to which they have unique rights. This isn't
necessary here because none of the parties want to do that.
--Brett
Christian Bahls
>
> > I totally understand why Theo is removing ipf from the src tree and I
> > totally agree with him on it. But my concern is what are we going to
> > replace it with? Theo, Any ideas on what is going to replace ipf? And is
> > ipf going to go into 2.9 or not?
>
> Some people are looking at ipfw as a starting point. That leaves
> quite a few gaps at first, but we'll see what happens. Others are
> looking at other ideas. We'll see.
what about using the code from IPSec ..
it already implements an SPD ..
this would just have to be expanded
.. wouldn't it ..
you would have the benefit of a tighter integration
of firewall and IPSec .. you could use Keynote as well ..
my euro 0.02
christian bahls