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.
I've been watching this on the Linux Security Module mailing list and have high hopes that SCC sticks to their original promise and not place restrictions on the use of this technology. There are plans to get this into the Linux 2.5 development tree and eventually have it available in 2.6. This is the sort of security technology we desperately need in a popular OS, so let's hope SCC does not prevent its movement towards integration with the main Linux source tree.
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 think that this also falls under the class of submarine patents. Either way, if I'm right in my conclusion, they can't do anything about it - you can't "unlicense" a GPL license; and it's non-exclusive, so anybody that has it can keep it going even after you stop offering it...
Summary: Chill out in the walk-in freezer!
SIG: HUP
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.
yep
its all stupid
patents should be on a process and as such software should not be patentable
its like saying I have copyrighted the ability to write trashy novels
there is no way that you could get away with this
simple because its too wide rangeing people argue that their software patents cover very specific things but unfortunatly you cant have them if you dont allow the wide rangeing
frankly its all a mess
just say no to software patents in europe
write to your MEP if you live in europe
Who is my MEP
regards
John Jones
- how are those patents going to benefit the companies that filed them ? It's mainly a closed-source word out there, how are they to prove that a competitor used the same technology in a closed-source product ?
- it does not appear to harm the free software community for the moment, but what later ? What if those components are no longer distributed under a free license ? SE Linux raises the problem with the explicit mention being removed from their pages, as mentionned by LWN.
- isn't it just a problem with the US patent office, who are overloaded with work, who do not always check the validity of a patent with regards to prior art, and the US legal system which allows lawyers of big companies to blackmail and racket smaller companies on unfair patent claims ? See this site which refers to a previous
/. post on the subject. I personnaly think that kind of situation is an incentive for RedHat and SELinux to spend big bucks on patents.
I clearly don't see the free software community benefiting from this situation. Individual programmers will have to face both the possiblity that a rogue company sues them unfairly for patent infringement, and the possibility that another company, owning patents on parts of free software, changes its attitude towards the GPL and decides to un-GPL their code and go proprietary.Say "thanks" to US lawyers and Powers That Be for allowing that nightmare to come true.
In Soviet Russia, our new overlords are belong to all your base.
I've heard the same phrase applied to capabilitiy-based architectures, but these are systems built around hardware enforcement, and I get the impression that SCC's scheme is software-based.
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."
In the commercial world, patent wars often end with the formation of a consortium that holds the patents and enforces them (where necessary). Is there such an organisation for open source? If not, why not?
It might seem a bit daft in the current case where SCC have GPL'd their code, but consider this:
1. Company A dual license their product - free under the GPL, and non-free under a closed license. The free version could contain community patches, the non-free version could not, but the non-free version could be licensed by a third party without that third party having to open its source. Patent fees would apply in this case.
2. Company R supports GPL'd product L, Company M makes closed-source product W. R patents several of the changes they have made. They are then sued for patent infringement by M - R countersues, via the umbrella group for infringements in W, not for patents they hold directly, but for patents held by the umbrella group on behalf of members.
This assumes you can GPL license and enforce patents on people who are using the patented invention, rather than a copy of the code, in their product (code copying is obviously covered by the GPL directly). I don't know that this is true - and I doubt that Stallman would approve. However it might increase the sense of safety people have with patents like this and the Red Hat ones waiting in the wings; it may also encourage more companies to GPL, since they retain the ability to chase closed-source competitors who steal their ideas.
Just a thought.
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.
Yeah, it's a patent-law versus GPL thing, but (at least to me) it appears to be cut-and-dry. Linux existed, with its use of the (L)GPL as its license. SCC held their patent and chose to modify Linux to make use of their technology. They are a 'consumer' of Linux, and Linux is NOT a consumer of their technology. They are, before any consideration of patent law is considered, required to comply with the GPL in regards to adding anything to Linux.
So they (we assume consciously) chose to work their code into Linux and redistribute it. This action implies intent to comply with the GPL. Considering the specific requirements of the GPL in regards to patents (must be royalty-free for ALL users who can receive the distribution), the only logical conclusion to draw is that SCC aggreed at the moment of distribution to permit use of their patent within Linux as royalty-free to the public (which includes individuals, governments, deities, and businesses alike).
it's a fairly a->b->c sort of thing. The only thing assumed is that SCC had the conscious intent to comply with the GPL... If they never intended to comply with the GPL, then this whole point is moot and they are in violation of the license! This certainly isn't a rocket-science concept to understand.
So what are our outcomes? (1) SCC provides royalty-free use of their patent in SELinux, (2) SCC withdraws their code, (3) SCC tries to play hardball by requiring licensing while violating the GPL and tries to fight the GPL in court. The likelihood of 3 doesn't seem too likely.
.... um, i lost you after "0110100001101001".
All it would take is one killer app license under the OPL to create public demand. Then if anyone wanted to duplicate that functionality, the OPL would allow it -- BUT the corresponding GPL (or the OPL itself if properly worded) would require developers to release source code with their implementation.
I submit that this would have an even GREATER impact than the GPL. Developers would be free to try widely disparate approaches to achieving the patented functionality. The different algorithms and approaches could be compared with the best methods prevailing because the best code would be that actually used. Think of the contribution to computer science possible with widespread comparison of designs. I think the industry-wide effects would result in much higher-quality code in general.
Don't tell me that Open Source cannot get patents. If someone bothered to look, they could find a patent attorney who would be thrilled to get a patent for Open Source code as long as someone paid the filing fees (for small entities, about $350). I am a registered patent attorney and I would be thrilled to prosecute one of these applications. I'm sure I am not alone.
Laws affecting technology will always be bad until enough techies become lawyers.
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.
OK, but what I'm interested in is what happens to the source that's already out there, with a GPL license on it. If they now try and enforce their patent, they void their GPL compliance, and lose the right to continue distributing code based on or linked with GPL code. But it's already out there. So what happens to their (copyrighted) source that was distributed under the GPL and which is now in the hands of many individuals?
They can't retroactively remove the GPL granted rights from that source, but on the other hand, they can't apply the GPL to it now or continue to distribute it. So if I have a copy of it (and I do), can I continue to modify and distribute their source? I didn't violate the GPL, and I'm not applying patent restrictions, so why should I (and the potential recipients) suffer from their patent lockdown? But then it means that I can keep distributing their source with a GPL license on it, but they can't, which gives me more powers. But heck, they can still sue me for patent infringement, because patent law is separate from copyright law. The GPL gives me the right to copy, modify and distribute their source, but their patent stops me from using it!
This looks like a bit of a legal minefield. I'm usually fairly clear on where the GPL leaves me, but in this case I'm stumped.
If you were blocking sigs, you wouldn't have to read this.
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.
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.
IANAL... but,
Maybe I'm stupid (Well, feel free to call me stupid: I just read the slashdot header and not the referenced articles), but as I see it, they also used patented techology from Seagate on their harddisks during the development. Does that mean that Seagate can claim a licence fee on distributing Linux? No!
Same here. They used a patented technology in the process of improving the Linux code. So that doesn't make the Linux code fall under the patent....
Now, "Type enforcement" is a technology that dates back from at least the early seventies (Pascal, algol). Those patents are either expired, or there is prior art. Or maybe they patented something like "type enforcement in relation to computer security". Well, that was invented in the sixties.....
Roger.
GigsVT - It's not against the GPL to aggregate the distribution of GPL and non-GPL, even closed source, or patented components.
My original response was to the "one line of code anywhere in their distro".
The hinge would be on the word aggregate, I won't conceed that a 'secure linux distro' would be considered a simple aggregation. If they were distributing a 'secure linux component' I could see restrictions being allowed.
The following is from the end of the preamble to the GPL, I for one think it is quite clear.
Finally, any free program is threatened constantly by software patents. 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.
I am becoming increasingly concerned about the rising numbers of 'closed distros' that ride on the backs of folks who have had the courage to free thier work for the benefit of all, only to have a few take the benefit of themselves.
There has been great debate about what free means, but there also appears to be some confusion as to what open means in the GPL.
Your assertion is that nothing was violated, not about 'one line of code'.
I contend that they have at the least violated the spirit of the GPL copyright, even if by chance the didn't violate the law.
They need to find a way out of the box they've put themselves in and soon.
In so doing, they will blow away their own ability to distribute Linux (possibly permanently). However, they will also be setting up a situation where nobody else is free to distribute (or use?) their patented stuff either. Those people will then be unable to distribute Linux either- to the extent that it depends on the patented stuff. They'd be able to distribute OTHER Linux dists that did not contain the patents.
So it's a doomsday switch: having anything patented in Linux provides a chance for the patent holder to blow themselves away and also take out everybody else, to the extent that the patented stuff is indispensable. If there was a patented thing that was absolutely indispensable to Linux, it would be a tactic that could shut down the whole movement (causing it to be GNU/ with nothing after it ;) ). It would require that the patent holder blow away their own work and, as someone else said, be a 'patch looking for a kernel', which is simply a measuring of relative value: is the financial hit of ruining the value of this IP less than, say, 40 billion dollars from MS for killing off Linux and making everyone start over with the Hurd?
For these reasons I'd say, totally reject patents in the context of free software. Any patents, even 'defensive' ones, can potentially cause this situation, and I would have thought the technolibertarian 'let's make our own patent pool and fight it out rather than ask that the rules be changed' types would be the FIRST to accept that, if offered enough money, anybody'll crack. In a perfect idealistic world, maybe 'open source patent pools' would be safe, but we don't live in one, and in practice it's more like stockpiling dynamite and using it as barricades. Stupid!
The outcome to watch for is (4) SCC blows away their license to distribute Linux and then shuts down all Linux distribution that involves their patented stuff, until the patented stuff is completely removed. The reason to watch for this is as follows: while destroying your own product (a Linux distribution) is bad business, there is enough outside interest in doing great damage to Linux that it WILL become rewarding to do so, to the extent that the patent becomes indispensable. If the patent becomes completely indispensable to Linux, the value of buying out or subverting the patent holder becomes astronomical to a competitor- some of whom claim to have rather a lot of money.
This holds for ANY patent being licensed into Free software, not just the SCC.
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.