Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

seL4 Verified Microkernel Now Open Source

Unknown Lamer posted about 3 months ago | from the formal-verification-for-the-rest-of-us dept.

Open Source 82

Back in 2009, OKLabs/NICTA announced the first formally verified microkernel, seL4 (a member of the L4 family). Alas, it was proprietary software. Today, that's no longer the case: seL4 has been released under the GPLv2 (only, no "or later versions clause" unfortunately). An anonymous reader writes OSnews is reporting that the formally verified sel4 microkernel is now open source: "General Dynamics C4 Systems and NICTA are pleased to announce the open sourcing of seL4, the world's first operating-system kernel with an end-to-end proof of implementation correctness and security enforcement. It is still the world's most highly assured OS." Source is over at Github. It supports ARM and x86 (including the popular Beaglebone ARM board). If you have an x86 with the VT-x and Extended Page Table extensions you can even run Linux atop seL4 (and the seL4 website is served by Linux on seL4).

Sorry! There are no comments related to the filter you selected.

Unfortunately? (2)

ichthus (72442) | about 3 months ago | (#47560865)

(only, no "or later versions clause" unfortunately)

You mean, fortunately. Now, it's more likely to actually be used.

Re:Unfortunately? (1)

Urkki (668283) | about 3 months ago | (#47560905)

(only, no "or later versions clause" unfortunately)

You mean, fortunately. Now, it's more likely to actually be used.

How does the "or later" clause hinder use? Licensing under GPLv3 might have (I'm not going to argue that either way), but what does the "or later" clause matter?

Re:Unfortunately? (0, Interesting)

Anonymous Coward | about 3 months ago | (#47560971)

Party A releases code under GPL 2 or later. They really want GPL 2, but or later implies future proofing.

Party B downloads code, releases it under GPL 3.

Party C finds Party B download and has less rights than if they found Party A.

Re:Unfortunately? (1)

mrchaotica (681592) | about 3 months ago | (#47561057)

Party D uses Party A's code, but locks it up a la TiVo.

Party E uses Party C's version instead of Party D's version because Party E gets more rights that way. (Party F, G, H, etc. ad infinitum keep more rights that way, too.... and that's the important part!)

Re:Unfortunately? (1)

Anonymous Coward | about 3 months ago | (#47561197)

Party D uses Party A's code, but locks it up a la TiVo.

Party A expressed their opinion about this scenario when they chose the license. GPL v2 Only means they don't want to prevent it.

You may disagree with Party A's choice, but your opinion doesn't matter. Party A wrote the code, and they get to decide.

Re:Unfortunately? (1)

vux984 (928602) | about 3 months ago | (#47561289)

Party A expressed their opinion about this scenario when they chose the license. GPL v2 Only means they don't want to prevent it.

Selecting GPLv2 or later ALSO allows for downstream Tivoization of your code. So choosing "GPLv2 only" OR "GPLv2 or later" makes no difference to Tivoization.

The only difference between "GPLv2 only" or "GPLv2 or later" is the or later can be mixed with GPLv3 or later, while GPLv2 only.

So the ONLY statement anyone picking "GPLv2 only" is making, is that they don't want their code mixed with GPLv3 which honestly... is pretty silly.

Re:Unfortunately? (1)

jcochran (309950) | about 3 months ago | (#47561407)

So the ONLY statement anyone picking "GPLv2 only" is making, is that they don't want their code mixed with GPLv3 which honestly... is pretty silly.

If "GPLv2 only" is silly, then you might want to alert all the Linux kernel developers. After all, the code in the Linux kernel is GPLv2, not GPLv2+.....

Re:Unfortunately? (2)

vux984 (928602) | about 3 months ago | (#47562321)

If "GPLv2 only" is silly, then you might want to alert all the Linux kernel developers.

Your kidding right? Alert them of what? Something they all already know?

As the kernel has no centralized copyright authority; the license is stuck where it is regardless of what anyone contributing to it wants or doesn't want.

Linus has been quoted saying he doesn't care for GPLv3 himself, and has no plans to change the kernel over; which is fine...(especialyl as its would be a fuckton of work -- due to each contributor to the kernel ever all having to either agree to the change or have their contribution pulled out and recoded from scratch). However it doesn't really answer the question of whether Linus actually objects to "GPLv2 or later" -- since it doesn't put any additional constraints on him; or anyone else contributing to the kernel -- the only upshot is that someone somewhere downstream might at some point create a gplv3+ distro based on the kernel. I'm really not sure Linus cares about that; if he doesn't care about Tivoization, what does he care if RMS and the FSF put together a pure gplv3 distro?

To me, at least, the choice of GPLv2 for the kernel instead of GPLv2 or later seems like, an oversight at best, that really can't be fixed now. After all, the kernel was one of the earlier works to use the GPL; it was still pretty new at the time. And Linus was not making a statement about Tivoization or GPLv3 or anything else when he didn't include the "or later" clause.

Re:Unfortunately? (1)

exomondo (1725132) | about 3 months ago | (#47562995)

I'm really not sure Linus cares about that; if he doesn't care about Tivoization, what does he care if RMS and the FSF put together a pure gplv3 distro?

He does care about that because the whole reason he chose the GPLv2 was because it was about "tit for tat", offering up the source in exchange for any modifications to be contributed back. If somebody created a GPLv3-licensed derivative then changes to that could not be contributed back to the GPLv2 kernel. What he cares about is the code, he doesn't care about Tivoization because that has nothing to do with the code and whether or not their changes can be incorporated into the mainline and distributed if desired.

Re:Unfortunately? (1)

vux984 (928602) | about 3 months ago | (#47563351)

Ok, that's a good point.

Re:Unfortunately? (1)

exomondo (1725132) | about 3 months ago | (#47561659)

Selecting GPLv2 or later ALSO allows for downstream Tivoization of your code.

So don't buy a TiVo then. "Tivoization of your code" is nonsense because Tivoization doesn't have anything to do with the code, in fact you can get the code here [tivo.com] licensed under GPLv2 and use it under those terms just as you would any GPLv2 project.

Re:Unfortunately? (1)

vux984 (928602) | about 3 months ago | (#47562471)

So don't buy a TiVo then. "Tivoization of your code" is nonsense because Tivoization doesn't have anything to do with the code, in fact you can get the code here licensed under GPLv2 and use it under those terms just as you would any GPLv2 project.

Read the preamble to the GPLv2 or the philosophy of the FSF. Tivoization is a legal end run around the philosophical purpose the license.

https://www.gnu.org/philosophy... [gnu.org]

"Specifically, free software means users have the four essential freedoms: (0) to run the program, (1) to study and change the program in source code form, (2) to redistribute exact copies, and (3) to distribute modified versions."

Tivoization of GPL code preserves those 4 rights, but withholds the implicit desire of GPL users to be able to exercise those rights on the hardware the software is running on.

Tivoization is a manifestation of "what good is your right to a phone call, if we take away your ability to speak".

When the GPL2 was written no one had conceived that you might receive GPL code installed on a device, be allowed to run it, be allowed to change it, be allowed to redistribute it... but NOT be allowed to run the changed software on the original device.

It was a loophole that was implicitly intended by the GPLv2, but not made explicit. The GPLv3 attempts to close the loophole.

And as an aside, the AGPL3 is mean to meant to close another loophole that wasn't originally conceived of... developers would use GPL code, and distribute only access to the code running remotely rather than copies of the code itself, thereby exempting them from the need to share the source.

Re:Unfortunately? (1)

exomondo (1725132) | about 3 months ago | (#47562773)

Read the preamble to the GPLv2 or the philosophy of the FSF. Tivoization is a legal end run around the philosophical purpose the license.

I have read it, I also understand it. It is nothing to do with the code. If you use the code Tivo provides but you don't own a Tivo then Tivoization has no impact on you because it is nothing to do with the code whatsoever.

Tivoization is a manifestation of "what good is your right to a phone call, if we take away your ability to speak".

Wrong, I don't need a Tivo to use their code.

It was a loophole that was implicitly intended by the GPLv2, but not made explicit. The GPLv3 attempts to close the loophole.

A loophole that clearly many authors wanted and have accepted as "by design". If the GPLv2 license didn't provide then some other license would and authors would be using that instead. Not everybody who uses the GPLv2 (or any FSF license) subscribes to the FSF ideology, in fact some of the most prominent ones (Linux for example) explicitly do not.

Re:Unfortunately? (1)

vux984 (928602) | about 3 months ago | (#47563311)

Wrong, I don't need a Tivo to use their code.

That is beside the point. This isn't about *you*.

This is about the 99.99% of people who use Tivo code, use it on a Tivo, and as a result they are denied the particular freedoms the original authors of the code it is licensed under intended for them to have.

Granted 98% of them don't care about the license or about changing the code. But the authors of the original code AND the license cared a great deal about it.

A loophole that clearly many authors wanted and have accepted as "by design".

Absolutlely not an outcome the authors of the license wanted. And I'm skeptical you can find any developers who expressly WANTED the GPL for tivoization... i mean if you want that, then use the BSD or something. There are lots of perfectly suitable licenses for that use.

What realistic scenario can you put forth where the developer actively wants to license their code under the GPL and simultaneously doesn't want people to be able to modify the code they received to run on on the equipment the code is installed on?

Seriously. Find one.

And no, Tivo itself doesn't count, they didn't author original code and actively select the GPL... they merely took the GPL code that was out there because it was out there and used it, and ran a legal end run around the authors intentions.

Not everybody who uses the GPLv2 (or any FSF license) subscribes to the FSF ideology,

There does have to be a fairly substantial overlap with FSF ideology though, otherwise you'd pick something else, like BSD.

in fact some of the most prominent ones (Linux for example) explicitly do not.

By "Linux" I assume you mean Linus? And while its clear he disagrees with the FSF on some key points, you'd be hard pressed to demonstrate that he actively approves of Tivoization. At best I'd say he doesn't like the GPLv3's method of trying to prevent it. But I could be mistaken. I'm not Linus.

Re:Unfortunately? (1)

exomondo (1725132) | about 3 months ago | (#47563387)

This is about the 99.99% of people who use Tivo code, use it on a Tivo, and as a result they are denied the particular freedoms the original authors of the code it is licensed under intended for them to have.

Wrong, you simply do not understand the license and are implying things that are not there. It has been made very clear multiple times, here [lkml.org] is just one example, that the use of the GPLv2 is purely about code openness and code contribution but not about FSF ideals.

If you believe otherwise then demonstrate where the original Linux kernel author actively intended the recipients of the code to have the freedoms that are not granted by the GPLv2, but you won't because Linus never intended that, it's yet another false inference you are making.

Absolutlely not an outcome the authors of the license wanted.

The authors of code that use it.

i mean if you want that, then use the BSD or something.

So not only do you not understand the GPL license but you also don't understand the BSD license. The BSD license does not require code contributions back, it does not require you to release your modifications like the GPL does. That is why the GPL was chosen over the BSD for the Linux kernel.

What realistic scenario can you put forth where the developer actively wants to license their code under the GPL and simultaneously doesn't want people to be able to modify the code they received to run on on the equipment the code is installed on?

The Linux kernel! Explicitly does not care about FSF freedom ideals and only cares about the code, that's why they use the GPLv2 and why the GPLv3 is incompatible with the ideals of the kernel developers.

By "Linux" I assume you mean Linus? And while its clear he disagrees with the FSF on some key points, you'd be hard pressed to demonstrate that he actively approves of Tivoization.

Tivoization is fine according to Linus because it is about source code and not anything else:
I personally have always been very clear about this: Linux is "Open Source". It was never a FSF project, and it was always about giving source code back and keeping it open, not about anything else.

Re:Unfortunately? (2)

vux984 (928602) | about 3 months ago | (#47563543)

GPLv2 is purely about code openness and code contribution but not about FSF ideals.

Not according to the people who actually WROTE the GPLv2. You made a good point about *some* of the people who chose to use it, but that is not what the GPLv2 was written FOR.

Re:Unfortunately? (1)

exomondo (1725132) | about 3 months ago | (#47563585)

GPLv2 is purely about code openness and code contribution but not about FSF ideals.

Not according to the people who actually WROTE the GPLv2. You made a good point about *some* of the people who chose to use it, but that is not what the GPLv2 was written FOR.

No I said that in this context the use of the GPLv2 is purely about code openness and code contribution but not about FSF ideals, obviously by "this context" I mean Tivo and who used Linux and thus the one using the GPLv2 is Linus. What the authors of the GPL intended is irrelevant, the only thing that matters is what they actually wrote.

Moreover on your request for specific examples of Linus endorsing Tivoization [lkml.org] :
"I think Tivoization is *good*."
"What Tivo did is *good* in my opinion!"

It doesn't get much more unequivocal than that, he does actively approve of Tivoization.

Re:Unfortunately? (1)

vux984 (928602) | about 3 months ago | (#47564275)

What the authors of the GPL intended is irrelevant, the only thing that matters is what they actually wrote.

Spoken like a true sociopath.

As for Linus' endorsement of tivoization; I've read the thread -- he's satisfied that Tivo followed the rules and contributed the code back. Yes, he writes that "tivoization is good" but that seems strictly within the context of that particular argument about tit-for-tat code especially with someone who was clearly arguing the FSF case, which Linus has repeatedly rebuffed.

In any case I remain unconvinced that Linus considered the Tivoization scenario when he selected the license, or that he really consciously desired specifically to enable it.

My read on it that his take on it is ragmatic, that it's happened, that it hasn't been "bad for the linux kernel", and that gplv3 is a worse "solution".

Re:Unfortunately? (1)

exomondo (1725132) | about 3 months ago | (#47570843)

What the authors of the GPL intended is irrelevant, the only thing that matters is what they actually wrote.

Spoken like a true sociopath.

So now you're just resorting to ad hominem attacks because you don't like the facts. We know for a fact that what they intended doesn't matter because they didn't write that and if they did write that the license would have gone beyond simple "tit for tat" and would not have been chosen for the Linux kernel.

As for Linus' endorsement of tivoization; I've read the thread -- he's satisfied that Tivo followed the rules and contributed the code back.

Because as he has made clear many many times that's all that matters, what the authors of the GPLv2 think about that or what you think they intended the license for has no relevance whatsoever.

In any case I remain unconvinced that Linus considered the Tivoization scenario when he selected the license, or that he really consciously desired specifically to enable it.

So? Clearly the authors of the GPLv2 didn't consider it either or they didn't care about Tivoization at all. The license did explicitly what Linus wanted and nothing more, if the license explicitly placed restrictions on the use of the code outside of contributing it back then the GPLv2 would not have been used because Linus has made clear many times that it is about "tit for tat" and nothing more.

So what I'm trying to understand now is what your point is? We know "tivoization of code" is a misnomer and makes no sense because tivoization has nothing to do with the code, we know that Linus approves of Tivoization and we know that any project that doesn't can switch to GPLv3 to prevent it. So what is your point?

Re:Unfortunately? (1)

vux984 (928602) | about 3 months ago | (#47571541)

I'm just pointing out that you are acting like a sociopath. A license (contract) is supposed to be a "meeting of minds"; perverting the intention of the contract terms is a sociopathic thing to do. Not ad hominem -- merely an observation.

Because as he has made clear many many times that's all that matters, what the authors of the GPLv2 think about that or what you think they intended the license for has no relevance whatsoever.

To whom?

So? Clearly the authors of the GPLv2 didn't consider it either or they didn't care about Tivoization at all.

Clearly. If they didn't care theyd' never have released a GPLv3 specifically to close that loop hole in what they wrote vis-a-vis their intent. Oh wait... they did release a GPLv3. Guess they cared.

if the license explicitly placed restrictions on the use of the code outside of contributing it back then the GPLv2 would not have been used because Linus has made clear many times that it is about "tit for tat" and nothing more.

Its impossible to say what Linus would have done at 22 years old in 1992 if the GPL had been slightly differently worded. Whether he'd have cared about an anti-tivoization clause at the time... you'll maybe recall that Linux 0.01 through 0.11 was released under a license that forbade commercial use in 1991.

He switched to the GPL in 1992. Your indulging in some serious mythologizing to even suggest he had such an extremely nuanced understanding and appreciation for a license that had only been around for a couple years. (GPL v1 was released in 89), and GPLv2 was barely 6 months old when Linus adopted it.

You are saying the same person that you argue thought tivoization was a good thing when he selected GPL was against any commercial use at all just a few months earlier? That doesn't add up. Unless maybe, just maybe Linus' stance on the license has evolved and become a lot more nuanced over the last 20+ years.

So what is your point?

1) That Linus in 2007 isn't really the same kid that picked GPLv2 for his experimental kernel project in 1992.

2) That Linus in 1992 wasn't really making pro-tivoization arguments in 1992 when he selected that license.

Re:Unfortunately? (1)

exomondo (1725132) | about 3 months ago | (#47571797)

I'm just pointing out that you are acting like a sociopath.

Which is false, by definition.

A license (contract) is supposed to be a "meeting of minds"; perverting the intention of the contract terms is a sociopathic thing to do.

Again, false. Prove to me how tivoization is a perversion of the contract terms. The "meeting of minds" in this case is the author of Linux and the user of Linux, that fact that you think the author of the GPL has anything to do with it demonstrates you have no idea about contracts whatsoever, so don't pretend to be able to discuss them.

To whom?

To whom what? Linus has made it clear to anybody who has bothered to ask or read his posts.

Clearly. If they didn't care theyd' never have released a GPLv3 specifically to close that loop hole in what they wrote vis-a-vis their intent. Oh wait... they did release a GPLv3. Guess they cared.

And that's why it's the GPLv3 and not v2, and you're free to use v3 if you want in your software, v2 is used for the kernel whether you like it or not.

Its impossible to say what Linus would have done at 22 years old in 1992 if the GPL had been slightly differently worded.

If it were v3 it would not have been "tit for tat" and by definition would not have fit Linus' principles.

You are saying the same person that you argue thought tivoization was a good thing when he selected GPL was against any commercial use at all just a few months earlier? That doesn't add up.

Now you've gone full retard, he made the change because he wanted to change, if he didn't want commercial use then he wouldn't have selected the GPLv2.

1) That Linus in 2007 isn't really the same kid that picked GPLv2 for his experimental kernel project in 1992.

Which is obvious and irrelevant, it makes no difference to anything whatsoever.

2) That Linus in 1992 wasn't really making pro-tivoization arguments in 1992 when he selected that license.

Tivo didn't even exist then so you're just stating the obvious.

Ultimately you have no point, don't understand the GPL, don't understand what a contract is and instead of getting educated you decide to call me a sociopath as an excuse for your own mental limitations.

The GPLv2 exists to protect the 4 freedoms, that is its goal, if you think it is supposed to do more then you just fail to understand it.

Re:Unfortunately? (0)

Anonymous Coward | about 3 months ago | (#47572249)

Now you've gone full retard

Pot meet kettle.

Re:Unfortunately? (0)

Anonymous Coward | about 3 months ago | (#47573081)

Clearly the authors of the GPLv2 didn't consider it either or they didn't care about Tivoization at all.

The loop hole at not been found at the time the GPLv2 was written. If it is a loop hole at all, the Tivo case never went to court, and the loop hole depends on the interpretation of the section that requires anything needed to build the binary. The FSF decided to close the loop hole just to be sure, the version with the hole closed is called GPLv3.

Re:Unfortunately? (2)

DamnOregonian (963763) | about 3 months ago | (#47563427)

I have licensed GPL code (some of it Linux kernel code). I specifically didn't care about the idea of tivoization, and was even running a tivoized device that I developed it for (cell phone).

I have a distaste for the practice, to be sure, but for me the selection of GPL licensing even where I'm not really required to is more about just making sure that improvements or ports of the code make it back. Companies that tivoize are shit-bags. They're also more likely to give something back, though, and that's better than nothing. I'd prefer not to limit their rights for how they use my code. That's more about morality, and they can deal with the consequences of their immorality without me enforcing it upon them. My improved comes back, that's good enough for me.

Re:Unfortunately? (0)

Anonymous Coward | about 3 months ago | (#47563109)

Tivoization of GPL code preserves those 4 rights, but withholds the implicit desire of GPL users to be able to exercise those rights on the hardware the software is running on.

rubbish! that is just your misguided perception of what "gpl users" want. if you were familiar with linus torvalds' take on the subject you would realize that your own personal "implicit desire" is not shared amongst others. it was not used in the linux kernel for the "spirit" or the fsf ideals or whatever you think is implied by the license. it was used for purpose of the license as written, nothing more. if you inferred something that was not actually written then that is your failure, the fact that linus has clarified this in relation to the gplv3 and tivo-ization only increases the magnitude of your failure.

Re:Unfortunately? (1)

LWATCDR (28044) | about 3 months ago | (#47564879)

Which is exactly why this does not use V3.
To be secure you really need to have the option to lock down the hardware and only allow updating with signed modules. It is actually part of the FIPS regulations.

whats the difference? (0)

Anonymous Coward | about 3 months ago | (#47561685)

whats the difference between tivoized code and non-tivoized code? i read the page on tivoization [wikipedia.org] and it doesnt seem to make any difference in terms of the code.

Re:whats the difference? (1)

vux984 (928602) | about 3 months ago | (#47564037)

whats the difference between tivoized code and non-tivoized code

Primarily, that the (majority) of users of said code are unable to effectively exercise the rights the GPL was intended to confer upon them.

Specifically, the right to change the code. That they can copy the code to some other deivces, change it, and run it there, but not be allowed to on the original device was not the intent of the GPL, or its author.

Re:whats the difference? (0)

Anonymous Coward | about 2 months ago | (#47577637)

Primarily, that the (majority) of users of said code are unable to effectively exercise the rights the GPL was intended to confer upon them.

If you're being truthful, that's because they don't own a Tivo, don't know how to program, or really don't care as long as their Tivo records the programs they want it to record.

A vanishingly small percentage fit outside that venn diagram. (But you do appear to be a very vocal bunch)

Re:Unfortunately? (1)

Immerman (2627577) | about 3 months ago | (#47562521)

Not at all - by including an "or later" clause you also open your code to being re-licensed under GPLv666: aka the "Stallman is dead and Microsoft now has unrestricted rights to all your code" edition.

Re:Unfortunately? (1)

vux984 (928602) | about 3 months ago | (#47563269)

Not at all - by including an "or later" clause you also open your code to being re-licensed under GPLv666

Maybe. It'll still be available under GPLv2 though.

Re:Unfortunately? (1)

Immerman (2627577) | about 3 months ago | (#47566115)

That is true - but not everyone want to give their code away to whoever happens to hijack the license.

Re:Unfortunately? (0)

Anonymous Coward | about 3 months ago | (#47591361)

So the ONLY statement anyone picking "GPLv2 only" is making, is that they don't want their code mixed with GPLv3 which honestly... is pretty silly.

Wrong.

Scenario 1

Party A writes some code, and releases it under GPL v2 or Later.
Party B modifies the code, and releases their changes under GPL v3.
Party A can't use Party B's changes unless they're willing to convert the entire project to GPL v3.
IMHO, Party A gets screwed in this scenario.

Scenario 2

Party A writes some code, and releases it under GPL v2 Only.
Party B modifies the code, and must release their changes under GPL v2.
Party A can freely use Party B's changes.

Re:Unfortunately? (0)

Anonymous Coward | about 3 months ago | (#47561311)

You may disagree with Party A's choice, but your opinion doesn't matter.

TFS expressed this opinion. It matters to some of us.

Re:Unfortunately? (1)

exomondo (1725132) | about 3 months ago | (#47561635)

Party D uses Party A's code, but locks it up a la TiVo.

False, the code is not "locked up", in fact TiVo's modified code is available right here [tivo.com] . If what you mean is that you cannot replace the code running on a TiVo device with your own modified code then say that, because what you said is completely untrue.

Re:Unfortunately? (0)

Anonymous Coward | about 3 months ago | (#47560997)

More like that now the company can probably release it. I have tried to opensource some things, the company legal dept was fine with BSD/GPLv2/GPLv3, but no 'or later' or something like that since that gives FSF a blank check to relicense the work.

Re:Unfortunately? (2, Insightful)

tlhIngan (30335) | about 3 months ago | (#47561207)

How does the "or later" clause hinder use? Licensing under GPLv3 might have (I'm not going to argue that either way), but what does the "or later" clause matter?

Because you cannot mix v2-only code with v3/v3+ code. It's actually incompatible - v3 puts additional "restrictions" (from v2's perspective) on the code, making it incompatible (e.g., anti-TiVoization, etc).

So this means all code in that kernel must be either v2 or v2+ (which means the "+" disappears).

For an embedded systems, they typically want GPLv2 or v2+, avoiding v3 as much as possible. "or later" can hinder since if you're not careful, you might accidentally include v3 code (especially if you pull from an upstream source) when you don't want to. v2-only makes that a license violation, while v2+ turns into v3/v3+. One should be careful when pulling patches to make sure the codebase doesn't unexpectedly turn into v3.

Re:Unfortunately? (1)

mx+b (2078162) | about 3 months ago | (#47561249)

But the clause in the statement of the GPLv2/3 is "or (at your option), any later version". There is nothing forcing someone to use v3 if it is released as v2+ -- you pick 2 or 3 based on your project since it is your option. I believe this is what GP was asking -- since you can choose forever, everyone can pick, how does it hurt anything to have "v2 or later at your option"?

Re:Unfortunately? (0)

Anonymous Coward | about 3 months ago | (#47561369)

Because the anti-FSF people who always start these license flamewars think GPLv3 is worse than proprietary software.

Re:Unfortunately? (0)

Anonymous Coward | about 3 months ago | (#47624885)

This flamewar was started by the original post saying "(only, no "or later versions clause" unfortunately)"

You can't choose forever. Once v3 touches it, gone (0)

raymorris (2726007) | about 3 months ago | (#47561373)

> since you can choose forever, everyone can pick
You cant choose forever. As soon as someone touches it with v3, it's v3 and you can't get it back.
The most common and easiest case where that happens if that someone integrates some other GPL code into the GPL project.
The contributor didn't realize that GPL(2) and GPL(3) are two very different things. The code integrated / copy-pasted from elsewhere was GPL3. If not caught and removed immediately, the presence of ANY GPL3 code, just one line, requires that the entire project be released _only_ as GPL3. It can no longer be used under GPL2.

The reason for that is that the new contribution that is GPL3 licensed wasn't licensed under GPL2. Since that bit isn't licensed under 2, the whole package can't be distributed under 2.

The wording in GPL3 is unclear in such a way that it could pose a very significant risk to people who aren't even remotely involved in open source at all. Whether that wording is merely stupid or devious, who knows. The problem was pointed out before the license was approved, and the wording wasn't changed, so perhaps Stallman actually did intend to leave the threat there, while claiming the threat didn't exist.

Re:You can't choose forever. Once v3 touches it, g (2, Informative)

Immerman (2627577) | about 3 months ago | (#47562563)

Yes, it does mean that any code including v3 code can only be legally licensed as v3 - but there's nothing stopping you from later extracting the offending code and reverting to v2+. You don't magically change the 2+ license under which you gained rights to the other code, you just only have the option of redistributing it under v3 so long as any v3-only code is included. So long as you make sure all contributions made in the interim are made under v2+ you don't have a problem (i.e. v3-only licensing can only spread if you let it).

contributions on top, etc scare me. Once you know (1)

raymorris (2726007) | about 3 months ago | (#47562807)

True, theoretically once you know about it, you should be untangle any GPL3 code and any contributions on top of that GPL3, and any other code that borrowed from the GPL3 code. As an example of what I'm thinking of, suppose you have something modular like WordPress or Apache. Someone contributes an authentication module that includes gpl3 code. Because it includes GPL3 code, the whole module is gpl3. Someone else writes a different type of authentication module and rather than writing boring parts from scratch, they start by making a copy of the existing authentication module and replacing the "guts", the actual authentication function, with some other type. That second authentication module would be a derivative work of the first, and therefore gpl3. The project maintainers have no way of knowing how the author went about writing it, though, so they don't know if it's gpl3 or not.

My primary 8-5 job is maintaining and enhancing a gpl3 project called Moodle. I appreciate what the licence APPEARS to say, but I'm always nervous about what it DOES say. I'm careful to only contribute or distribute under my personal name, never hosting a copy of the source on my employer's servers. When I get an email at work asking for a copy of a module I wrote, or some help with something, I reply from my personal email address in order to protect my employers IP by avoiding any indication that the organization is distributing. Even with that, I also have to watch the entire project for anything that might infringe on my personally held UP because if someone puts infringing code on the project github I'll arguably lose my rights.

Re:Unfortunately? (1)

DeVilla (4563) | about 3 months ago | (#47563007)

... how does it hurt anything to have "v2 or later at your option"?

Because, if you "accidentally include v3 code" you'll only be violating one license instead of two. ....wait??!?

Re:Unfortunately? (0)

Anonymous Coward | about 3 months ago | (#47561863)

The "or later" hinders use because the legal team at a perspective company will only agree to a license that doesn't change.

"Or later" isn't a clearly defined set of terms: it gives the FSF the ability to re-license your code at any time. Lawyers don't like the opportunity for anyone external to say "I am altering the deal. Pray I don't alter it any further."

It also lets manufacturers produce devices which will work with only the blessed kernel; there are valid reasons for this:
- Lowers support burden. When it costs x dollars times y users who have problems, and ask for support with their product. A percentage of requests will be from users who conceal the fact they are running a hacked kernel. Companies generally don't like to spend money fixing somebody else's problem.
- It's a valid security practice to only execute cryptographically signed binaries (and only specific credentials at that). This includes kernels.

The FSF calls it "Tivoization"; others call it "protecting the security of our customers with delusions of competence."

Re:Unfortunately? (1)

Anonymous Coward | about 3 months ago | (#47563055)

Because the GPL has a certain non-free philosophy attached to it that a BSD license doesn't impose.

If you release under GPLv2, you have to share the code and your modifications (which is fine by me in most cases) but you can't hide your changes, nor are you obligated to license everyone who uses your code/changes to your patents, which is why the GPL3 is evil and not free.

Everyone should, when they decide on a license
a) consider the ramifications of the license family (most software that is utilitarian in nature and breaks if changed, eg libpng/zlib should be using a zlib or bsd style license that stipulates you can take the source, but you can't release anything misrepresenting. eg I can't take zlib, compile it, and call it "myzlib, pay me 20$ to use", now if I make changes to it that alter the functionality, I can't call it zlib, nor can I redistribute the source code under a new license, stripping all the previous license data out.)
  WHICH BY THE WAY, GPL-FREEDOMITES TEND TO DO... "hey look this file doesn't have a license, let's GPL it"
b) consider the political statement that is made by picking that license. 90% of the time, you don't want the GPL unless you philosophically agree with it. The remaining 10% of the time you want the GPL because you know other people are going to rip off the project, and if they're going to rip it off, they better share what they do with it.

In the case of things like the iPhone development where the GPL basically prevents you from using the software entirely, yes, you are totally shooting yourself in the foot by picking the GPL.

In most cases, people don't care what the license is, and aren't going to use it as a battering ram against someone unless that person has their hand too deep into the cookie jar. Case in point libvorbis is better off as a BSD license because it would encourage adoption, while FFMPEG is better off as GPL/LGPL to prevent people from ripping off the code and putting it in their own projects. There are several hundred software units out there that do "convert to flash" or "convert to h264" and most of them just straight compile ffmpeg and pipe it using a bridge library so they never have to show the source code of their software.

The point of a software license is to explicitly control what users do with it, and if that license is too tightly enforced, you hinder adoption, hence how Oracle has pretty much destroyed any chance in hell of Java being useful since JDK1.4, and that started with Microsoft. Anyone who adopts Java, has no gaurantee their software will work in the next version, hence why I said it's a poor choice now. Microsoft on the other hand embraced the Mono project and thus we have a useable language that can be compiled to native code on all platforms.

Where you probably want to avoid the GPL is with drivers. Yes it might be useful to be GPL, if the hardware is dead/dying, but a lot of vendors need to keep their cards close to their chests, otherwise they will leak hardware specifics that competitors can use.

Re:Unfortunately? (1)

silanea (1241518) | about 3 months ago | (#47565829)

[...] WHICH BY THE WAY, GPL-FREEDOMITES TEND TO DO... "hey look this file doesn't have a license, let's GPL it" [...]

If a file does not have a license the "freedomites" fall back to default copyright, which in most cases translates to "DO NOT TOUCH!". Could you kindly point out examples where people who advocate usage of the GPL have deliberately taken third-party code with no license attached and released it under the terms of the GPL? Usually it is the other way around: People take GPL'd code and re-release it in closed source software.

Re:Unfortunately? (1)

HornWumpus (783565) | about 3 months ago | (#47567849)

They do it to BSD code all the time. They often follow up by finding a copy somewhere in the wild and jumping up and down yelling 'Evil! Evil!' until someone points out that the code is actually BSD code that was included in a GPL project.

Re:Unfortunately? (1)

silanea (1241518) | about 3 months ago | (#47572633)

To quote myself:

[...] Could you kindly point out examples [...]

So far I have seen only vague accusations.

Re:Unfortunately? (0)

Anonymous Coward | about 3 months ago | (#47573093)

First of all, BSD code is not code with no copyright.

Second, the ability to relicense the code is the advantage of the BSD license that BSD license proponents keep arguing for. If you don't want people to do that, you shouldn't pick a license that explicitly allows it. Pick one that requires derivative works to be under the original license, such as the GPL.

Re:Unfortunately? (0)

Anonymous Coward | about 2 months ago | (#47577711)

No, that's the point.

You can't relicense BSD. Period.

You follow it or you don't use it. Just like GPL.

Re:Unfortunately? (0)

Anonymous Coward | about 2 months ago | (#47577787)

Oh, and slapping a GPL license above a BSD is technically dodgy at least.

The BSD license basically says "This information must be provided" with a copyright. That means commercial companies following the license must either have the license shown on a screen or printed in a manual, for example.

The GPL license says you cannot further restrict the code. (GPL 2.0, clause 6 "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." GPL 3.0, clause 10 "You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License.")

Except BSDs generally have the line "Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution." (Specifically, this is clause 2 in NetBSD's license)

That is, a further restriction on what GPL forces you to do.

Re:Unfortunately? (-1, Redundant)

marcello_dl (667940) | about 3 months ago | (#47560979)

Man, what a pathetic troll style. Go to usenet and learn.

Eat Shit! Learning from Wikipedia! (-1)

Anonymous Coward | about 3 months ago | (#47561121)

In humans, defecation may occur (depending on the individual and the circumstances) from once every two or three days to several times a day. Extensive hardening of the feces may cause prolonged interruption in the routine and is called constipation.

Human fecal matter varies significantly in appearance, depending on diet and health. Normally it is semisolid, with a mucus coating. Its brown coloration comes from a combination of bile and bilirubin, which comes from dead red blood cells.

In newborn babies, fecal matter is initially yellow/green after the meconium. This coloration comes from the presence of bile alone. In time, as the body starts expelling bilirubin from dead red blood cells, it acquires its familiar brown appearance, unless the baby is breast feeding, in which case it remains soft, pale yellowish, and not completely malodorous until the baby begins to eat significant amounts of other food.

Throughout the life of an ordinary human, one may experience many types of feces. A "green" stool is from rapid transit of feces through the intestines (or the consumption of certain blue or green food dyes in quantity), and "clay-like" appearance to the feces is the result of a lack of bilirubin.

Bile overload is very rare, and not a health threat. Problems as simple as serious diarrhea can cause blood in one's stool. Black stools caused by blood usually indicate a problem in the intestines (the black is digested blood), whereas red streaks of blood in stool are usually caused by bleeding in the rectum or anus.

Food may sometimes make an appearance in the feces. Common undigested foods found in human feces are seeds, nuts, corn and beans, mainly because of their high dietary fiber content. Beets may turn feces different hues of red. Artificial food coloring in some processed foods such as highly colorful packaged breakfast cereals can also cause unusual feces coloring if eaten in sufficient quantities.

Clinical laboratory examination of feces, usually termed as stool examination or stool test, is done for the sake of diagnosis, for example, to detect presence of parasites such as pinworms and/or their eggs (ova) or to detect disease spreading bacteria. A stool culture — the controlled growth of microbial organisms in culture media under laboratory conditions — is sometimes performed to identify specific pathogens in stool. The stool guaiac test (or guaiac fecal occult blood test) is done to detect the presence of blood in stool that is not apparent to the unaided eye. Fecal bacteriotherapy — also known as a fecal transplant — is a medical procedure wherein fecal bacteria are transplanted from a healthy individual into a patient.

Human feces collected for a specific practical use, such as for fertilizer, is known as night soil.

The distinctive odor of feces is due to bacterial action. Gut flora produce compounds such as indole, skatole, and thiols (sulfur-containing compounds), as well as the inorganic gas hydrogen sulfide. These are the same compounds that are responsible for the odor of flatulence. Consumption of foods with spices may result in the spices being undigested and adding to the odor of feces. The perceived bad odor of feces has been hypothesized to be a deterrent for humans, as consuming or touching it may result in sickness or infection. Human perception of the odor may be contrasted by a non-human animal's perception of it; for example, an animal that eats feces may be attracted to its odor.

Feces elicits varying degrees of disgust — one of the basic human emotions — in all human cultures. Disgust is experienced primarily in relation to the sense of taste (either perceived or imagined), and secondarily to anything which causes a similar feeling by sense of smell, touch, or vision. As such, human feces is regarded as something to be avoided diligently: expelled in private and disposed of immediately and without trace. It is often considered an unacceptable topic in polite conversation and its mere mention may cause offence in certain contexts. An example from the ancient world of the repulsion people have felt toward feces is found in Deuteronomy 23:12-14.

12Designate a place outside the camp where you can go to relieve yourself. 13 As part of your equipment have something to dig with, and when you relieve yourself, dig a hole and cover up your excrement. 14 For the LORD your God moves about in your camp to protect you and to deliver your enemies to you. Your camp must be holy, so that he will not see among you anything indecent and turn away from you.

The disposal of feces has always been associated with the lowest people among a society, the social outcasts, the pariahs, and the social discards. The Caste system in India was created along the lines of profession and the dalits (untouchables) were left to do work related to human emissions. They did such work as cleaning and picking feces from streets, cleaning toilets, and working with dead bodies. Such practices are prevalent even today in the rural and small villages of India.

Re:Unfortunately? (2)

ichthus (72442) | about 3 months ago | (#47562949)

I made a statement about GPLv2 being more conducive than its successors to project adoption, and you obviously disagree with this statement. Because of this -- because your opinion differs, I'm trolling? You need to go to wikipedia and learn [wikipedia.org] .

Re:Unfortunately? (0)

Anonymous Coward | about 3 months ago | (#47563807)

Hah. Tell me now *who* the zealots are.

More info (4, Informative)

Enry (630) | about 3 months ago | (#47560969)

http://sel4.systems/FAQ/ [sel4.systems]

Is it really that hard to give more background information?

Re:More info (1)

lemur3 (997863) | about 3 months ago | (#47563075)

fuck whoever decided that having a .systems TLD was a good idea.

it just aint right i tells ya.

Re:More info (1)

jones_supa (887896) | about 3 months ago | (#47563803)

Handing out TLDs is no more about being proper but giving tools for various fancy names and word plays. Remember to register your .fish domain today.

BSD 2 Clause as well (1)

Anonymous Coward | about 3 months ago | (#47560991)

What's being released?

It includes all of the kernel's source code, all the proofs, plus other code and proofs useful for building highly trustworthy systems. All is under standard open-source licensing terms — either GPL version 2, or the 2-clause BSD licence.

Directly from the website. Not bothered enough to see what bits are BSD 2 Clause though.

JCS and NSA wont like this (0)

Anonymous Coward | about 3 months ago | (#47561127)

Wait for them to f**k with it until they can reconnoiter anything on L4 systems. My money is on a bunch of wholly useless features which will be added in the next few months.

Re:JCS and NSA wont like this (0)

Anonymous Coward | about 3 months ago | (#47561633)

But those features would be proven to report to the NSA!

Waste Of Time (-1)

Anonymous Coward | about 3 months ago | (#47561295)

"World's First Formally-Proven OS Kernel" running on completely unverified hardware.

Close to useless.

Waste Of Time (0)

Anonymous Coward | about 3 months ago | (#47569523)

What a SCHEISS-Kommentar. They have done 50% of work and you bitch they did not 100% of the work. Like "they only brought me a wife, now I have to spend lots of effort to inseminate, boohooo".

Don't tell HURD (1)

Carnildo (712617) | about 3 months ago | (#47561375)

Don't tell the HURD people -- they'll change which microkernel they're building around, again.

Re:Don't tell HURD (1)

ChunderDownunder (709234) | about 3 months ago | (#47562603)

I think they already tried and failed to port to L4, giving up because HURD was too mach-specific.

Re:Don't tell HURD (-1, Flamebait)

slashdot_commentator (444053) | about 3 months ago | (#47563633)

seL4 is probably a subset of MACH. It wouldn't be an insurmountable problem to port HURD to run on top of seL4. What might be exceptionally difficult would be to rewrite HURD to take advantage of seL4's design, to produce a more "correct" version of a microkernel based OS.

IIRC, the HURD effort to replace MACH with L4 had nothing to do with difficulty salvaging HURD code to run on top of L4. It had to do with known security flaws with inter process communications in MACH and the original L4 implementation. There was a grad student looking to replace MACH with a prototype secure variant of L4 called coyotos, which was eventually abandoned.

Fuck HURD. HURD was a failure. HURD was a vanity project Richard Stallman wanted implemented to undercut the popularity of the fledgling linux OS. He abandoned his cheerleading effort for it over a decade ago. (I doubt Stallman even contributed code to the original HURD implementation.) Since then, its been whored out to every grad student looking to use it as a platform for their thesis. The whole academic drive towards microkernel OS is obsolete research, like using PROLOG to implement AI systems. Microkernels have been supplanted by hypervisors and secure ipc implementations. Really, if HURD worked, what would it be doing that would make it uniquely valuable when compared to all current operating systems?

Personally, I wish I could avert my eyes from this collision between two behemoth machines trapped in an event horizon.

I like this idea, but (1)

Beck_Neard (3612467) | about 3 months ago | (#47561473)

Who else thinks that it's only a matter of time before the first vulnerability is found?

Knuth said it best (2, Informative)

Anonymous Coward | about 3 months ago | (#47561723)

It may have been proven correct, but lets wait and see until after it's actually been used if it really is.

(Knuth said (paraphrased): be aware of bugs in the above code. I have only proved it to be correct; I have not tried it.)

Re:Knuth said it best (2)

Beck_Neard (3612467) | about 3 months ago | (#47562393)

Well, 'proven correct' assumes that the proof itself is correct (verification), that the proof actually proves the correct thing (validation), and that the underlying system actually conforms to its formal specification (another thing that's hard to verify - formally-verified CPU design anyone?). These people seem to have done their homework so I'll be looking at this more closely, but based on experience it's pretty much guaranteed that there's going to be some unconsidered vulnerability somewhere.

A good step forward... (3, Interesting)

ndykman (659315) | about 3 months ago | (#47562117)

I feel an explaination may help. This project is based on a formal specification (in Isabelle/HOL) about what should be true about the microkernel. This specification rules out things like buffer overflows, null pointer dereferences and other properties by recasting these ideas in terms of higher order logic and uses automatic theorem proving tools to verify the proofs and that implementations match the specification.

There's even a binary verified version for ARM, so you don't even have to trust that your compiler works (but, there is progress in verified compilers, so hopefully an x86_64 version is on the way). The value in this is in using the tool chain and creating new, formally specified abstractions and implementing them in an verified manner to implement more secure, robust programs on top of this kernel. Of course, the microkernel makes assumptions about the hardware, boot loader, but formal verification is used more often in hardware, and you have to trust something at some point.

This opens a whole set of possibilities to the community as a whole. As a random example, you could formalize the Arduino language (or a kernel for that language) and create a verified version of that system that runs on this microkernel. This would be a big effort, but you could do it.

Overall, this is a positive step in lower the costs of verified co-designed systems and I hope it attracts more interest in software formal verification.

Proof (2)

manu0601 (2221348) | about 3 months ago | (#47562629)

While proved software is much better than unproved software, this is not the end of security holes: The proof assumes hardware and compiler behave as specified, which lets a lot of attack surface.

At least it raises the bar much higher.

Re:Proof (2)

flux (5274) | about 3 months ago | (#47563723)

While there have been some Linux bugs due to the compiler, I can't really recall hardware problems that have caused security problems â" unless you already have physical access, and then all bets are off.

The compiler issue could be addressed by using a certified compiler, such as this: http://compcert.inria.fr/ [inria.fr] . Sadly CompCert is not FOSS.

Re:Proof (2)

jones_supa (887896) | about 3 months ago | (#47563841)

Sadly CompCert is not FOSS.

To me it looks like FOSS. The source code is available to download and it allows to choose between INRIA Non-Commercial License and GNU GPLv2.

Re:Proof (1)

HornWumpus (783565) | about 3 months ago | (#47567907)

Intel x86 systems management mode (SMM). If you can beat the processor into this mode all protected memory is off. You own it all, like DOS/MacOS prior to X.

This is also the mode that motherboard manufacturers put the CPU in, to hide the fact that they are using the processor to save money on hardware.

Undocumented OP codes are a bitch.

Re:Proof (0)

Anonymous Coward | about 3 months ago | (#47564023)

> While proved software is much better than unproved software, this is not the end of security holes

Of course not. Usually hardware is verified, and this has done nothing to prevent security holes either. Just for the record, neither would work proven libraries, compilers, run-times or virtual machines. To stop security holes you need to secure the whole stack, including user **applications** and the **operators**. To achieve this the only possible way is **extreme** simplification, any added complexity adds bugs.

Re:Proof (0)

Anonymous Coward | about 3 months ago | (#47578911)

Is there a good reason why suddenly everybody stopped saying "proven" and started saying "proved" instead? Just because the media talking heads do this does not mean everyone else absolutely must follow suit.

Shared Source (-1)

Anonymous Coward | about 3 months ago | (#47564269)

So, this is basically shared source.

Making something explicitly GPLv2, when that license has known problems that have been fixed in GPLv3, is a clear hint that someone has an agenda.

Take a look at the differences:

1. Tivoization. A possible loop hole (that was never tested in court) allows people to lock the binary away behind a signature, even though the GPLv2 explicitly requires everything needed to build the binary. So, the company behind this wants to sell it in closed devices? Nope, the copyright owner can do anything, including putting the same code under different licenses. They wouldn't need this.

2. Patents. GPLv3 requires that you give the license to any patents along with the code. If you have the code, but no patent license, you can look at the code all you want, but you cannot distribute it without a patent license. Basically what you get in this case is Shared Source, as Microsoft called their "read-only open source" idea.

With this trap, nope, I won't be touching this.

Now, some might be thinking "but doesn't that mean you won't be using Linux"? Nope, that's a different case. While the dangers of GPLv2 is still there, it was not deliberately chosen to allow Linus to patent the thing. It was chosen because we didn't have anything better at the time. When the GPLv3 was created, Linux included code from thousands of people, and changing the license had become impossible. It's stuck there. Yes, they could have chosen "or any later version" from the start, but that does have its own problems. That would basically allow the FSF to change the license. Imagine the FSF being bought out by Apple... Suddenly the GPLvX would state "all rights reserved Apple Corp". So, Linux is GPLv2 because its stuck there, not for some nefarious reasons.

Re:Shared Source (1)

Half-pint HAL (718102) | about 3 months ago | (#47564741)

A trap? Not really. From the developer's point of view, they'll still be able to get access to any changes to code on their terms, even if it is "tivoised". They can incorporate them into their code base without worrying too much about which hardware devices will or won't work - Somebody Else's Problem. They're interested in the code, not in "right to do whatever you want with your devices."

Shared Source (1)

slashdice (3722985) | about 3 months ago | (#47565363)

nice troll, too bad nobody is biting :( Slashdot has really gone down hill.

What exactly is the point? (2)

Half-pint HAL (718102) | about 3 months ago | (#47564715)

Surely a formally-proven OS doesn't want a traditional open-source license, because if you let people tinker, what you will end up with is forking... into unproven versions. And suddenly, the world's first formally-proven microkernel is just a plain old microkernel again.

OK, so maybe tinkering is alright as a personal hobby, but it risks the ecosystem.

Re:What exactly is the point? (2)

mr_mischief (456295) | about 3 months ago | (#47565583)

It allows others to borrow the code into their GPLv2 projects. It also allows others to make modifications which are not proven, but potentially those could be audited and proven, too.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?