Slashdot Mirror
IPF License Change: Redistribution Not Allowed
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.
This license applies only to certain test releases releases etc, that the author posts for testing purposes doesn't want in general distribution.
Information from Darren Reed on this appears at this URL:
http://false.net/ipfilter/2001_05/0458.html
Link to above URL
Want to see what's really going on? Visit This thread. Darren Reed (the author of IPF) has been poking his head in there. It's not a pretty sight either. Unfortunatly. Intreped (a poster) has made some intelligent commentary about the copyright law / policy near the bottom.
1. He wrote the software. /.
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!
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
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
Too bad OSI applied for a trademark on "Open Source" and got shot down because the term is too generic and has a plain english meaning.
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".
--
Business. Numbers. Money. People. Computer World.
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.
now we need to go OSS in diesel cars
This is actually an extremely valid point that has not been brought up yet (that I've seen). However I think that to "use" source code is to compile it rather than to change it. I have a feeling most US courts would agree.
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.
-Raphaël
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."
-Raphaël
Anyone else notice that Darren Reed and Theo de Raadt have similar personalities.
:).
I can't think of two people better to be to be mad at each other
It looks more like someone harassed him into changing the wording on HIS software to be more specific.
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..
But lots of folks believed that the original license permitted modifications, because they were permitted to "use" the source.
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.
"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.
The LWN story starts out with the necessary explanation: "IPFilter is the firewalling system used in FreeBSD, OpenBSD, and NetBSD". Kind of important, isn't it?
I think Darren is right: there is no change.
:o)
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.)
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)
--
Exigo spamos et dona ferentes
Whether you call it a "clarification" or not, the changes are changes and don't apply to the original license terms.
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.
Someday, you're going to die. Get over it.
IIRC the actual license cannot be changed for those releases which you received under a different license except this is stated. So a fork will appear. (Or maybe more: OpenIPF, NetIPF, FreeIPF... ;-)
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.
Someday, you're going to die. Get over it.
Yes, the -submitter- failed to mention or discover that Reed only meant the redistribution restriction to apply to certain test releases. However, the restrictions on modification apply to -all- releases, past and future.
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.
Someday, you're going to die. Get over it.
mathilda$ date -uz
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 ?
*/
An interesting thing is that Todd Fries bought the openipf.org domain on May 25.
Todd contributes to many opensource projects, like OpenSSH .
So maybe it means that IPF have the same future than SSH : a really free implementation will follow.
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.
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.
{{.sig}}
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? 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?
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
Perhhaps the author forgot to add the clause:
"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.
You have heard of the Term "fair use"?
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...
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.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
"...derivitive or modified works...
... If you have a series of adjectives all modifying the same noun, you generally do not write (or say) the noun after each one, its redundant. ...
"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.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
having an "open source" product without having the ability to modify ... creates a dependency on the author of the product to get a patch out. ... 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.
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."
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
How is this a clarification? The paragraph didn't exist at all in the previous versions. The license people agreed to when using previous versions did not include this restrictipon, though Darren may have wanted it to be there.
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.
ipfw is the standard firewall in FreeBSD (and it is more advanced than ipfilter, which is also in FreeBSD). See the latest release notes (search for ipfilter in this page). The FreeBSD Handbook doesn't even mention ipfilter, only ipfw.
Hub
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.
If a corporation is a personhood, is owning stock slavery?
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.
According to the author..."The licence has only ever granted right to redistribute/use, not modify. "
;-)
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.
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)
ok then your [sic] infringing on my copyright! Could you as [sic] me next time before STEALING my comments for your own?
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.
cat
All your major studies and BSDbots are belong to us...
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.