In the se4L case, then it's a closed-source product based on modified GPL code and so your first line of thought applies. However, pressuring the owners of the product to comply is likely to produce a greater amount of negativity around open source than positivity, simply because almost nobody uses L4-based Linuxes.
Ah, good, a reply that's actually getting the point! Yay!
The problem is that in the first case (seL4), they specifically prohibit you from invoking or asking about any Open Source license whatsoever under any circumstance. To ignore that and ask them anyway is more likely to produce a backlash than a sympathetic response.
Under certain circumstances, you want to try anyway because it's more important TO try than to not try, no matter what the probability of a good response is. Under other circumstances, it's better to not stir the pot because it's more important to encourage people to look at Open Source in the first place than it is to win any specific battle - even if you could.
In the second case, we've no means of knowing what Mentor actually bought - even assuming they themselves know - and we already know Mentor is part of the Old Guard that is hostile to Open Source philosophy. Again, the only way to know the facts of the case are to dig and dig hard, but the sheer lack of users of the product convinces me that even if they agreed to make the Open Sourced variant available (albeit unmaintained), the antipathy that would be produced would far exceed the benefit of having the code.
So, again, you've got to find a place to draw a line in the sand. Beyond this point, it's just not worth even the most elementary of digging because even the tiniest of backlashes would swamp the greatest benefits you could possibly obtain.
I have no desire to be a jerk, directly to those involved OR to those who could benefit in future from businesses that feel Open Source is safe enough to enter. Finding an archive would probably work, though the impressive lack of links from anyone looking for such an archive tells me there probably isn't one. Not the end of the world (that's next year) but definitely frustrating.
Equally, doing nothing ever seems just as absurd. (The key word being "ever" - doing nothing when nothing needs to be done is just fine.) The FSF aren't the FBI, they don't have the kind of manpower to track down legitimate crossings of the line, they depend on people knowing where said line is and how to spot when someone's crossed it. In obvious cases, it's obvious. Obviously. But there's a fair amount of debate here as to what it is the GPL even says, which tells me that it's not so much a line in the sand as a fuzzy area the size of Texas in the sand. If none of us knows what a GPL violation actually looks like, how are any of us going to recognize one?
Finally, even when it's all nice and legal, that doesn't make things kosher. It's legal to do lots of highly unethical things and completely illegal to do some ethical things. What to do then?
There's no evidence that Mentor Graphics ARE the rights holder, and in the case of seL4 they certainly AREN'T the rights holder, so no I'm not asking that. Since that's obvious to everyone else but you, the safe bet would be that you're the one on drugs.
This is an excellent response, thank you. It shows that the issue is complex enough that it DOES have be to thought through and that it's not just me who is unsure just what is acceptable, and is highly informative over what the rules are. This is exactly the sort of info I was wanting, even though it doesn't go much into the ripples a decision either way will make.
(Doing nothing when doing something is correct is as much a problem as doing anything when doing nothing should be done. Both will produce ripples, unintended consequences. Sometimes these are good, often they're not. The "proper" reaction to a given situation can therefore also be the "improper" reaction, and vice versa. People are complicated, I recommend having nothing to do with them. I've never known a complicated turnip and henceforth will use Baldrik as a source of inspiration.)
Perhaps they have. It's not like Mentor Graphics is exactly OSS-friendly and tells us these things. They're worse than the old-style IBM and Microsoft combined.
Perhaps they haven't noticed. Engineers who use a product like VSIPL are very unlikely to have the months it would require to carry out a complete digital forensic analysis of Mentor's binaries to see if any code contributions they weren't entitled to were included.
Perhaps they don't have a bazillion dollars and are heavily reliant on the kinds of organizations that HATE fusses. If you were a consultant in one of the areas currently suffering high unemployment with most of those employed hired by the DoD (who paid for the open source version) and were currently under a contract from them, would YOU be kicking up a fuss? Probably not. It's easier to put bread on the table when you've bread in the bank. Stirring up trouble would be a great way to fry the contract and be out of work - long-term, possibly permanently. Absolutely not worth it.
Ok, what about any military contributions to the GPLed version? Even if GOTS was present in the codebase, I somehow think the military chain of command wouldn't give a damn if one of their lowly developers filed a complaint. They've bigger problems, for a start, and limited vendors they can buy from for another.
I'm not saying people have complained, merely that there's countless reasons why you specifically might not have heard if they had.
Ah, yes, and what facts specifically am I to find out?
What laws would you recommend understanding?
I think it safe to say that I wouldn't have asked the question if these were simple matters, and I think it's also safe to say that you would have been specific if you'd known any more than I do.
And even then, you've not answered the questions. Sure, I could do a lot of digging, but that involves bothering those involved and will make both them and others less inclined to do ANYTHING for the Open Source community in future.
Sure, I could dig, but WHEN? WHEN is it worth harassing people on these issues?
If it was so completely wrong, why DIDN'T you jump in and correct it when it was in the firehose? Why wait until after publication to complain when you could have addressed the problem earlier?
Seems to me, you're not as upset as all that about generating page views and ad revenue on articles you disagree with, or you'd be using what Slashdot already provides to ensure that the articles were all of high calibre.
It's a little more complex. I'll clarify. There were two code bases - one optimized and closed-source, one regular and GPLed. There was quite a lot of code shared between them, but there was code that solely existed in the GPLed version (all the non-optimized functions, for example). I believe the GPLed version took code contributions* and any that applied to the shared code would then exist in both versions. I do NOT know if the GPLed version included code from pre-existing VSIPL code bases for which Code Sourcery had rights under open source licenses but did not own that software - it seems entirely possible but it's not certain.
*The USAF paid for several years for Code Sourcery to have the GPLed version and paid them to have developers maintain it. It's a safe bet that the USAF wouldn't have paid extra specifically for that license if having it closed would have been just as effective. At the very least, it can be assumed the US Government contributed patches to the GPLed code.
Mentor buys Code Sourcery and continues the closed-source version. That's their right. That's fine. Provided, of course, that the closed-source version Mentor currently deploys has no software that Code Sourcery had no right to close. (I'll assume Code Sourcery played nice and didn't break any licenses themselves.) I'd consider it a possibility, but it would be extremely hard to test. Since the USAF now uses the closed source version, whatever it was that was contributed CAN be assumed to be in the closed version.
The open source version is another matter, in that it depends on whether Mentor is the true owner of it or if they are merely the owner of a fork. Since the GPLed code was produced under contract to the DoD and since any bits pulled from other projects would still be nominally owned by their original authors, it's impossible to assume Mentor bought the full rights. They're more likely to have bought only Code Sourcery's fraction of the rights.
Again, though, even if we assume it's all fully legal - which it may well be, it does not seem in the ethos of open source (hence the usage of kosher) to prohibit access to that part of the code which was shared and has not been changed since. What they do with the bits that are theirs that replaced the open source stuff, that's their business, along with the code that was never shared and always closed. The remainder --- uhhhhhh. It feels very icky that anyone, owner included, can retroactively alter the rights to something.
Mentor certainly didn't create it. It's not even clear to me if Code Sourcery created it, since VSIPL software already existed and it's entirely reasonable to think that they used code that already existed under Open Source licenses.
Even if Code Sourcery created every bit of the version Mentor bought, it's not clear Mentor owns the GPL version. They own the proprietary version, sure, as they bought the company that had the rights. Mentor never produced or distributed the GPL version. Since the code bases included shared code but were NOT identical (the closed version had heavily optimized versions of many of the functions), I'm not seeing anything that says Mentor is the sole copyright holder of the GPL edition. I'm reading that as meaning the shared code and the GPLed code were forked and that Mentor is merely the owner of their fork.
Sure they do not have to keep distributing new versions under the GPL, but that doesn't indicate to me that they're entitled to not distribute the old versions that were under the GPL. Provided the old versions are distributed in binary form (and I think they are), then I don't see anything in the GPL about retroactive un-GPLing it. That would be doubly so if indeed Mentor only owns their fork. I couldn't fork Linux and then close-source it, claiming I was the owner of that fork. (Although that IS what was claimed by the SE4L group.)
Let's say, for argument's sake, that Mentor do own the code and do have all the rights. Is it still kosher to un-GPL code? It may be legal as per copyright, but the word "kosher" is less about the strict governmental laws and more about the belief system and philosophies. In this case, that means copyleft. Forgetting whether you'd win in court, is it kosher to take software that had once been GPL and close it to the world?
That's what I'm meaning. Further, any contribution submitted into the shared codebase after the last GPLed release and before the code went closed-source only would exist only in the closed-source version. The first case, it may be argued that the code was known to be under both licenses so submissions would be understood to be in both trees and thus discontinuing one tree is still not a problem. Submissions made after the last GPLed version drop but before Code Sourcery were bought - errr, that's not so clear-cut because such submissions were not used for the purpose for which they were developed.
However, the picture isn't as clear-cut as Arlet suggested. Yes, it's legal to abandon the GPLed version but nobody has answered (so far) the fact that a certain percentage of the code WAS distributed under the GPL and whilst the GPL has a provision for allowing code to be reused in closed-source software, it only permits that specific piece of re-use to not be GPLed when it is substantially different from the GPLed version. In other words, those bits of the library that are completely identical to the GPLed version are surely covered by the provision stating that that code remains covered by the GPL even when the rest of the code is not.
It gets a bit more complex, since I'm reasonably sure you can still buy the binaries from the dual-licensed form and I see nothing in the GPL that says you can retroactively change the license of a GPLed product.
Further, it depends on whether you consider Mentor Graphics to now own the software that had been GPLed or be merely a licensee. In other words, when a company that has GPLed code is bought, is the new "owner" maintaining the "original" or a fork? If it's a fork. then they are only entitled to use the code at all under the license of the GPL and certainly can't re-license the GPLed portions as they don't own the GPLed portion. They only own the right to modify and distribute it. If it's the original, then that wouldn't apply.
In the case of, say, MySQL, Oracle are entitled to produce completely new functionality and close-source that functionality but aren't entitled to close MySQL simply because new functionality exists. Which is why we have the multiple versions from Oracle. They can stop developing MySQL, they can replace chunks of MySQL with proprietary code, but they can't re-license the chunks that were under the old license.
Oh, and their license agreement states that in order to download the software you have to renounce all Open Source rights and agree not to pursue them. Now, I personally didn't see any clause in there saying I couldn't forward the info to the FSF guys for them to pursue, I just had to agree that I wouldn't.
(If they're not going to make any meaningful use of the project, I'm sorely tempted to take the risk and let the Gnu folk know what's going on. The risk being that the developers take the website down and claim it's a private project, which would deprive everyone else of the use of even the binaries. It's a hard one. I don't want to irk people who are doing valuable work, but if they're not doing any valuable work any more and the code is bit-rotting, it seems better to take the gamble than not. What's your take on it?)
I know that and I'm always grateful for new information. (I devour new information like most programmers devour pizza. This means my brain is overweight and a slob, but very happy when fed.)
Agreed completely on two grounds. Rats, even the extinct 0.75 tonne ones, are closely related to squirrels so no matter what method you use you will get about the same distance to this new species and therefore you can pick either. However, your point (I think) is that the relationship is so distant from any extant small mammals that you can still pick any of them with a roughly equal probability of picking the one that actually is the closest. I can buy that.
General Sciency part:
Morphological data is often all paleontologists have to go on (although you CAN extract spider and brewing yeast DNA from 45 million year old amber), so in such cases there simply isn't a choice. You have to go with that because there's nothing else to go by. Well, not unless you've a handy TARDIS or other time machine.
The relationship that you're talking about tells us structurally how things relate. It can be used to build up a reasonable tree showing where the relationships coming from. I say "can" because, as you know, the early family tree of birds is highly contentious due to the question of which changes are considered important and which are not. You get very different trees according to how you divide the characteristics up. A morphological tree, then, is most useful when there's no ambiguity. Ambiguity is always a warning sign that there's insufficient data leading to multiple possible scenarios.
Let's assume that we have a good tree, though. What can we infer from it, beyond where species divided off? Not as much as we'd like. We know that a morphological change is caused by a genetic change, but not all genetic changes lead to morphological changes and equal-sized genetic changes can produce unequal-sized morphological changes. As a result, having the tree gives us plenty of constraints on the relationship between two species and it gives us a specific number of parameters, but it doesn't give us values for any of them.
Specific to this Post Part:
It's extremely hard to say what is meant by "relative" in this context. If you mean "this species isn't a direct ancestor of squirrels" then I'd say you're absolutely correct. If you mean "the order to which this species belongs is not directly connected to any part of the ancestral lineage of squirrels" then I'm happy to accept that at face value. If you mean "the last common ancestor between this and squirrels pre-dates other branches from either lineage that survive today and are not considered related", again I'm happy to accept that. In other words, anything that treats the tree as a genealogical map and considers Nth cousins for some accepted value of N as being "related" and nothing else is probably going to say these species are unrelated.
From a molecular standpoint, things get more complex. In terms of the genetics, it is technically wrong to depict all morphological branches as being at equal angles from the lineage they branch from, as we simply don't know how many evolutionary steps were taken for the changes to become visible. It might be one, it might be a million. But because rock doesn't preserve DNA too well, we have no way of knowing which end of the spectrum things are. Hence, the simplest option is to assume that the average will be about the same as you can't really do otherwise.
The practical upshot is that if we take the morphological tree, some branches may be squished together and others may be much further apart than the morphology alone would suggest. So, if you define "relative" as being "within a certain distance" on the tree in a straight line rather than as a count of branchings (ie: the genetic distance falls below G, where G is some threshold for what is considered related), you can guarantee you'll get very different results than from the morphological genealogy. What you can't do is say in which direction and therefore you can't say (for fossils, at least) what the straight-line distance is and therefore cannot say how closely related something is at the molecular level
Bar stewards! (Actually, just been to their site. They're distributing kernel binaries, if you dig around some, which means they're legally required to provide the source code for the kernel on request, though they're not required to provide the source code for the security kernel if it is a module. They have to if it's solidly built into the code, though.)
Because the security kernel is the only part that actually has to be formally proven for A1 or EAL7, provided the security kernel totally isolates the protected facilities from the rest of the kernel, an audit and a few mods to the various Linux testing tools out there should be able to show SEL4 as EAL7-compliant. And even though IBM would never market such a version, they've already had Linux certified up to EAL5+ and there would be considerable bragging-rights if they were able to produce an EAL7-certified version. (Just as JCB doesn't sell their GT sports model backhoe but uses it for promotional stunts and drag racing, IBM could - in principle - do likewise with Linux. Well, not the drag racing part, although cars -are- becoming more computerized...)
I'm using IBM as an example here because they're the ones with the buckets of cash needed for Common Criteria certification, although any major company could do it. I'm also less concerned about such certification for "practical" usage of SEL4 as I am in certification schemes of any kind being usable as proof that given standards of security can actually be met in the real world. There's a huge difference between thinking something might be doable and seeing something that has already been done.
I'm glad you mentioned this project because there is so much fascinating work out there that is too damn obscure! Doesn't matter if I'm wrong on what level of compliance they'd get, the mere fact that the project exists and that segments of the code have been formally proven could lead to all kinds of fascinating and neat developments in Linux and other OS'. Provided, of course, kernel developers learn that things like this actually exist.
No, you do not understand the nature of MAC as defined under the Rainbow books. MIC is NOT the same thing. It is an extremely limited, unidirectional subset.
Biting through fire hydrants is terrible, though. You've got to think of the dogs!
Ok, seriously, yes. I wouldn't have wanted to have met any of the ancient bears. Even the European Cave bear was lethal and psychotic. Nothing after that point matters, unless you're into making slasher horror films and want to make them biologically correct.
The logic is easy. Nobody reads the Firehose, so only catchy titles ever get spotted, and even fewer submit stories in the first place. (It's complex. Or, in some cases, wholly imaginary.)
An extinct giant short-faced bear that went extinct 5 million years ago would have put up a decent fight against Secret Squirrel here. "Our analyses show that it had the most powerful bite of any known terrestrial mammal determined thus far," Dr Wroe told BBC Nature.
It's unclear and therefore the superorder (which is morphic, not genetic, and therefore almost certainly wrong -- traditional classifications tend not to hold up under genetic scrutiny) is immaterial.
Second, it's on here because it's a discovery of a new species. That's a particularly interesting part of science. Linking it with squirrels was no worse a travesty than chaos mathematicians linking storms and butterflies, and certainly no worse than plasma physicists talking of sausage instabilities. Nobody is trying to forecast the weather by studying insects and nobody is trying to cook breakfast in a nuclear fusion facility. I'll agree that Joe Average might be confused, but Joe Average certainly has no business being on a news-for-nerds site.
Tsk! We don't know the genetic distance between this species and squirrels, all you can say is that squirrels aren't direct ancestors and therefore the genetic distance can't be any less than that between squirrels and the common ancestor of all modern rodentia. It can certainly be smaller than the genetic distance between squirrels and rodent-like animals that provably have a TMRCA of comparable age - mammals were quite diverse 94 million yeas ago and this new species may well be from a sub-branch off the branch that eventually became squirrels. Nothing in TFA to prohibit that, although it's a little unlikely.
You stating certainties where you have none is a far worse example of KWing than the headline.
Slashdot Mirror
In the se4L case, then it's a closed-source product based on modified GPL code and so your first line of thought applies. However, pressuring the owners of the product to comply is likely to produce a greater amount of negativity around open source than positivity, simply because almost nobody uses L4-based Linuxes.
Ah, good, a reply that's actually getting the point! Yay!
The problem is that in the first case (seL4), they specifically prohibit you from invoking or asking about any Open Source license whatsoever under any circumstance. To ignore that and ask them anyway is more likely to produce a backlash than a sympathetic response.
Under certain circumstances, you want to try anyway because it's more important TO try than to not try, no matter what the probability of a good response is. Under other circumstances, it's better to not stir the pot because it's more important to encourage people to look at Open Source in the first place than it is to win any specific battle - even if you could.
In the second case, we've no means of knowing what Mentor actually bought - even assuming they themselves know - and we already know Mentor is part of the Old Guard that is hostile to Open Source philosophy. Again, the only way to know the facts of the case are to dig and dig hard, but the sheer lack of users of the product convinces me that even if they agreed to make the Open Sourced variant available (albeit unmaintained), the antipathy that would be produced would far exceed the benefit of having the code.
So, again, you've got to find a place to draw a line in the sand. Beyond this point, it's just not worth even the most elementary of digging because even the tiniest of backlashes would swamp the greatest benefits you could possibly obtain.
I have no desire to be a jerk, directly to those involved OR to those who could benefit in future from businesses that feel Open Source is safe enough to enter. Finding an archive would probably work, though the impressive lack of links from anyone looking for such an archive tells me there probably isn't one. Not the end of the world (that's next year) but definitely frustrating.
Equally, doing nothing ever seems just as absurd. (The key word being "ever" - doing nothing when nothing needs to be done is just fine.) The FSF aren't the FBI, they don't have the kind of manpower to track down legitimate crossings of the line, they depend on people knowing where said line is and how to spot when someone's crossed it. In obvious cases, it's obvious. Obviously. But there's a fair amount of debate here as to what it is the GPL even says, which tells me that it's not so much a line in the sand as a fuzzy area the size of Texas in the sand. If none of us knows what a GPL violation actually looks like, how are any of us going to recognize one?
Finally, even when it's all nice and legal, that doesn't make things kosher. It's legal to do lots of highly unethical things and completely illegal to do some ethical things. What to do then?
There's no evidence that Mentor Graphics ARE the rights holder, and in the case of seL4 they certainly AREN'T the rights holder, so no I'm not asking that. Since that's obvious to everyone else but you, the safe bet would be that you're the one on drugs.
This is an excellent response, thank you. It shows that the issue is complex enough that it DOES have be to thought through and that it's not just me who is unsure just what is acceptable, and is highly informative over what the rules are. This is exactly the sort of info I was wanting, even though it doesn't go much into the ripples a decision either way will make.
(Doing nothing when doing something is correct is as much a problem as doing anything when doing nothing should be done. Both will produce ripples, unintended consequences. Sometimes these are good, often they're not. The "proper" reaction to a given situation can therefore also be the "improper" reaction, and vice versa. People are complicated, I recommend having nothing to do with them. I've never known a complicated turnip and henceforth will use Baldrik as a source of inspiration.)
Perhaps they have. It's not like Mentor Graphics is exactly OSS-friendly and tells us these things. They're worse than the old-style IBM and Microsoft combined.
Perhaps they haven't noticed. Engineers who use a product like VSIPL are very unlikely to have the months it would require to carry out a complete digital forensic analysis of Mentor's binaries to see if any code contributions they weren't entitled to were included.
Perhaps they don't have a bazillion dollars and are heavily reliant on the kinds of organizations that HATE fusses. If you were a consultant in one of the areas currently suffering high unemployment with most of those employed hired by the DoD (who paid for the open source version) and were currently under a contract from them, would YOU be kicking up a fuss? Probably not. It's easier to put bread on the table when you've bread in the bank. Stirring up trouble would be a great way to fry the contract and be out of work - long-term, possibly permanently. Absolutely not worth it.
Ok, what about any military contributions to the GPLed version? Even if GOTS was present in the codebase, I somehow think the military chain of command wouldn't give a damn if one of their lowly developers filed a complaint. They've bigger problems, for a start, and limited vendors they can buy from for another.
I'm not saying people have complained, merely that there's countless reasons why you specifically might not have heard if they had.
Ah, yes, and what facts specifically am I to find out?
What laws would you recommend understanding?
I think it safe to say that I wouldn't have asked the question if these were simple matters, and I think it's also safe to say that you would have been specific if you'd known any more than I do.
And even then, you've not answered the questions. Sure, I could do a lot of digging, but that involves bothering those involved and will make both them and others less inclined to do ANYTHING for the Open Source community in future.
Sure, I could dig, but WHEN? WHEN is it worth harassing people on these issues?
If it was so completely wrong, why DIDN'T you jump in and correct it when it was in the firehose? Why wait until after publication to complain when you could have addressed the problem earlier?
Seems to me, you're not as upset as all that about generating page views and ad revenue on articles you disagree with, or you'd be using what Slashdot already provides to ensure that the articles were all of high calibre.
It's a little more complex. I'll clarify. There were two code bases - one optimized and closed-source, one regular and GPLed. There was quite a lot of code shared between them, but there was code that solely existed in the GPLed version (all the non-optimized functions, for example). I believe the GPLed version took code contributions* and any that applied to the shared code would then exist in both versions. I do NOT know if the GPLed version included code from pre-existing VSIPL code bases for which Code Sourcery had rights under open source licenses but did not own that software - it seems entirely possible but it's not certain.
*The USAF paid for several years for Code Sourcery to have the GPLed version and paid them to have developers maintain it. It's a safe bet that the USAF wouldn't have paid extra specifically for that license if having it closed would have been just as effective. At the very least, it can be assumed the US Government contributed patches to the GPLed code.
Mentor buys Code Sourcery and continues the closed-source version. That's their right. That's fine. Provided, of course, that the closed-source version Mentor currently deploys has no software that Code Sourcery had no right to close. (I'll assume Code Sourcery played nice and didn't break any licenses themselves.) I'd consider it a possibility, but it would be extremely hard to test. Since the USAF now uses the closed source version, whatever it was that was contributed CAN be assumed to be in the closed version.
The open source version is another matter, in that it depends on whether Mentor is the true owner of it or if they are merely the owner of a fork. Since the GPLed code was produced under contract to the DoD and since any bits pulled from other projects would still be nominally owned by their original authors, it's impossible to assume Mentor bought the full rights. They're more likely to have bought only Code Sourcery's fraction of the rights.
Again, though, even if we assume it's all fully legal - which it may well be, it does not seem in the ethos of open source (hence the usage of kosher) to prohibit access to that part of the code which was shared and has not been changed since. What they do with the bits that are theirs that replaced the open source stuff, that's their business, along with the code that was never shared and always closed. The remainder --- uhhhhhh. It feels very icky that anyone, owner included, can retroactively alter the rights to something.
Mentor certainly didn't create it. It's not even clear to me if Code Sourcery created it, since VSIPL software already existed and it's entirely reasonable to think that they used code that already existed under Open Source licenses.
Even if Code Sourcery created every bit of the version Mentor bought, it's not clear Mentor owns the GPL version. They own the proprietary version, sure, as they bought the company that had the rights. Mentor never produced or distributed the GPL version. Since the code bases included shared code but were NOT identical (the closed version had heavily optimized versions of many of the functions), I'm not seeing anything that says Mentor is the sole copyright holder of the GPL edition. I'm reading that as meaning the shared code and the GPLed code were forked and that Mentor is merely the owner of their fork.
Sure they do not have to keep distributing new versions under the GPL, but that doesn't indicate to me that they're entitled to not distribute the old versions that were under the GPL. Provided the old versions are distributed in binary form (and I think they are), then I don't see anything in the GPL about retroactive un-GPLing it. That would be doubly so if indeed Mentor only owns their fork. I couldn't fork Linux and then close-source it, claiming I was the owner of that fork. (Although that IS what was claimed by the SE4L group.)
Let's say, for argument's sake, that Mentor do own the code and do have all the rights. Is it still kosher to un-GPL code? It may be legal as per copyright, but the word "kosher" is less about the strict governmental laws and more about the belief system and philosophies. In this case, that means copyleft. Forgetting whether you'd win in court, is it kosher to take software that had once been GPL and close it to the world?
That's what I'm meaning. Further, any contribution submitted into the shared codebase after the last GPLed release and before the code went closed-source only would exist only in the closed-source version. The first case, it may be argued that the code was known to be under both licenses so submissions would be understood to be in both trees and thus discontinuing one tree is still not a problem. Submissions made after the last GPLed version drop but before Code Sourcery were bought - errr, that's not so clear-cut because such submissions were not used for the purpose for which they were developed.
However, the picture isn't as clear-cut as Arlet suggested. Yes, it's legal to abandon the GPLed version but nobody has answered (so far) the fact that a certain percentage of the code WAS distributed under the GPL and whilst the GPL has a provision for allowing code to be reused in closed-source software, it only permits that specific piece of re-use to not be GPLed when it is substantially different from the GPLed version. In other words, those bits of the library that are completely identical to the GPLed version are surely covered by the provision stating that that code remains covered by the GPL even when the rest of the code is not.
It gets a bit more complex, since I'm reasonably sure you can still buy the binaries from the dual-licensed form and I see nothing in the GPL that says you can retroactively change the license of a GPLed product.
Further, it depends on whether you consider Mentor Graphics to now own the software that had been GPLed or be merely a licensee. In other words, when a company that has GPLed code is bought, is the new "owner" maintaining the "original" or a fork? If it's a fork. then they are only entitled to use the code at all under the license of the GPL and certainly can't re-license the GPLed portions as they don't own the GPLed portion. They only own the right to modify and distribute it. If it's the original, then that wouldn't apply.
In the case of, say, MySQL, Oracle are entitled to produce completely new functionality and close-source that functionality but aren't entitled to close MySQL simply because new functionality exists. Which is why we have the multiple versions from Oracle. They can stop developing MySQL, they can replace chunks of MySQL with proprietary code, but they can't re-license the chunks that were under the old license.
Oh, and their license agreement states that in order to download the software you have to renounce all Open Source rights and agree not to pursue them. Now, I personally didn't see any clause in there saying I couldn't forward the info to the FSF guys for them to pursue, I just had to agree that I wouldn't.
(If they're not going to make any meaningful use of the project, I'm sorely tempted to take the risk and let the Gnu folk know what's going on. The risk being that the developers take the website down and claim it's a private project, which would deprive everyone else of the use of even the binaries. It's a hard one. I don't want to irk people who are doing valuable work, but if they're not doing any valuable work any more and the code is bit-rotting, it seems better to take the gamble than not. What's your take on it?)
I know that and I'm always grateful for new information. (I devour new information like most programmers devour pizza. This means my brain is overweight and a slob, but very happy when fed.)
"Saber-toothed rat" part:
Agreed completely on two grounds. Rats, even the extinct 0.75 tonne ones, are closely related to squirrels so no matter what method you use you will get about the same distance to this new species and therefore you can pick either. However, your point (I think) is that the relationship is so distant from any extant small mammals that you can still pick any of them with a roughly equal probability of picking the one that actually is the closest. I can buy that.
General Sciency part:
Morphological data is often all paleontologists have to go on (although you CAN extract spider and brewing yeast DNA from 45 million year old amber), so in such cases there simply isn't a choice. You have to go with that because there's nothing else to go by. Well, not unless you've a handy TARDIS or other time machine.
The relationship that you're talking about tells us structurally how things relate. It can be used to build up a reasonable tree showing where the relationships coming from. I say "can" because, as you know, the early family tree of birds is highly contentious due to the question of which changes are considered important and which are not. You get very different trees according to how you divide the characteristics up. A morphological tree, then, is most useful when there's no ambiguity. Ambiguity is always a warning sign that there's insufficient data leading to multiple possible scenarios.
Let's assume that we have a good tree, though. What can we infer from it, beyond where species divided off? Not as much as we'd like. We know that a morphological change is caused by a genetic change, but not all genetic changes lead to morphological changes and equal-sized genetic changes can produce unequal-sized morphological changes. As a result, having the tree gives us plenty of constraints on the relationship between two species and it gives us a specific number of parameters, but it doesn't give us values for any of them.
Specific to this Post Part:
It's extremely hard to say what is meant by "relative" in this context. If you mean "this species isn't a direct ancestor of squirrels" then I'd say you're absolutely correct. If you mean "the order to which this species belongs is not directly connected to any part of the ancestral lineage of squirrels" then I'm happy to accept that at face value. If you mean "the last common ancestor between this and squirrels pre-dates other branches from either lineage that survive today and are not considered related", again I'm happy to accept that. In other words, anything that treats the tree as a genealogical map and considers Nth cousins for some accepted value of N as being "related" and nothing else is probably going to say these species are unrelated.
From a molecular standpoint, things get more complex. In terms of the genetics, it is technically wrong to depict all morphological branches as being at equal angles from the lineage they branch from, as we simply don't know how many evolutionary steps were taken for the changes to become visible. It might be one, it might be a million. But because rock doesn't preserve DNA too well, we have no way of knowing which end of the spectrum things are. Hence, the simplest option is to assume that the average will be about the same as you can't really do otherwise.
The practical upshot is that if we take the morphological tree, some branches may be squished together and others may be much further apart than the morphology alone would suggest. So, if you define "relative" as being "within a certain distance" on the tree in a straight line rather than as a count of branchings (ie: the genetic distance falls below G, where G is some threshold for what is considered related), you can guarantee you'll get very different results than from the morphological genealogy. What you can't do is say in which direction and therefore you can't say (for fossils, at least) what the straight-line distance is and therefore cannot say how closely related something is at the molecular level
Bar stewards! (Actually, just been to their site. They're distributing kernel binaries, if you dig around some, which means they're legally required to provide the source code for the kernel on request, though they're not required to provide the source code for the security kernel if it is a module. They have to if it's solidly built into the code, though.)
Because the security kernel is the only part that actually has to be formally proven for A1 or EAL7, provided the security kernel totally isolates the protected facilities from the rest of the kernel, an audit and a few mods to the various Linux testing tools out there should be able to show SEL4 as EAL7-compliant. And even though IBM would never market such a version, they've already had Linux certified up to EAL5+ and there would be considerable bragging-rights if they were able to produce an EAL7-certified version. (Just as JCB doesn't sell their GT sports model backhoe but uses it for promotional stunts and drag racing, IBM could - in principle - do likewise with Linux. Well, not the drag racing part, although cars -are- becoming more computerized...)
I'm using IBM as an example here because they're the ones with the buckets of cash needed for Common Criteria certification, although any major company could do it. I'm also less concerned about such certification for "practical" usage of SEL4 as I am in certification schemes of any kind being usable as proof that given standards of security can actually be met in the real world. There's a huge difference between thinking something might be doable and seeing something that has already been done.
I'm glad you mentioned this project because there is so much fascinating work out there that is too damn obscure! Doesn't matter if I'm wrong on what level of compliance they'd get, the mere fact that the project exists and that segments of the code have been formally proven could lead to all kinds of fascinating and neat developments in Linux and other OS'. Provided, of course, kernel developers learn that things like this actually exist.
Ok. I'd heard otherwise, but if you were actually involved then you've direct knowledge and that's always better than indirect reports.
No, you do not understand the nature of MAC as defined under the Rainbow books. MIC is NOT the same thing. It is an extremely limited, unidirectional subset.
Biting through fire hydrants is terrible, though. You've got to think of the dogs!
Ok, seriously, yes. I wouldn't have wanted to have met any of the ancient bears. Even the European Cave bear was lethal and psychotic. Nothing after that point matters, unless you're into making slasher horror films and want to make them biologically correct.
The logic is easy. Nobody reads the Firehose, so only catchy titles ever get spotted, and even fewer submit stories in the first place. (It's complex. Or, in some cases, wholly imaginary.)
Good question. You've got me curious now, I'll look that up. It was one of the L4-based Linux microkernels?
An extinct giant short-faced bear that went extinct 5 million years ago would have put up a decent fight against Secret Squirrel here. "Our analyses show that it had the most powerful bite of any known terrestrial mammal determined thus far," Dr Wroe told BBC Nature.
This should explain things more clearly.
It's unclear and therefore the superorder (which is morphic, not genetic, and therefore almost certainly wrong -- traditional classifications tend not to hold up under genetic scrutiny) is immaterial.
Second, it's on here because it's a discovery of a new species. That's a particularly interesting part of science. Linking it with squirrels was no worse a travesty than chaos mathematicians linking storms and butterflies, and certainly no worse than plasma physicists talking of sausage instabilities. Nobody is trying to forecast the weather by studying insects and nobody is trying to cook breakfast in a nuclear fusion facility. I'll agree that Joe Average might be confused, but Joe Average certainly has no business being on a news-for-nerds site.
Tsk! We don't know the genetic distance between this species and squirrels, all you can say is that squirrels aren't direct ancestors and therefore the genetic distance can't be any less than that between squirrels and the common ancestor of all modern rodentia. It can certainly be smaller than the genetic distance between squirrels and rodent-like animals that provably have a TMRCA of comparable age - mammals were quite diverse 94 million yeas ago and this new species may well be from a sub-branch off the branch that eventually became squirrels. Nothing in TFA to prohibit that, although it's a little unlikely.
You stating certainties where you have none is a far worse example of KWing than the headline.
Bah. Just noticed the username. Never mind.
I think it's owls that hoot. Squirrels make more of a chittering sound.