Slashdot Mirror
LWN on the Patent Encumbrence of SELinux
Anonymous Coward writes "LWN has a story about patents in SELinux. The article says: "Much of the actual work in the implementation of SELinux was done by Secure Computing Corporation (SCC). SCC, in its implementation of SELinux, used a technology that it calls type enforcement. As it turns out, SCC has a patent on this technology." Sigh.
From clause 7 at http://www.gnu.org/copyleft/gpl.html
"If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program."
Type enforcement is patented, yet the distro is freely available AFAIK. Plus, even though they retracted a previous FAQ on the source distribution for TE, it seems that they almost would have to keep any kernel modifications public or face down GPL issues. However, it appears that the whole issue is going to get skirted around by modularizing TE and also releasing a security policy config. Thus, without directly applying any hard change to the kernel per se, the license shouldn't be screwed with. It's still shady, but after a once-over it seems like they have enough of a loophole to wriggle through.
Never attribute to Hanlon that which can be adequately attributed to Heinlein.
No.
From clause 7 at http://www.gnu.org/copyleft/gpl.html
"If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program."
I'm pretty sure webpages have very little validity when compared to patents, but my favorite part of this debate is the fact that no one from SCC said anything until the use of SELinux in a commercial package was brought up on the mailing list. Even better is this page, which, after being around for about 2 years, 'magically' disappeared from SCC's website after the debate began on the mailing list. Take a look at Questions 5 & 6, which pretty much spell out that they released the work under the "letter and spirit of the GPL."
This is just another example of software patent BS. Doesn't the GPL forbid/advise against patents anyway? If that's the case then why would SCC bother to say they were releasing the work under the GPL? It looks more like they just noticed that there could be money to be made on this, so now it's time to break out the patents and scream about royalties.
Way to go, SCC. I think you've confused the 'spirit of the GPL' with something else far more ugly.
--Kylus
Idiot-proof something, and Life will build a better Idiot.
You should read the GPL. In the introduction, it states: "We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all." For the details, you should check sections 7 and 8 of the GPL.
Let's put this in a different way: if a company distributes some code for which they own a patent under the GPL, then the only way for them to comply with section 7 of the GPL is to allow royalty-free usage, redistribution and modification of the code. Otherwise, they would not be allowed to distribute the code under the GPL. They would have to stop distributing it, or change the license.
-Raphaël
I'll post the relevant section here:
The situation that the FSF had in mind was a company taking GPL code, then injecting patented code in a attempt to de-GPL it and make it proprietary. The protection provided by copyright is the leverage that enforces this.
What they didn't apparently consider was a patent owner voluntarily providing code (that they have the copyright to) under the GPL license. However, I think (I hope) the license is clear enough that if the code is GPL, it can't be retracted (even by the copyright holder) or restricted by patents.
IANAL, but I bet this is giving some FSF lawyers pause to consider whether they need an explicit clause in the GPL to cover this.
If you were blocking sigs, you wouldn't have to read this.
I believe that GPL 3 will fold a number of the IBM Public License concepts as they relate to patents into the GNU General Public License.
This is something we need sooner rather than later, and I'm hopeful that the FSF will recongize this need and make a new GPL soon.
Once this hapens, the ambigious situations like this one will be resolved (though the patent issue will still be there).
- Serge Wroclawski
The commercial restriction is a violation of the GPL.
If they have not enforced it yet, I am not comforted.
As a contributor to thier product (The total distro), I would be a concerned party, and in fairnes would want them to consider my input before violating my agreement to the GPL.
Does anyone know if there is a GPL for patents?
Not to start a GPL-free v. BSD-free flamefest, but the Tux, real-time, and secure Linux patents harm BSD, which is part of the free software community.
A patent is least harmful as part of a patent pool, as described in "Mutual Defense Against Software Patents."
These folks have a content filter available for the Squid Proxy Cache. When I hired on at my current employer, we were using MS Proxy with the Websense content filter. (Employer wants to block porn access in the workplace.) Anyhow, MS Proxy was requiring too much babysitting, so I investigated, tested, and switched to Squid running on Linux. SCC was the only vendor I could find that had content filter for Squid (on Linux, anyway).
So the first year we were on, our annual cost for filter was around $2000. Renewal time came, and they bumped it up to $4000. This year at renewal time, they bumped it to $7000. I politely explained to SCC that their pricing terms sucked, and that if it were my decision we wouldn't pay them that much to filter in the workplace. Their response was amazing. They said that the price increase was necessary because they were "filtering the entire Internet." Must be very busy people to filter the entire Internet.
Also had a problem with them at renewal time a year ago. We had paid one of their resellers for the annual renewal, and thought all was well. Then suddenly we were cut off from filter updates. When I contacted them to find out why, they said that their reseller had not passed along payment to them for our renewal. They also told me that they subsequently severed relations with the reseller. (Keep in mind that the reseller was an authorized agent of SCC when we purchased the renewal, acting on their behalf to sell the subscriptions.) I explained that we had paid their agent, and were therefore entitled to the service that was promised. After a bit of back-and-forth, they relented and allowed access to the filter update service.
Anyhow, I know this is a bit OT. But the point is that they have shown evidence of being either an immature organization, a greedy organization, or an incompetent organization (or any combination of such). I don't doubt that they think they're helping the world become a better place. But if they have patented software in ANY Linux distro, then good luck getting them to do the right thing. (At least without much kicking and screaming.) I don't trust these folks, and if I had my way we'd dump the content filter in a heartbeat.
oever asks:
Where is the problem exactly with patents in GPL-ed software?
Worst case scenario: a patent could make it illegal to use a particular software package, even one licensed under the GPL. Depending on patent laws, it could also interfere with redistributing GPL code.
If a company has a patent on a software technique and writes and distributes GPL code to implement it, anybody can use this code. Or can't they?
Potentially not. The GPL is a copyright license, it gives people the right to distribute the software. It is not a patent license, it does not grant people the right to use any patents.
A patent holder who is friendly to the Free software community will provide, seperately from the GPL, a license permitting anyone to use, for free, the patent within the context of software licensed under a Free Software license. The DFSG makes a good set of guidelines for this purpose. Generally such licenses are void if you sue the patent holder over their use of your own patents. These are called Royalty-Free patents (or RF Patents). Some companies, whose patents are purely defensive, give a royalty-free license to everyone who isn't suing them.
To my knowledge, SCC has not done this for the patents connected to SELinux. This is why people are upset.
And can people modify that code? I guess one cannot write new GPL-ed code that does the same thing.
You can modify existing code or write new code if and only if you do so within the bounds of the above discussed patent licenses.
Or can a company charge you for using the GPL-ed code with patents?
Yes they can. Let's say the ACME Software company comes up with a great streaming video codec, they post the specifications online and encourage people to use it. A group of people take those specifications and make programs to make, broadcast and view ACME video, the program gets distributed widely. Two years later we find that prior to publishing the spec, ACME quietly filed for a patent, and it has come through.
My understanding is that ACME would have the legal right (though not the moral right, IMHO) to charge everyone who uses that software, or who has used it in the two year period while the patent is pending, for each time they use the software, or distribute files that were made with that software. This scenario is not that different from what Unisys did with LZW encryption, and GIF files.
Note: I am not a lawyer, none of the above should be construed as legal advice.
----
Open mind, insert foot.
FSMLabs has a patent on running Linux as a thread within a real-time operating system that is used in their RTLinux distribution. If you develop a real-time module under the GPL, you are automatically covered by their patent license. If you want to release a real-time module under a different license than the GPL, you need to get a commercial patent license from FSMLabs.
In this usenet posting Linus states that neither he nor the FSF have a problem with the FSMLabs patent.
They've agreed to release the patent when they bundled their patent with GPL'ed code and distributed it. Under terms of the GPL, the intent is clear, a license to the patent is bundled with all GPL code that inherits from the existing distribution.
I know the guys who did the work at the NSA on SE-Linux.
The press is constantly making it sounds like the NSA outsourced the whole effort. They didn't the folks at the NSA did a huge part (majority) of the work. It would be nice if the articles started reflecting that.
No one goes to work at the NSA for the glory. But, they still deserve more credit then they get.
This work is extremely promising, in that it represents a well architechted, principle-driven design that can make guarantees about its security model (e.g. it provably enforces the confinement principle). Not only does EROS achieve significant security goals, but it does so while mantaining excellent performance.
Other bells and whistles of interest include transparent persistence. EROS' memory model does not include an explicit disk/filesystem layer. Instead, it uses a single-level store model, wherein the memory model is extended all the way down to disk. Periodically, a consistent system state is checkpointed down to disk. This includes not only conventional end-user data, but processes, IPC state, etc. Everything. Perhaps counter-intuitively, this is actually *more* efficient than conventional designs.
As a parting note, this kernel is still in research phases, and wasn't quite to the point where it's ready for major external application-level software authoring... but it's been making steady and impressive progress both in technology and implementation.