IPF License Change: Redistribution Not Allowed 117
An Anonymous Coward writes: "I found this at SecurityPortal, here. I use IPF and I noticed last week in the snapshot the license changed: 'Yes, this means that derivitive or modified works are not permitted without the author's prior consent.' which was kind of bad since it violated OpenSource guidelines. Now the current snapshot of IPF says 'Redistribution is not permitted' which completely violates any Open Source style license. Does this mean IPF will have to fork an older version or someone needs to write a completely new version for all the BSD's/Solaris/etc?" The old license certainly doesn't read this way to me, but IPF author Darren Reed asserts this is only a clarification of the license, not an actual change. Another ssh vs. OpenSSH? More coverage at LWN, partway down the page.
Re:I'm sorry.. (Score:1)
When you buy a painting you receive a fee simple [iown.com] title to it and you can do with it as you like. When you use IPF you are using it under license and to be legal you must abide by the terms of that license which, in this case, says you may not modify the code.
Re:Lets see here. (Score:1)
I have GPL:ed just about all programs that I've written, but idiots like you seriously make me consider stopping that.
Now, read slowly: the original licence did not give you a right to modify the code. It didn't mention the subject at all. I don't know how it is in your fairyland, but in the real world this means that you have permission to do only what is explicitly allowed by the "fair use" clauses of the copyright laws. Modifying and distributing the code doesn't fall under "fair use", and doesn't get even close.
No, try to get into your thick head that "Open Source" is not a right. On the contrary, a programmer has the right to choose any licence, including one of those that you don't like. If you don't like it, don't use the software. It is that simple.
Re:Already been here... (Score:1)
Copyright law grants the author exclusive rights. Unless he gives you those rights, he retains them. The license is clearly giving distribution and copying of the original source.
If you are confused about this, compare his license to a BSD license. Note the lack of the words "modify" (as in the BSD license) and "derived" or "derivative" in his license.
Re:Ambiguity works against the author (Score:1)
Amiguity of language does not apply here when law in question is otherwise clear. Ambiguity only plays a part when there is nothing else to refer to in order to make a decision of the validity of a complaint. However, here, we are dealing not only with contract law but with a license which falls under copyright laws.
And copyright law is very clear. The law GIVES authors exclusive rights. Unless those rights are explicitly transferred, the author RETAINS those rights. Ever see "All rights reserved" in a copyright? It was a phrase, still included in contracts today, to make it clear the author retains the rights not specified in a license. That said, it is a phrase that is NO LONGER NEEDED anymore.
Under current law, the rights on non-visual works include the right to distribute, copy, and modify (also known as derived works). IPFilter has a copyright statement, which removes any question that the author intended his work to have copyright protection. The license under IPFilter clearly states that the user may only copy and distribute the binary and source code.
The words modify, dervivative, or derived works were not used. That means, under copyright law, because the law GIVES the author rights, the author NEVER handed over those rights to the user of the software. He cannot give those rights away unless he says so.
Oh, and the word "use" is used correctly. Remember, the layman's interpretation of "use" is not the same as the legal implications. While you and I might read his license and think that we may modify the source code, he uses the word correctly. We may not, without his permission.
Re:Lets see here. (Score:1)
The license does not have to FORBID you from doing something. Copyright law GIVES the author rights, rights that only he may only give up clearly and specificly. The license does NOT give up those rights granted to him.
Your crap is like saying a person arrested gives up the right to a lawyer if that person does not ask for a lawyer. Bull. The accused has the right to a lawyer until he waives it.
Similarly here, the copyright holder is given rights as the author immediately when he publicly releases a work (even without a copyright notice). Until he gives up those rights himself, you can NOT assume that he has under copyright law. Before 1976, maybe you could--that is why you may see "All Rights Reserved" in copyright agreements, a holdover from the time when it was necessary to clarify that the author retains rights not touched on in a license. But today, those words are NOT needed.
Dammit, get a clue before you comment on this. You really don't know what the heck you are talking about.
Once again slashdot panics without the facts... (Score:5)
Information from Darren Reed on this appears at this URL:
http://false.net/ipfilter/2001_05/0458.html
Link to above URL [false.net]
Darren Responds (Score:1)
What's really happening... (Score:2)
Re:noone ever mentions cygwin? (Score:1)
___
Re:What if I contributed code? (Score:1)
Ahem, I don't want to be insulting, but from the same page:
So, to answer your question, no, Linus would not be able to release Linux under another license without asking permission from all the contributors. Also, the author of IPF cannot retroactively change the license, no matter what he would have you believe. (And make no mistake about it: this is not a clarification of the license, this is a retroactive change of the license). However, if he is the sole author and contributor of the code, he can release the *future* versions of the code under a different license without having to ask permission from anyone. He cannot, however, prevent FreeIPF from forking off of the latest free code.
___
Re:They're meant for each other... (Score:1)
whining about a problem that didnt exist (if
you read closer, the "no distribution" clause
ONLY applies to non-release beta/test versions
of the software), you'd be JUST A LITTLE pissy
too.
Its his software, he can do what he wants with
it. He has no obligation to release it under
any certain license, and he has all the right
to just tell people to fuck off if he wants.
He also has no obligation to anyone, anywhere,
in any way, regarding his software.
Just my two cents - next, someone will be
complaining that my comments arent GPLed...
Lets see here. (Score:2)
2. People *assumed* the license meant what they
wanted it to mean.
3. He clarifies the license (the distribution
policies of HIS software).
4. People complain they cant do things they
ASSUMED were okay.
5. People get up in arms and post to
Solution?
Just do like lots of other Open Source enthusiasts
do - IF YOU DONT LIKE IT, WRITE YOUR OWN!
Re:OpenIPF soon ? (Score:1)
Unless the netfilter developers make sure to contact all relevant contributors and get an OK for distributing under alternative licensing (ie, BSD style licensing), at least FreeBSD will stick with ipfw (which, contrary to the LWN article, is the primary firewall used in FreeBSD.)
Eivind, FreeBSD developer, speaking his own opinions.
Re:OpenIPF soon ? (Score:1)
(I'm assuming you mean "IPF" as in IPFilter) Well, it is in a sort of twilight zone. The original license can be read either way, and the way most people have read it has been different from what Darren intended with it. And this is the reason why IPFilter has been allowed into the base (along with Darren not saying anything about it, while he should be perfectly aware of the *BSD license policies, as he has a commit bit in both FreeBSD and NetBSD.)
We are looking at how to resolve it, with either Darren changing the license terms or IPFilter being delegated to a port.
Eivind.
Violate a license? I think not. (Score:1)
No, it non-free according to the Debian Free Software Guidelines and not open source, according to the Open Source Definition, but it doesn't violate any license. It's incompatible with Free Software and Open Source licenses, but that's a very different wording.
Editors... your job... please?
You have zero rights by default .. (Score:2)
But this does not make sense to me: this addition does change the meaning of the license.
Nope, remember that if you find some software just lying around somewhere, you have, by default, zero rights for that software.
All rights to use it have to be explicitly given to you by the rightsholder.
So if the license did not explicitly allow any use of modified code, that that's it. It was never allowed.
This is also why the GNU GPL works, agreeing on it is the only thing that will allow you to use the code.
--
echo '[q]sa[ln0=aln80~Psnlbx]16isb15CB32EF3AF9C0E5D727
Where's the netiquette? (Score:1)
Not being religiously fanatic about IPF or anything related to this incident, it's hard not to react to the extremely hostile mood that has been the result.
Is the pressure in the Open Source/Free Software/whatever meritocracy developing this hostility? Suddenly, it doesn't seem to be about writing good software - it's about showing your might and power so that you may speak with the Money that has entered the building...
Re:I like to know (Score:1)
Re:"Open Source" (Score:2)
You can have an "Open Source Definition", but there's nothing preventing Microsoft or Sun or anyone else from using the term "Open Source" to describe whatever they want. In fact the term runs counter to a long usage tradition of the word "Open" in the industry for software/hardware that has documented interfaces and behavior.
Which why "Open Source" is a lousy term for propaganda value.
There was an opportunity to invent a real identifable 'brand' a few years ago, but it was missed ("OSI-approved" comes close, but is dull), which is exactly why most slashdotters will spend their life arguing about what is or isn't "open source".
--
Re:Define "Use" and "Modification" (Score:1)
source code to be compilation thereof. The
benefit of having source is not that you can
modify it, but that you can compile it against
your setup with the optimizations you want.
This is similar to having a PDF of a book. The
"use" would be your ability to print it on any
paper you wanted not to plagiarize it by
taking you words and the original work and
"merging them together (usually in some coherent
way that works)".
Face it, he did not mention modification, and
as GNU documentation says (my paraphrase from
memory): nothing else grants you any rights
with respect to this software.
Define "Use" and "Modification" (Score:2)
Modification has been the whole purpose of making software free in the first place. The idea is if someone has an idea to make it better, they are able to do so reasonably if they have the source code. Licenses for free software have intended this in general (and often add other things, like GPL also requires your modifications to be equally free). Therefore, IMH(IANAL)O, the right to modify free software can be implied from common usage. An ordinary person involved in these projects could assume this. And the opportunity to exclude modification rights has always been available and easy to do (just say so, clearly).
And what is modification, anyway? It's taking parts of the original, plus what you contribute, and merging them together (usually in some coherent way that works). It's not all that far a concept from use.
Re:Define "Use" (Score:2)
"Shared Source" (Score:1)
Re:Previous Coverage (Score:1)
Minor correction (probably a typo): the link to Advogato should point to www.advogato.org [advogato.org]. The direct link to the article is correct.
Re:"Use in source code" vs. "no derivative works" (Score:2)
Let's take this from another point of view (suggested by an AC in another comment): if I am only allowed to "use" the source code for compiling it and running it but not using it in another project, then why does the license say that I should give credit "to the original author and its contributors?" This only makes sense if I am allowed to use this source code in some other project and re-distribute it.
"Use in source code" vs. "no derivative works" (Score:5)
The previous license says (emphasis mine):
Now the author claims that the license said that "redistribution" and "use" were allowed, but not "modifications" and he has added a statement clarifying that, claiming that it had always been that way:
But this does not make sense to me: this addition does change the meaning of the license. Allowing "use in source [...] form" should imply that I am free to use the (unmodified) source code in any project, thereby creating a "derivative work".
The debate over "modified works" is another problem. Indeed, the original license did not explicitely allow any modification to the source code, only its use. However, the license did not specify what is meant by "use in source form", especially what happens if you only take a small part of the source code and use it in some other project. Or if you use most of the original source code (without any modifications), and use it in a new project that contains only one new file that happens to be compatible with an old file in the original IPF code and provides some new features.
I do not know what a judge would think about someone who says "you can use my source code" as if it meant "look, but don't touch." Most programmers would think that "use" means "use whatever part of this code in any project, including modified versions."
OpenBSD (Score:1)
Does any one know what OpenBSD is going to do? (according to some sources there's little love lost between the ipf and OpenBSD camps anyway)
Re:They're meant for each other... (Score:1)
But to not talk to Linux Weekly News because "I really don't like Linux"? I fully expect a post from Darren that says, "Get used to disappointment" (which seems to be de Raadt's signature phrase)
They're meant for each other... (Score:2)
I can't think of two people better to be to be mad at each other
I'm sorry.. (Score:2)
The original license agreement says nothing at all about derivitive works or nonexclusive rights.
IT says you may use and distribute 'it' in source or binary form, 'it' being the source you are given.
Also, redistribution not permitted simply means YOU cannot redistribute it without the permission of the copyright holder. It does not mean nobody can have it.
Silly as it may be... it is.
And is he claiming it's open-source? I don't know..
The problem happens when meaning is unclear. (Score:2)
A judge would have to rule on whether or not "use" of source code includes modification. The author's intent doesn't count for much in this regard.
Re:Lets see here. (Score:2)
3. He clarifies the license (the distribution policies of HIS software).
He changed it, adding restrictions that were not stated, and that therefore did not exist originally in the license...
No, he did not change it. The point is made in this thread [deadly.org].
The license was never *BSD. Nobody is free to modify the code, since the right of modification doesn't exist if it isn't explicitly offered.
So there is no question of forking the code. If "OpenIPF" is ever produced it will have to be a clean-sheet development. Darren owns IPF.
And with the war of words that's under way, Darren would have to be a saint or a wuss to open-source it now.
Re:I'm sorry.. (Score:1)
Re:this sort of thing is important (Score:1)
Why Language Is Important (Score:2)
"Derivitive" is a nonexistent word. I hereby define it to mean "something which is not licensed under the GPL".
If this license referred to "derivative works" it would mean something else, but fortunately it does not.
Re:Forgive my ignorance.... (Score:2)
Re:this sort of thing is important (Score:2)
Re:I don't think that works... (Score:1)
If you write a patch to this or any software that consists of only code that you wrote then you would own the copyright to that code and license it however you chose without regard to the license for the software that you intend to patch with that code.
Define "Use" (Score:2)
I disagree.
his license only ever allowed "redistribution" and "use", not "modification".
How do you define "Use"?
If someone gives me source code, and says that I have license to "use" it - to me, that means that I have the right to modify it, because that's one of the ways to use source code.
Really, what's the point of giving someone source code if they're not allowed to modify it? (I guess the answer is to ask MS
There are many ways to "use" source code. Modifying it is one of them. Mr. Reed should have been more explicit in his original license (perhaps he should have contacted a lawyer.)
Re:Already been here... (Score:1)
The lesson is: Either consult a number of lawyers before writing a license or make damn sure you use a well known one whose properties you understand. The well known licenses like the GPL arent complicated as hell and full of legalese for fun, they are that way because they have to represent the whole concept and prevent any form of use not intended.
If his idea was to make just some more proprietary software then he should have said so. Of course, nobody would be actually using it in that case...
ianal, etc.
Re:"Use in source code" vs. "no derivative works" (Score:1)
Why? Because it is assumed/understood that is the intent.
As such, it would not be inconceivable for a court to grant that Source Code is used to make changes. Not simply to be read. So, providing the source code without stating that it cannot be modified might allow for it.
Redistribution of those modifications is up for grabs though...
Ambiguity works against the author (Score:2)
IANAL, but because this was ambigious, and was admitted to be so (because it needed clarifing) would it not fall directly under the principle of "contra proferentem"?
(Verba fortius accipiuntur contra proferentem: Latin: a principle of construction whereby if words of a contract are ambiguous, of two equally possible meanings, they should be interpreted against the author of the words and not against the other party)
--
Re:I'm sorry.. (Score:1)
Actually, you can't edit the source; Reed's clarification specifically denies modification privileges without his permission. Although I don't see him being miserly with simple requests from free/OSS software authors, you still don't have any rights to edit the source under his license. This is definitely more restrictive than the GPL, and far, far more restrictive than BSD. Don't confuse "legally comfortable" with "less restrictive."
Re:Partly (Score:1)
It's also not open source in the BSD fashion, which is more important in this case, since ipf is used by default in at least one *BSD implementation, and is available for others. This is really closer to MS "Shared Source." To that end, I point out the following:
The complete inability to modify the source or use it in a derivative work, at all, goes against Open Source licenses, which generally provide modification and use rights without restriction. This includes the GPL, the BSD, Apache (you have to rename your derivative works, but beyond that you can still play with the source), X11, etc.
This presents real problems for users of IPFilter, especially the OpenBSD crew, which uses ipf by default, and is apparently part of the reason Reed made this clarification. I don't see Darren being evil with refusing permission for BSD projects using the code, but it's still a restriction that generally doesn't appear in Open Source licenses.
Re:I'm sorry.. (Score:1)
Possibly. You would have to ask a lawyer or Darren for the final word on that. That's another issue the license does not address, and someone should probably ask him about that. He is perfectly within his rights to restrict modification of the source even for personal use; I believe this is what MS plans with its "Shared Source" initiative, look-but-don't-touch code.
Re:Already been here... (Score:2)
Unless the "changes" relate to something not specifically dealt with in the original license.
"provided that this notice is preserved and due credit is given to the original author and the contributors" is a fairly well understood phrase in the open software world in which Darren was working, and what it means has been fairly established.
I notice that you failed to quote the preceding
words..."Redistribution and use in source and binary forms are permitted". Note that "modification" is not explicitly mentioned, and hence relies on the copyright holder's wishes, whatever they may be; you cannot just take advantage of a loophole or particular omission and run. There is no restriction in Reed's particular license preventing retroactive application of new clauses, so even if this "clarification" is a change from the previous license, there is nothing preventing Darren from doing this.
It sucks, but there you have it. Lesson learned; read the licenses for software you intend to utilize.
Re:Already been here... (Score:3)
According to Darren, the modification restriction is only a clarification of the original license, and applies retroactively. He intended the restriction to apply from day one, but didn't explicitly mention it in the license. He could be right, he could the wrong; the ambiguity in language calls this into question. The lesson; read the licenses on software you intend to use, so you aren't taken by surprise by situations like this.
Re:Lets see here. (Score:4)
No, they assumed, naturally, that it meant the established meaning of the wording that he copied.
I don't recall seeing the word "modify", or any form of said word, in the original license, do you?
"Established meaning" might apply to GPL, BSD, and other widely-used licenses. This was Darren's own license for IPfilter.
3. He clarifies the license (the distribution policies of HIS software).
He changed it, adding restrictions that were not stated, and that therefore did not exist originally in the license,
He didn't specifically allow or deny modification rights, meaning the final authority on the subject would be the copyright holder...which is Darren. Ambiguous, yes, but lack of mention does not automatically mean you get that particular right.
and that therefore do not apply to the distributions before those restrictions were added (this is perfectly valid as it applies to the software distributed with the new releases, of course).
Not in Darren's interpretation, and since, again, there is nothing in his license preventing retroactive application of clarifications or changes (and Darren certainly sees this as a clarification, since he never specifically allowed modifications), it applies.
4. People complain they cant do things they ASSUMED were okay.
No, people are complaining that they can't do things that the license absolutely did not forbid before,
And absolutely did not allow. Once again, authority over unmentioned aspects reverts to the copyright holder - in short, Darren. Had someone asked earlier, they would have received the same answer. Instead, many assumed.
and which are a perfectly normal part of the "use" of the software source code.
"Use" can just as easily mean simple reading and compilation. Modification is explicitly allowed by other open source licenses.
In fact, that is a far superior solution, because it will prevent him from waiting until the competing software is complete, and then calling it illegal because of further "accidently left out" clauses forbidding reverse engineering the software and so forth and so on,
No sense doing that, as the source code is available for viewing and compilation, just not modification. In any event, rights not specifically granted by the copyright holder in a license revert to the copyright holder, to dole out as he or she sees fit.
and oh, that nondisclosure note he sort of forgot again to put into his "open" source, but which conveniently added just before the latest lawsuit he filed...
Non-disclosure would need to be specifically mentioned in this case, since he allows the source to be viewed, compiled, and outside of certain test releases distributed. An NDA would be a restriction on top of the previous rights he specifically granted to others, and would have to be specifically mentioned. Modification rights were never specifically dealt with.
Partly (Score:5)
For another thing, this isn't panic; this deals with legitimate license questions, and raises issues of using non-free-licensed code in free/open-source software. IPFilter's license does not allow any modification without the author's permission; although I don't imagine Reed being evil over modifications being made for the *BSDs, it still goes against some of the spirit of OSS, and it calls into question how lax software maintainers should be about the licenses they allow into their software, especially when a clarification like this reveals restrictions that weren't explicitly mentioned previously, but are assumed to apply retroactively.
I can forsee a code license audit coming soon after this incident.
And... (Score:1)
Nice, but no. (Score:1)
No, this would not prevent that... (Score:1)
The no-mod/no-deriv change does apply to all versions of ipf and not just test builds.
That said, if Red Hat wants to shoot themselves in the foot and lose credibility because of insufficient testing of a fundamental component of the software they release, that's their problem. That software should still be available for those who know what they're doing to help diagnose and fix issues, and to move it from a test build or beta to stable. This isn't closed source, commercial software. We shouldn't disappear for periods of time, hiding intermediary builds, and suddenly reappear with a build we claim works.
The transparency afforded by most Open Source/Free Software projects is just as important as the fact that we can read/modify source at stable releases.
But hey, if you think that hiding the process is the best way to go about improving stability and security, you can go back to your Windows box.
Redistribution is not permitted. (Score:2)
Mon May 28 13:43:48 UTC 2001
mathilda$ fetch http://coombs.anu.edu.au/~avalon/ipf34-current.tg
Receiving ipf34-current.tgz (579329 bytes): 100%
579329 bytes transferred in 0.1 seconds (6.12 MBps)
mathilda$ tar xzf ipf34-current.tgz
mathilda$ cd ipf34-current
mathilda$ cat LICENCE
/*
* 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 is not permitted.
*
* 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 legalese, don't you ?
*/
We all lose. (Score:1)
It's nearly impossible to retroactively change a license. Once you give away the farm, it's hard to take it back.
This story shows how important it is to have a good license statement, and why it's easier to make use of some of the standard licenses out there. He should of spent a little more time writing the license if retaining his rights was important, perhaps with a lawyer. He should have tried to reuse one of the popular, well-established licenses versus writing his own.
Live and learn, I suppose... well, hopefully others won't make the same mistake.
Re:OpenIPF soon ? (Score:1)
OpenIPF soon ? (Score:4)
Todd contributes to many opensource projects, like OpenSSH [openssh.com] .
So maybe it means that IPF have the same future than SSH : a really free implementation will follow.
At the same time, Linux Netfilter [samba.org] is growing. While it's not as mature as IPFilter, it's definitely featureful, and going in the right direction.
So maybe the BSD folks can work with the Netfilter dudes instead of reinventing the wheel. We would get only one free packet filtering system, but common to many system, with many developpers, and that would beat everything.
Porting Netfilter to BSD systems is not impossible. Internal socket structures are different, but the way protocols are analyzed can be left unchanged. And it should be also easy to code a parser that would rewrite IPF rules into Netfilter rules, so that people would be able to easily migrate.
What if I contributed code? (Score:3)
Does this mean that any code that I contribute needs to be contributed with a license? Is it not fair for me to assume that any code contributions that I make to an open source/free software project are licensed under the same terms that the original author offered me?
What this brings up, is whether or not the author of an opensource or free software project is really allowed to relicense the code. Especially if that code is GPL'd. Say for example Linus decided to make something proprietary with Linux. As the original author, he's got the right to relicense the code, right? Well if he does, then what about all the code that was contributed by someone else?
If you're saying that he doesn't have the right to relicense the code, doesn't this go against what RMS says [gnu.org]? Or is this only allowed for the initial release of the software. Does the original author have any rights to change the terms of the software license after someone else has contributed code?
Re:Already been here... (Score:1)
No, I don't think so. Whether you call it a "clarification" or not, the changes are changes and don't apply to the original license terms. "provided that this notice is preserved and due credit is given to the original author and the contributors" is a fairly well understood phrase in the open software world in which Darren was working, and what it means has been fairly established. I don't care if he adds "except that distribution is not allowed by left handed people" and states that he originally intended that such sinister characters not be included, or whatever, license changes don't propogate retroactively.
Humpty Dumpty's Software License (Score:2)
"The provisions in this license mean, now and in the future, exactly what the author wants then to mean, neither more nor less".
Unlike yourself, I do not believe this is automatically assumed to be a standard part of a software license or other legal document.
Default rights (Score:2)
Poisoning the well (Score:2)
Even though new substitute package would likely be (and should be) written by those expert programmers who have already concerned themselves the IFL package, and naturally have gone through it with a figurative fine-tooth comb looking for security holes)? That kind of knowledge of the software seems to create a legal assumption that the resulting new software is a copy/paraphrase/erivative work, going by the the results of between-corporation lawsuits.
Gee, too bad. I guess that makes the competing package a lot harder to create, doesn't it? How convenient for that original author again...
Re:Lets see here. (Score:3)
Given.
2. People *assumed* the license meant what they wanted it to mean.
No, they assumed, naturally, that it meant the established meaning of the wording that he copied.
3. He clarifies the license (the distribution policies of HIS software).
He changed it, adding restrictions that were not stated, and that therefore did not exist originally in the license, and that therefore do not apply to the distributions before those restrictions were added (this is perfectly valid as it applies to the software distributed with the new releases, of course).
4. People complain they cant do things they ASSUMED were okay.
No, people are complaining that they can't do things that the license absolutely did not forbid before, and which are a perfectly normal part of the "use" of the software source code.
5. People get up in arms and post to /.
irrelevent, except as a troll.
Solution?
Just do like lots of other Open Source enthusiasts
do - IF YOU DONT LIKE IT, WRITE YOUR OWN!
That's one solution. An equally valid one being to fork the code from the last version that did not contain the new and odious restriction which would forbid that forking, and if he doesn't like that and goes to court, to watch as the judge laughs him out of said court once the situation is explained.
In fact, that is a far superior solution, because it will prevent him from waiting until the competing software is complete, and then calling it illegal because of further "accidently left out" clauses forbidding reverse engineering the software and so forth and so on, and oh, that nondisclosure note he sort of forgot again to put into his "open" source, but which conveniently added just before the latest lawsuit he filed...
I don't think that works... (Score:2)
I think you missed a point.
To create the patch file you have to do one of two things:
Create a derivative work and diff them.
Write the patch file from scratch.
Writing a patch file from scratch that even applys correctly is difficult without at least trying to apply it, which also creates a derivative work. Writing one that produces working code is virtually imposible. (Did you ever get even a single subroutine to compile and run correctly the first time? Not impossible with a small one, but extremely rare.)
Copyright is a civil matter, so the standard of proof it "preponerance of evidence". A patch file that applys correctly and produces working code with a feature added or changed in a predicted way should qualify for that test, and bring copyright's draconian penalties to bear.
(And then there's the question of whether a context diff is itself a derivative work or if the included text qualifies as "fair use".)
IANAL. But this sure makes sense to me.
You missed the spelling flame. (Score:2)
"Derivitive" is a nonexistent word. I hereby define it to mean "something which is not licensed under the GPL".
It does refer to derivative works.
You missed his point. What he posted was a spelling flame. The original misspelled "derivative" as "derivitive" and SEWilco keyed off that and declaraed that, since this was a new word, he could define it as whatever he wanted.
Of course the meaning is clear despite the misspelling, and what's important is whether a "reasonable and prudent" licensee could be expected to understand what was meant. So if the word was misspelled in this way in a license it wouldn't invalidate the license.
You interpret it correctly but... (Score:2)
It's bad but not AS bad.
In the "read but don't touch" model you've still got the world to debug the code, diagnose any security failures, and supply proposed changes. You're just dependent on the copyright holder to apply and distribute them. In the closed-source model all the world can do is submit bug reports, which the small team must sift for REAL bugs, diagnose the probles, write and test the changes, and THEN apply and distribute them.
Not as nice as being able to apply your own changes, or those supplied by others, while you're wating. Definitely not as nice as being able to publish fixes. But it's still ahead of "peh-TI-shun-ing the LAW-ud with prah-AY-uh" and waiting for a vendor to notice that the bug is real and decide it's worth fixing before they even START to TRY to fix it.
Still I prefer Linus' model: "The OFFICIAL kernel has only what I approved and added. Hack all you want, but don't blame me if it blows up."
Retrospective licensing? (Score:3)
Just because he's added it there now and *wanted* it to be there all along isn't a clarification of the license, its a modification of the license to suit the authors long term intentions.
The software now does not meet any of the FSF free doms and also the Open Source Definition.
And yes, the OpenBSD team is having trouble with the license already.
Re:I'm sorry.. (Score:1)
Another wrong fact: (Score:2)
Previous Coverage (Score:4)
One more reason to stick with ipfw (Score:1)
Re:OpenIPF soon ? (Score:2)
I think it would almost be easier to implement free ipf from scratch. In a way, the hard part was coming up with the conceptual framework. Once you understand ipf syntax, writing the firewall should be less than astronomically difficult.
Thoughts on this (Score:1)
Having followed this topic on the ipf list for the past couple of days, I'm not sure if the change is as serious as people think, or if it is more serious.
What I do know is this. Linux has had three very different filtering systems over the past three major kernel revisions. ipfwadm in 2.0, ipchains in 2.2 and netfilter / iptables in 2.4. Granted, iptables aren't that big a change from ipchains, but it's still a pain to have to upgrade all your filter scripts and learn new syntax every time a new major kernel release happens.
Over the same period of time ipfilter has stayed the same. It has retained it's syntax and most importantly, it has run on many different systems.
ipfilter was one of the contributing factors in our decision to drop Linux in my company. We have to maintain sun solaris boxes for certain clients, and we already use ipfilter on our OpenBSD firewall. But we had filters on all machines as additional layers of security. By dropping Linux and moving to FreeBSD we still have a powerful server platform, and we get to standardise on our filtering tools
For us, this is a good thing. Less different packages to maintain in an organisation means less chance of things going wrong. Less chance of things going wrong leads to more free time for my staff and me.
So ipfilter has been a blessing for us. We can now use the same filtering scripts on our database servers be they Sun or FreeBSD. We have the same webserver set of filtering scripts for Solaris, FreeBSD and OpenBSD. Everything all nice and tight.
Now the downsides. When the fragment bug was found in ipfilter 3.4.16, we had to upgrade it on 20 servers. That's a pain. If this licence does cause people to shy away from ipfilter that will be bad too, purely because there will be less support going into it and it will take longer for things to get noticed / fixed.
I read talk of OpenIPF, but how long will that be? It was quite a while before OpenSSH was able to work as a drop in replacement for SSH.
Just my thoughts.
/* Wayne Pascoe
You Can't Fork It. (Score:2)
Whether or not we like this, this is the way it is. The author has his rights. He created a license that gave users certain rights. The lack of statement on other rights (distribution of derivative works) does not (and cannot, for licensing to be a sane process) imply granting of those rights.
Re:I'm sorry.. (Score:1)
That, in fact, was one of the things that kept the United States out of the Berne Convention for a long time. Berne requires protection of certain rights called "moral rights" of authors, and one of those rights is the protection of the integrity of their work. This goes way beyond what the US thinks copyright should cover.
To get into Berne, the US enacted these moral rights, but only for a very small set of works, and then the Berne countries pretended that that was enough, and the US joined.
noone ever mentions cygwin? (Score:1)
Their marketing docs say that cygwin is GPL, but in reality that license is only for certain groups, commercial companies still need to pay distribution royalties...
Re:noone ever mentions cygwin? (Score:1)
Re:New security model? (Score:2)
Security through obscurity fails to function with proprietary software, but even more so with open source software that nobody is permitted to fix. A security issue is discovered by code review but to remedy the issue is to breach the license terms.
Re:this sort of thing is important (Score:1)
Re:OpenIPF soon ? (Score:1)
At the same time, Linux Netfilter is growing. While it's not as mature as IPFilter, it's definitely featureful, and going in the right direction.
and then you go on to say
So maybe the BSD folks can work with the Netfilter dudes instead of reinventing the wheel.
Did you mean to say that the Linux people (who are the one currently reinventing the wheel) should be supporting the BSD people as the BSD people have the more featureful and mature product?
Re:Partly (Score:1)
*sigh*
The fact here is that nothing is "being assumed to apply retroactively." Under copyright law generally "all other rights are reserved." I'm quite sure that you've seen that phrase used over and over and over. It does, in fact, impart a specific legal meaning. And even if a copyright license does not expressly state that phrase, it is implied.
Now, nowhere in the license did Darren Reed ever grant the right for others to modify his software. That means that you did not have that right and never had that right. There is nothing "retroactive" about it.
To further illustrate, lets look at the BSD license:
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: [...etc...]
The BSD license looks oddly similar to Darren Reed's IPF license except that it explicitly grants you the right to redistribute the source and binary code with modification. Since it explicitly gives you that right, you have that right and it is not reserved. On the other hand, had that phrase been left out of the BSD license then you would not have been granted that right. Since Darren Reed left that off of IPFs license, you do not have that right. There is no "but it looks like a BSD license, he's trying to fool me!" defense in copyright law.
All that Darren Reed has done with this action is that he's obviously gotten fed up with people confusing his license with the BSD license and decided to clarify it so that he doesn't have to deal with the headaches. He could have left the clarification off and you still wouldn't have the right to modify his software. The clarification does not legally change his license at all.
Re:Lets see here. (Score:1)
What's amusing is that the OSS license most closely resembling the IPF license is the BSD license which states:
"Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: [..etc...]"
In the context of the BSD license it seems clear that his deliberately leaving out the clause pertaining to modification of source code was meant to prohibit that right.
He changed it, adding restrictions that were not stated, and that therefore did not exist originally in the license, and that therefore do not apply to the distributions before those restrictions were added (this is perfectly valid as it applies to the software distributed with the new releases, of course).
Unfortunately, under copyright law all rights which are not specified revert to the holder of the copyright. He doens't have to give an itemized list of all the ways using his software is prohibited. All he is required to do is to grant your privaleges. Anything else is prohibited. So the fact that the restriction was not originally stated does not change anything. Since it was originally allowed it was prohibited. It always existed there in a legal sense.
Go ahead and talk to a laywer if you don't believe me. This is Copyright Law 101.
Re:Define "Use" and "Modification" (Score:1)
Yup, you're certainly not a lawyer. You don't have a clue.
Hmm (Score:1)
Of course, ipf.c has claims within it that run contrary to this, and the license changes only affect the test versions -so far-.
If that same license makes it into the production versions . . . well, doesn't FreeBSD have a nice firewall package anyways?
--Ryvar
¹"No redistribution" is NOT open source (Score:1)
It's open source. Just not free software.
Bull. A program that cannot be redistributed in source form violates provisions 1 and 2 of the Open Source Definition [google.com].
Re:Ambiguity works against the author (Score:1)
I note that you don't claim to be a lwayer yourself, nor give any references to confirm the assertions you make in your post.
Under currto put into service ent law, the rights on non-visual works include the right to distribute, copy, and modify (also known as derived works). IPFilter has a copyright statement, which removes any question that the author intended his work to have copyright protection. The license under IPFilter clearly states that the user may only copy and distribute the binary and source code.
Nobody is claiming that the author needs to specify exactly what rights he or she isn't giving away. However, if one explicitly grants a broad-sounding right such as the right to "use" the source, it seems ludicrous to suggest that the author can then "clarify" it so as to eliminate the right to use it in certain ways. The fundamental question, of course, is what exactly does the right to "use" source code entail? I haven't yet seen a definitive answer.
Oh, and the word "use" is used correctly. Remember, the layman's interpretation of "use" is not the same as the legal implications. While you and I might read his license and think that we may modify the source code, he uses the word correctly. We may not, without his permission.
Okay, now we're getting somewhere. So you are aware of a legal precedent establishing what it means to "use" source code? Can you provide a reference? Exactly what rights does the right to "use" the software give you?
There's a legal dictionary at www.lawyers.com [lawyers.com]. I looked up "use"; the definition given for "use" as a verb is:
Looking up "service" provides nothing meaningful in this context. The definition given for "enjoyment" is:
That looks to me to be at least as broad as the everyday sense of "to use".
could this be worse than MS? (Score:2)
Dang...it looks like I can't submit those patches to that major security hole I found...I guess I will just have to exploit everyone til they learn.
No..but seriously...having an "open source" product without having the ability to modify kinda makes it a bad model. This creates a dependency on the author of the product to get a patch out. IANAL...but this seems worse than MS...because if you are relying on something that has 1 main author in this model...you technically could only get a fix from him/her. At least MS has a team of maintenance developers in case one is in the hospital.
As always...please correct me if I interperted this incorrectly.
Updated SecurityPortal artilce (Score:1)
Re:OpenIPF soon ? (Score:1)
Unfortunately, this discussion is in danger of degenerating to an OS war.
As it stands, the netfilter project is composed of a set of kernel features in the 2.4.x kernel and a userspace tool called iptables. As the featuresets of IPFilter vs netfilter can be argued, I have serious doubts that the netfilter project has much to contribute to firewalling on BSD. Programmers would have much greater impact contributing to the IPFW project.
Re:I'm sorry.. (Score:1)
Re:Already been here... (Score:1)
Re:I'm sorry.. (Score:1)
Re:I'm sorry.. (Score:1)
Fair Use criteria:
- The purpose and character of the use - to fix bugs and create compatibility, add features
- The nature of the copyrighted work - pretty much standard here
- The amount and substantiality - because this isn't copying, presumably this would be counted differently
- The effect of the use upon the potential market - zero
I'll take my chances. I believe that the constitution protects my rights to modify source code (or even binaries) for personal use. I don't think this would extend to cirumvention of particular intentional parts of the product (for example, for example an expiration or limit on simultaneous users), but I do think it extends to bug fixing, compatibility enhancement, and minor feature enhancement.Re:The Constitution doesn't give you Fair Use (Score:2)
Perhaps you should read the tenth ammendment: "The powers not delegated to the United States by the Constitution, nor prohibited by it to the states, are reserved to the states respectively, or to the people."
As applies to copyright, as you said, the constitution says: "To promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries; "
The supreme court has taken this to imply that copyright which does not "promote the progress of science and useful arts" is unconstitutional. Granted, they could whip out the "interstate commerce" clause, and let the federal government do just about anything it wants (and have done in various other types of cases), but fortunately they have not done that as of yet. Further, they have outlined the fair use guidelines which I posted, and commanded the lower courts to use them.
State law is a completely different matter, the states can restrict anything they want, as long as it does not infringe free speech (and the other constitutional rights). But I'm talking here about federal copyright law. A District Court ruling which gives summary judgement without addressing the Supreme Court guidelines with regard to fair use would be immediately struck down by the Supreme Court. The District Court would then have to listen to the fair use defense, and make a ruling. An improper ruling by the District Court would then go back to the Supreme Court.
I contend that disallowing bug fixes and minor compatibility enhancements for a product does not even arguably promote the progress of science and useful arts. I'm talking about a product which you already have the source code for, I understand that it can be argued that not providing the source in the first place promotes the progress of science and useful arts. But I'm saying that this case is pretty much indisputable.
That's what fair use is all about. You got half of it right, but you forgot about the tenth ammendment.
The primary objective of copyright is not to reward the labor of authors, but "[t]o promote the Progress of Science and useful Arts." To this end, copyright assures authors the right to their original expression, but encourages others to build freely upon the ideas and information conveyed by a work. This result is neither unfair nor unfortunate. It is the means by which copyright advances the progress of science and art. - Justice Sandra Day O'Connor (Feist Publications, Inc. v. Rural Telephone Service Co., 499 US 340, 349(1991)
Re:Already been here... (Score:2)
Aside from that, it seems rather comical that Darren slipped this under the nose of the BSD Gurus. They should have never allowed this into their distros in the first place. Basically, it amounts to unmaintainable code.
Re:*BSD is dying (Score:2)
Re:Already been here... (Score:1)
Therefore, I suspect that in this case, benefit of the doubt would to to the parties using the software and not to Mr. Reed; where it is ambiguious then the courts would tend to find in favour of the more permissive reading of the license.
But then, I'm not a legal lamb...
Re:What if I contributed code? (Score:2)
It's quite simple:
[1] You can of course change to a compatible license. Also, this also applies if the contributions are covered by copyright, which might not be the case for small trivial changes.
oss control (Score:1)
Re:NOT FLAIMBAIT (Score:1)
this sort of thing is important (Score:2)
This seems like a fairly benign case: the code is self contained and can be removed if Darren doesn't change the license (and he is under no obligation). If this code were more integral to the system, it would potentially be a big problem. In fact, I wonder now whether the BSD project has really made sure in other, more critical cases that all contributions to the project really are made under the BSD copyright.
The FSF is picky about copyright assignments and licenses for a reason. Open source projects really need to pay attention to this or they put their whole user community at risk.