Thanks. It's rare to see someone actually follow through on a statement like that here on slashdot.
The problem the committees tried to solve with their new terminology is a real one, and I don't want to minimise that. Most people using computers these days don't even know what binary means, and as the powers go higher, the difference between the binary and the decimal interpretation increases. The potential for confusion is great. And if their terminology had been used from the start it would make sense. But the fact is it hasn't, we've got over 30 years of tradition using the binary terms, and for some committee to think they can simply redefine them by fiat is irritating to say the least. Given that the the usage is already well supported and entrenched, not to mention that the binary values are the natural groupings of bytes which make sense in the areas where they are used, I would propose instead of trying to redefine kilobyte as 1,000 bytes and make up a new term (kilo-binary-byte aka kibibyte) for what we already call a kilobyte, they should make up new terms for the less useful values instead (perhaps decimal-kilo-byte aka dekilobyte for 1,000 bytes.) As it is, their proposal is being mostly ignored, causing even more confusion than existed before they tried to remedy the situation, and about the only folks that seem to get anything good from it as far as I can see are the hard drive manufacturers, who get a handy excuse to continue inflating their drive capacity numbers.
Drive manufacturers have done that for years, ever since they started selling more drives to non-technical types than to geeks, just to inflate their numbers.
Communications devices, however, are a different matter - they're more the province of electrical engineers than computer scientists, and referring essentially to circuit cycle speed, so it makes perfect sense to use decimal there.
Your definition is good, and if it's correct then I humbly apologise for being so trollish sir. Until some suitably respected authority confirms your definition, I shall have to call shenanigoats.
If you want an authority for this you don't need to look very hard, just hit the Jargon File.
quantifiers
In techspeak and jargon, the standard metric prefixes used in the SI (Système International) conventions for scientific measurement have dual uses. With units of time or things that come in powers of 10, such as money, they retain their usual meanings of multiplication by powers of 1000 = 10^3. But when used with bytes or other things that naturally come in powers of 2, they usually denote multiplication by powers of 1024 = 2^10.
Here are the SI magnifying prefixes, along with the corresponding binary interpretations in common use:
Changing the rules after the fact is confusing you see.
But that's exactly what your sources are doing - attempting to change the definitions after the fact. I've been using these units since 1980, and they were old when I started soldering computers together and programming them. It's only very recently that the confusion has arisen - primarily because the SI folks invented new units and rather than give them new names, attempted to coöpt the already existing and well established names for their new units, and give new names no one had ever heard of before for the old ones.
If people (that's you, adamofgreyskull) would stop propounding incorrect use of the language, those of us who quietly continue to use it correctly would... give you a pat on the back.
A byte is binary 1000 (that's 8 in decimal) bits. A kilobyte is binary 10000000000 (1024 in decimal) bytes. A megabyte is binary 10000000000 (again 1024 in decimal) kilobytes. A gigabyte is binary 10000000000 megabytes. Bits (Binary digITS) are counted in binary, not decimal. Surely a bright guy like you can figure this out?
Just because some idiotic idea got posted with a.gov address doesn't refute the posters point. They've just made up their own units, which by itself is actually fine by me, though in this case pointless - but their attempt to name these units with names already taken long ago for useful units is not.
Any real geek would know that bytes are counted in binary, not decimal, so your appeal will certainly fall on deaf ears. Excepting a few mentally challenged moderators, obviously.
And yes, I know all about the SI page you're going to link next. All would-be standards setting bodies should keep in mind the abject failure that group has had in it's attempt to redefine megabyte and gigabyte whenever they get the urge to indulge in similar stupidity themselves. Those terms not only sound stupid, more importantly they are completely unecessary and serve no purpose other than to confuse an area that was perfectly clear before. The SI folks, thankfully, have no power to enforce their stupid ideas, so geeks around the world can quite safely continue to give them the attention they deserve - none.
The threat of impending hunger and homelessness for a fellow with considerable skill in both chemistry and computers certainly sounds coersive to me.
It could be coërsion, but only if it's a threat in the strict, not the loose sense - that is if there is a person threatening to somehow do this to you if you don't bend to his will - NOT if it's simply external circumstances in general.
I can't force the world to give me good luck but I find the distinct lack of any reasonable opportunity to be more than suspicious. I've met former felons that get treated better with reaspect to financial advancement and job opportunity.
I have a feeling we're actually a lot alike in that respect - certainly I didn't find working in corporate America any more congenial than you are finding it.
Who? How did _he_ get into this?
He got into it because it was in his name that the habit of speaking of people as being 'coërsed' by general circumstances, rather than by deliberate individual action, and particularly the attempts to confuse the one with the other in terms of legal and moral consequences, became widespread in the last century - no more, no less.
How about after every paragraph of a EULA/Terms of Service, there is a check box indicating the paragraph had been read, Yes or No, with no default, and if any box is left unchecked the software would not load. At the least, a user would have to go down thru the EULA/Terms of Service and check each box.
This would prove only that someone read the terms, not that s/he agreed to them, or that s/he was a person with authority to bind other users of the computer to them.
And even if it did, it still wouldn't be a valid contract, since there is no quid pro quo - the user gets no compensation under these agreements except the ability to use the software which is already bought and paid for - it's like if I sold you a car, then turned around and refused to deliver it until you signed a paper purporting to give me access to your wife and daughters perpetually. Nor is it a valid license, since it gives no permission to do anything that one can't legally do to begin with, but rather in fact purports to forbid many things that could be legally done without agreeing to it.
What it would accomplish would be to waste even more of the users time, and make the disdeign with which the software company involved treats their customers more obvious.
Of course, in a sane world, customers would be so offended by even this lame attempt to take away their rights without even token compensation, by blocking them from functionality they already purchased and holding it ransom for their 'agreement' that they would immediately boycott the company that produced such nonsense in the first place.
I agree, there is no way a EULA can be valid under contract law, although there are some factual errors in your post I should clear up. Oral contracts are just as valid as written ones. Of course, if there are no witnesses and the other party is willing to perjure him/herself, then you can have a problem, which is why signed papers are preferable. Notaries and witnesses are not required, they just (like having it on paper) make it easier to establish facts later if you have to sue to enforce it.
But EULAs lack any 'meeting of the minds', any compensation for the 'end user,' and any verification as to who the supposed 'end user' who clicks the accept button is, among other things. This is why they don't call themselves contracts, but rather 'licenses.' This dodge doesn't hold much water either, however.
Legally, you have no need for a 'license' to use the software you've already bought. (You would need a license to, for instance, create derivative works based on it, but not simply to use it.) So why on earth would anyone agree to one?
I've certainly never agreed to any such thing. I've occasionally pushed a button saying 'agree' or the like, simply because it's the only way to get software I own to perform it's function, but the act is certainly performed in those cases without any intent to actually agree to the 300 pages of legalese that I haven't even looked at. I daresay I'm probably a pretty mainstream computer user in that way. And I can't see how a court could possibly claim that this act somehow held any water as a legal agreement without ceasing entirely to be concerned or bound by legal traditions and principles and coming out in broad daylight as just a mouthpiece for the corporations and nothing more.
Please, educate me more about this clause. I'd like to have my employment and credit card contracts reevaluated under the light of,"Well, your Honor, it was either sign a contract that I knew was a scam or else look at homeless hunger as a real option of life."
That's not duress. Unless of course you were put in that position by the credit card guys, through no fault of your own, then the point could be argued perhaps.
: wrongful and usu. unlawful compulsion (as threats of physical violence) that induces a person to act against his or her will: "coercion"
Your lack of due diligence or even genuine lack of opportunity doesn't allow you to claim duress, despite the Marxist habit of claiming otherwise.
I wonder if you can link to the new code dynamically just like I can link to LGPL dynamically without changing whatever license I choose.
That's one of those areas of copyright law that there are different opinions on, but IIRC the opinion of the FSF counsel is a qualified no. The qualification being that if the code you're linking is sufficiently generalised that there are other libraries it could link to just as well then there's no question of 'derivative works' and so that would be ok (like it's ok to dynamically link your GPL code to a proprietary C library as long as the same code will work fine linked to Glibc instead) - but if your code is specific to the X code, so it can't function without it, then the licenses have to be compatible.
That wouldn't come up anyway, unless the XFree guys start applying the new license to the library code which it currently does not apply to. I don't think there's a short term practical problem here in terms of anything folks are doing at the moment being illegal because of the new license. But at the very least, it's a pain in the ass because now everyone has to run around involving the lawyers just to be sure of that fact where there was no question before.
So there actually does not seem to be a conflict with GPL licencing in apps at all, so I dont understand why people are so concerned over the licence change. Its still an open source licence which you can freely use, modify, and redistribute.
There definately is a conflict with the GPL. You cannot add any conditions to the license, the GPL prevents that. So a license which imposes conditions above and beyond what the GPL requires are GPL incompatible - you cannot legally combine code under the GPL with code under this license. It's true that it's a relatively innocuous condition, and not a big deal in and of itself, but you still can't combine code with it under the GPL legally, and that's what the concern is.
Since they've stated they don't intend to place library code under this license (I think, although I can't seem to find a link to back that up) it doesn't seem like a huge deal, but considering all the problems with the XFree86 organisation lately, and the fact that there's a perfectly good GPL-compatible fork (which probably has more active developers already) there's just no reason not to avoid the potential problems of having a major part of your distribution GPL-incompatible unecessarily.
Hmm, so like slack, it's available in a development branch only. Hardly what I would have expected from the words "Distros that have integrated it."
In regards to linking, I believe the new license is only on non-library code.
Quite true (although if I'm not mistaken that's the case only because when confronted on the issue they tried to back down off the original plan to avoid trouble?) and the license change isn't that huge a deal for that reason IMOP. At the moment, it covers a miniscule amount of code in fact, but of course that amount of code will grow over time, if Xfree86 keeps putting out code at least. More than anything else it seems that the whole flap over this issue has been sort of a 'last straw' that's pushed the alternative projects to critical mass and discouraged distro makers from using Xfree86.
The "slackware-current" version of Slackware right now has the 4.4.0 version in the official "X" section, but recently the X.org version was made available (in the 'testing' section) as an alternative. I suspect that X.org may supplant the XFree86 4.4.0 version before the next 'official' slackware release.
Heh, ok, but from what they said on the website you'd expect it was in the latest release (9.1,) not the unstable testing tree. As long as it stays there and doesn't make it into an official release the license difference is probably moot, since slack-current is certainly not advertised. Anyway good catch spotting it.
Sorry, I know it's screwey to reply to yourself, but looking over their website some more they look to be even deeper in denial than I thought over this, and I don't see any better place to post this than here.
4.4.0 now Stable
After tremendous testing and community feedback, the 4.4.0 Release is now available for twenty (yep that's the number 20!) popular platforms. Distros that have integrated it are: NetBSD, Slackware Linux, Conectiva, and many others. See our distro support page for the full breakout.
But checking up on it, that doesn't seem to be true.
My Portugeuse is a bit rusty and I gave up trying to find what version Connectiva is shipping, but I found it astonishing that they would claim NetBSD and Slack are using 4.4 when they aren't. Is anyone shipping Xfree86 4.4?
What transpired was that the guy in charge of the XFree86 project changed the license to more of a BSD-ish license that requires advertising, etc.
Yes, they recently changed to something resembling the old BSD license, including an advertising clause, which makes it not compatible with the GPL. That's the licensing tiff. However this came after the original split between the groups, where some people walked away from the Xfree86 project because of other issues - problems getting changes commited, folks that hadn't developed in years still having developer status while folks that were major current contributors couldn't get it, and had to go through a huge rigamarole to get bug fixes posted and the like. So it was really the combination of the two different issues that brought the current situation about - the first group that split were fortuitously positioned to pick things up when the license change drove the second group to leave and the Linux Distro-makers decided they didn't want anything to do with the new Xfree86.
This made the newly licensed version incompatible on a licensing level with any GPLed OS- you can use it, you just can't distribute the new version of XFree86 with a Linux distribution without the prospects of possible legal hassles, etc.
This isn't actually true. You can distribute non-free software on the same disk with free, that's not the problem at all.
The problem is that you can't link the code. If your GPL program needs to link against some of the new Xfree code, then you have a legal problem because of the licenses being incompatible. In most cases that's probably not necessary, but in the cases where it is it's a huge problem, and while shipping the new Xfree86 in a distro would not necessarily be a legal problem (particularly since the new license affects only the new code,) it would still be opening the door to huge problems later on, and that's why no one wants to touch the thing. Hopefully the fact that this license change has just dropped Xfree86 from being the defacto standard X11 implementation to being a historical footnote overnight will act as a warning to anyone else that might be considering the same course of action.
The Xfree86 project still seems to be in denial about this, btw, as a quick browse of their website will show, but the fact remains - no one is using their new version, no one will touch it with a ten foot pole, and their developers are hemmoraging like crazy.
FAT was originally designed in the 1980's, and although long filenames might've been considered, hardware limitations may have made them infeasible at the time. Also, FAT wasn't initially designed by Microsoft; the first version was released with QDOS.
Not actually true. FAT first appears in the Stand-alone Disk BASIC written by Marc McDonald for MicroSoft back about 1977. When Tim Patterson kludged together QDOS in 1980, he used FAT, but he didn't invent it, it had already been in use for around 3 years.
Nope, they expressly only asked for an injunction to prevent the company from continuing to distribute in violation of the license. If they wanted to cut them off at the knees, they could, but clearly that's not their intention.
This hasn't gone to a trial, and it doesn't look like it will. Sitecom almost immediately added a download that appears to bring them into compliance with the GPL to their Drivers and Manuals Page. Of course we'll have to wait for the copyright holders to look it over and decide whether it's legit or not before we can be certain...
The collision theory is extraordinarily unlikely, although of course in a sense possible. A few more likely scenarios strike me though.
But Brown predicted that a satellite would pop up as a companion "dot" in Hubble's precise view. The object is not there, though there is a very small chance it might have been behind Sedna or transiting in front of it, so that it could not be seen separately from Sedna itself in the Hubble images.
Remember that Sedna itself is so small the Hubble can't resolve it. So Sednas companion could be quite tiny and still large enough to affect it. If it has a very small companion with a very low reflectivity, would it be surprising if Hubble didn't pick it up immediately? I'm not an astronomer, and there may be something I'm missing, but that seems quite plausible to me.
It also seems possible that it was part of a binary system earlier and lost its companion, or that it's rotation rate was affected by one or more near misses out in the kuiper belt. We don't know the history of this object at all, we barely even know it exists. It is cool that an initial prediction seems to be a failure here, because that indicates a potential to learn new things, but at the same time it's hardly surprising given how small and far away the thing is and how difficult this makes it to detect and measure.
Slashdot Mirror
Thanks. It's rare to see someone actually follow through on a statement like that here on slashdot.
The problem the committees tried to solve with their new terminology is a real one, and I don't want to minimise that. Most people using computers these days don't even know what binary means, and as the powers go higher, the difference between the binary and the decimal interpretation increases. The potential for confusion is great. And if their terminology had been used from the start it would make sense. But the fact is it hasn't, we've got over 30 years of tradition using the binary terms, and for some committee to think they can simply redefine them by fiat is irritating to say the least. Given that the the usage is already well supported and entrenched, not to mention that the binary values are the natural groupings of bytes which make sense in the areas where they are used, I would propose instead of trying to redefine kilobyte as 1,000 bytes and make up a new term (kilo-binary-byte aka kibibyte) for what we already call a kilobyte, they should make up new terms for the less useful values instead (perhaps decimal-kilo-byte aka dekilobyte for 1,000 bytes.) As it is, their proposal is being mostly ignored, causing even more confusion than existed before they tried to remedy the situation, and about the only folks that seem to get anything good from it as far as I can see are the hard drive manufacturers, who get a handy excuse to continue inflating their drive capacity numbers.
Drive manufacturers have done that for years, ever since they started selling more drives to non-technical types than to geeks, just to inflate their numbers.
Communications devices, however, are a different matter - they're more the province of electrical engineers than computer scientists, and referring essentially to circuit cycle speed, so it makes perfect sense to use decimal there.
If you want an authority for this you don't need to look very hard, just hit the Jargon File.
quantifiers
In techspeak and jargon, the standard metric prefixes used in the SI (Système International) conventions for scientific measurement have dual uses. With units of time or things that come in powers of 10, such as money, they retain their usual meanings of multiplication by powers of 1000 = 10^3. But when used with bytes or other things that naturally come in powers of 2, they usually denote multiplication by powers of 1024 = 2^10.
Here are the SI magnifying prefixes, along with the corresponding binary interpretations in common use:
prefix decimal binary
kilo- 1000^1 1024^1 = 2^10 = 1,024
mega- 1000^2 1024^2 = 2^20 = 1,048,576
giga- 1000^3 1024^3 = 2^30 = 1,073,741,824
tera- 1000^4 1024^4 = 2^40 = 1,099,511,627,776
peta- 1000^5 1024^5 = 2^50 = 1,125,899,906,842,624
exa- 1000^6 1024^6 = 2^60 = 1,152,921,504,606,846,976
zetta- 1000^7 1024^7 = 2^70 = 1,180,591,620,717,411,303,424
yotta- 1000^8 1024^8 = 2^80 = 1,208,925,819,614,629,174,706,176
But that's exactly what your sources are doing - attempting to change the definitions after the fact. I've been using these units since 1980, and they were old when I started soldering computers together and programming them. It's only very recently that the confusion has arisen - primarily because the SI folks invented new units and rather than give them new names, attempted to coöpt the already existing and well established names for their new units, and give new names no one had ever heard of before for the old ones.
If people (that's you, adamofgreyskull) would stop propounding incorrect use of the language, those of us who quietly continue to use it correctly would... give you a pat on the back.
A byte is binary 1000 (that's 8 in decimal) bits. A kilobyte is binary 10000000000 (1024 in decimal) bytes. A megabyte is binary 10000000000 (again 1024 in decimal) kilobytes. A gigabyte is binary 10000000000 megabytes. Bits (Binary digITS) are counted in binary, not decimal. Surely a bright guy like you can figure this out?
Just because some idiotic idea got posted with a .gov address doesn't refute the posters point. They've just made up their own units, which by itself is actually fine by me, though in this case pointless - but their attempt to name these units with names already taken long ago for useful units is not.
Any real geek would know that bytes are counted in binary, not decimal, so your appeal will certainly fall on deaf ears. Excepting a few mentally challenged moderators, obviously.
This isn't informative, it's stupid.
And yes, I know all about the SI page you're going to link next. All would-be standards setting bodies should keep in mind the abject failure that group has had in it's attempt to redefine megabyte and gigabyte whenever they get the urge to indulge in similar stupidity themselves. Those terms not only sound stupid, more importantly they are completely unecessary and serve no purpose other than to confuse an area that was perfectly clear before. The SI folks, thankfully, have no power to enforce their stupid ideas, so geeks around the world can quite safely continue to give them the attention they deserve - none.
It could be coërsion, but only if it's a threat in the strict, not the loose sense - that is if there is a person threatening to somehow do this to you if you don't bend to his will - NOT if it's simply external circumstances in general.
I have a feeling we're actually a lot alike in that respect - certainly I didn't find working in corporate America any more congenial than you are finding it.
He got into it because it was in his name that the habit of speaking of people as being 'coërsed' by general circumstances, rather than by deliberate individual action, and particularly the attempts to confuse the one with the other in terms of legal and moral consequences, became widespread in the last century - no more, no less.
This would prove only that someone read the terms, not that s/he agreed to them, or that s/he was a person with authority to bind other users of the computer to them.
And even if it did, it still wouldn't be a valid contract, since there is no quid pro quo - the user gets no compensation under these agreements except the ability to use the software which is already bought and paid for - it's like if I sold you a car, then turned around and refused to deliver it until you signed a paper purporting to give me access to your wife and daughters perpetually. Nor is it a valid license, since it gives no permission to do anything that one can't legally do to begin with, but rather in fact purports to forbid many things that could be legally done without agreeing to it.
What it would accomplish would be to waste even more of the users time, and make the disdeign with which the software company involved treats their customers more obvious.
Of course, in a sane world, customers would be so offended by even this lame attempt to take away their rights without even token compensation, by blocking them from functionality they already purchased and holding it ransom for their 'agreement' that they would immediately boycott the company that produced such nonsense in the first place.
I agree, there is no way a EULA can be valid under contract law, although there are some factual errors in your post I should clear up. Oral contracts are just as valid as written ones. Of course, if there are no witnesses and the other party is willing to perjure him/herself, then you can have a problem, which is why signed papers are preferable. Notaries and witnesses are not required, they just (like having it on paper) make it easier to establish facts later if you have to sue to enforce it.
But EULAs lack any 'meeting of the minds', any compensation for the 'end user,' and any verification as to who the supposed 'end user' who clicks the accept button is, among other things. This is why they don't call themselves contracts, but rather 'licenses.' This dodge doesn't hold much water either, however.
Legally, you have no need for a 'license' to use the software you've already bought. (You would need a license to, for instance, create derivative works based on it, but not simply to use it.) So why on earth would anyone agree to one?
I've certainly never agreed to any such thing. I've occasionally pushed a button saying 'agree' or the like, simply because it's the only way to get software I own to perform it's function, but the act is certainly performed in those cases without any intent to actually agree to the 300 pages of legalese that I haven't even looked at. I daresay I'm probably a pretty mainstream computer user in that way. And I can't see how a court could possibly claim that this act somehow held any water as a legal agreement without ceasing entirely to be concerned or bound by legal traditions and principles and coming out in broad daylight as just a mouthpiece for the corporations and nothing more.
That's not duress. Unless of course you were put in that position by the credit card guys, through no fault of your own, then the point could be argued perhaps.
: wrongful and usu. unlawful compulsion (as threats of physical violence) that induces a person to act against his or her will: "coercion"
Your lack of due diligence or even genuine lack of opportunity doesn't allow you to claim duress, despite the Marxist habit of claiming otherwise.
Amazon Browser?
Quite cool, indeed. Damn, I may have to get the book now.
That's one of those areas of copyright law that there are different opinions on, but IIRC the opinion of the FSF counsel is a qualified no. The qualification being that if the code you're linking is sufficiently generalised that there are other libraries it could link to just as well then there's no question of 'derivative works' and so that would be ok (like it's ok to dynamically link your GPL code to a proprietary C library as long as the same code will work fine linked to Glibc instead) - but if your code is specific to the X code, so it can't function without it, then the licenses have to be compatible.
That wouldn't come up anyway, unless the XFree guys start applying the new license to the library code which it currently does not apply to. I don't think there's a short term practical problem here in terms of anything folks are doing at the moment being illegal because of the new license. But at the very least, it's a pain in the ass because now everyone has to run around involving the lawyers just to be sure of that fact where there was no question before.
There definately is a conflict with the GPL. You cannot add any conditions to the license, the GPL prevents that. So a license which imposes conditions above and beyond what the GPL requires are GPL incompatible - you cannot legally combine code under the GPL with code under this license. It's true that it's a relatively innocuous condition, and not a big deal in and of itself, but you still can't combine code with it under the GPL legally, and that's what the concern is.
Since they've stated they don't intend to place library code under this license (I think, although I can't seem to find a link to back that up) it doesn't seem like a huge deal, but considering all the problems with the XFree86 organisation lately, and the fact that there's a perfectly good GPL-compatible fork (which probably has more active developers already) there's just no reason not to avoid the potential problems of having a major part of your distribution GPL-incompatible unecessarily.
Hmm, so like slack, it's available in a development branch only. Hardly what I would have expected from the words "Distros that have integrated it."
Quite true (although if I'm not mistaken that's the case only because when confronted on the issue they tried to back down off the original plan to avoid trouble?) and the license change isn't that huge a deal for that reason IMOP. At the moment, it covers a miniscule amount of code in fact, but of course that amount of code will grow over time, if Xfree86 keeps putting out code at least. More than anything else it seems that the whole flap over this issue has been sort of a 'last straw' that's pushed the alternative projects to critical mass and discouraged distro makers from using Xfree86.
Heh, ok, but from what they said on the website you'd expect it was in the latest release (9.1,) not the unstable testing tree. As long as it stays there and doesn't make it into an official release the license difference is probably moot, since slack-current is certainly not advertised. Anyway good catch spotting it.
Sorry, I know it's screwey to reply to yourself, but looking over their website some more they look to be even deeper in denial than I thought over this, and I don't see any better place to post this than here.
The Xfree86 homepage proudly trumpts the following:
But checking up on it, that doesn't seem to be true.
NetBSD?
XFree86 upgraded to version 4.3.0 for those architectures which use XFree86 version 4.
SlackWare?
- XFree86 4.3.0
My Portugeuse is a bit rusty and I gave up trying to find what version Connectiva is shipping, but I found it astonishing that they would claim NetBSD and Slack are using 4.4 when they aren't. Is anyone shipping Xfree86 4.4?
Joke? Try troll. Look who wrote it.
Yes, they recently changed to something resembling the old BSD license, including an advertising clause, which makes it not compatible with the GPL. That's the licensing tiff. However this came after the original split between the groups, where some people walked away from the Xfree86 project because of other issues - problems getting changes commited, folks that hadn't developed in years still having developer status while folks that were major current contributors couldn't get it, and had to go through a huge rigamarole to get bug fixes posted and the like. So it was really the combination of the two different issues that brought the current situation about - the first group that split were fortuitously positioned to pick things up when the license change drove the second group to leave and the Linux Distro-makers decided they didn't want anything to do with the new Xfree86.
This isn't actually true. You can distribute non-free software on the same disk with free, that's not the problem at all.
The problem is that you can't link the code. If your GPL program needs to link against some of the new Xfree code, then you have a legal problem because of the licenses being incompatible. In most cases that's probably not necessary, but in the cases where it is it's a huge problem, and while shipping the new Xfree86 in a distro would not necessarily be a legal problem (particularly since the new license affects only the new code,) it would still be opening the door to huge problems later on, and that's why no one wants to touch the thing. Hopefully the fact that this license change has just dropped Xfree86 from being the defacto standard X11 implementation to being a historical footnote overnight will act as a warning to anyone else that might be considering the same course of action.
The Xfree86 project still seems to be in denial about this, btw, as a quick browse of their website will show, but the fact remains - no one is using their new version, no one will touch it with a ten foot pole, and their developers are hemmoraging like crazy.
Not actually true. FAT first appears in the Stand-alone Disk BASIC written by Marc McDonald for MicroSoft back about 1977. When Tim Patterson kludged together QDOS in 1980, he used FAT, but he didn't invent it, it had already been in use for around 3 years.
Nope, they expressly only asked for an injunction to prevent the company from continuing to distribute in violation of the license. If they wanted to cut them off at the knees, they could, but clearly that's not their intention.
This hasn't gone to a trial, and it doesn't look like it will. Sitecom almost immediately added a download that appears to bring them into compliance with the GPL to their Drivers and Manuals Page. Of course we'll have to wait for the copyright holders to look it over and decide whether it's legit or not before we can be certain...
*cough*GNUstep*cough*
The collision theory is extraordinarily unlikely, although of course in a sense possible. A few more likely scenarios strike me though.
Remember that Sedna itself is so small the Hubble can't resolve it. So Sednas companion could be quite tiny and still large enough to affect it. If it has a very small companion with a very low reflectivity, would it be surprising if Hubble didn't pick it up immediately? I'm not an astronomer, and there may be something I'm missing, but that seems quite plausible to me.
It also seems possible that it was part of a binary system earlier and lost its companion, or that it's rotation rate was affected by one or more near misses out in the kuiper belt. We don't know the history of this object at all, we barely even know it exists. It is cool that an initial prediction seems to be a failure here, because that indicates a potential to learn new things, but at the same time it's hardly surprising given how small and far away the thing is and how difficult this makes it to detect and measure.
Heh, if the law was privitised this sort of thing would go away. Think about it.