Thus, one could very easily implement a protocol that does everything you just described,
Yes, "one could". But my point is: "one hasn't". There are no standards, no device support, nothing, for using 802.11 that way.
Conversely, Bluetooth could also be used like 802.11, but it isn't. Its TCP/IP encapsulation is based on PPP, and that is quite deliberate: it fits Bluetooth's usage profile much better.
it's just that maybe it could easily die without all that much trouble, if one were to take the truly interesting bits and place them atop 802.11.
Yes, and you'd end up with something that's more expensive, more power hungry, and with not hardware support.
Few people know how to write cursive anymore. Even adults have mostly forgotten and write some kind of odd mix of cursive and printed. That didn't start with computers, it started with those "please print and write one letter per box" forms.
Cursive was never designed for the modern world anyway--it combines being hard to read with being slow to write. It was designed by artists for appearance. Think of it as 19th century web design. It's completely obsolete.
I understand, these two still lag a little behind the PocketPC in the technology stakes -- for example, no cursive handwriting recognition (?).
PocketPC doesn't use cursive handwriting either. In fact, both Linux PDA software and Linux PDA hardware is better than what you get for Palm or PocketPC (have a look at the Zaurus 700 Series: 640x480 screen, 8h battery life). There is also plenty of software for those devices, including drivers for just about any CF I/O card you might want. The one big mistake Sharp made was going with a proprietary window system rather than X11--that made their hardware much less attractive to many current Linux users and developers.
In terms of technology, Linux PDAs are ahead of PPC and Palm. Mainly what is missing is marketing, in particular in the US.
Those numbers don't mean much: the best-selling PDA was the Zire, at sub-$100 prices. That skews dollar-based market share numbers in favor of the more expensive PocketPC handhelds.
In any case, Palm still has a better UI and applications, while Pocket PC has a slightly better OS. But both are pretty awful. It's MacOS vs. Windows all over again. One company can't do operating systems to save their lives, and the other one does a uniformly mediocre job. Let's hope that Linux gives us a serious alternative for handhelds as well, because Palm and Microsoft are screwing it up.
I'd like to know if you've ever actually used the MS ink software
Yes. I don't comment on things I haven't used.
we use it here for interactive whiteboard we have, and the character regognition is stunning.
I'd agree it's "stunning", but not in a good sense.
I can scrawl something onto the board (never a particularly inspiring sight), and it will usually interpret it how I wanted it to - the times it didn't, you wouldn't fault a human for reading it wrong.
Unfortunately, the software hallucinates: it doesn't actually recognize things very well, it just takes the closest match out of a limited vocabulary. That makes it unusuable for most serious applications.
Apart from the failings of the recognition engine itself, even worse is when and how the ink recognizer gets invoked: it's inconsistent among applications, and you can't "just write" things. Try enabling the full screen ink mode--it's actually pretty funny in how bad it is.
This is the single biggest advantage that MS has over Linux in PDAs and tablets.
I think that amounts to saying that Tablet PC and PocketPC doesn't really have an advantage over Linux on PDAs and tablets, because that kind of software is essentially useless in practice.
People use character-at-a-time recognizers because they work better. If they are well-designed, character-at-a-time recognizers are even faster than regular handwriting. That's, ultimately, why Palm won out over Newton.
Character support is like Palm input. One character at a time. The "ink" is one word at a time, like you were actually writing notes.
That's exactly what I said. X11 has support for pen input, so you can build whatever recognizer you like. And there are several character recognizers available already, but no good word-level recognizers.
And to alot of people who are used to writing notes with a pen and paper, its a big difference.
It would be if Tablet PC's word-level recognizer and ink support was actually usable. It isn't. It's basically junk. Maybe they'll get it right in another couple of releases, but by then, you'll probably see good Linux alternatives already.
Until then, Linux and Tablet PC are about equal when it comes to ink: character-at-a-time and on-screen keyboard input is the only stuff that really works for entering text.
Don't be silly: Microsoft didn't invent any of this stuff either. Pen-based applications and handwriting recognition go back to the 1960's.
And even in the modern PC era, it's not exactly anything new. Journal is a descendent of Aha! InkWriter, something that Microsoft didn't develop but simply bought. And X11 has had pen input support years before Windows XP.
All Microsoft has contributed with Tablet PC to the world of pen computing is that they have finally created a market for the hardware. This means that, finally, open source developers have a good target to develop to.
To the degree that Linux/X11 pen applications will look like Microsoft Tablet PC, it's superficial, and mostly to make users feel more comfortable.
Well, first you get Linux to run on Tablet PC hardware, then you develop the ink software. This may take Microsoft years to do and billions of dollars, but I suspect it will take Linux developers a few months, provided anybody really cares.
But you can't really do anything important (system-config type stuff) without resorting to a CLI
Sure you can. You can use Webmin for a web-based GUI, and it lets you administer pretty much everything on a Debian system. As an added bonus, it works pretty much the same way with several other Linux and UNIX flavors.
(There are a number of other GUI-based configuration tools for Linux as well.)
Can someone out there create a linux-equivalent to the ink applications for TabletPC?
Yes. In fact, a lot of software already exists. X11 has been used for more than a decade with tablets (Wacom, etc.), so all the pen input and character recognizer support is there. Furthermore, Gtk+ and a few other toolkits have low-level support for pen input.
In addition, the Linux-based handhelds already use pen input, so there is experience with, and support for, Linux and X11-based pen-based applications, although those are, of course, for small-screen devices.
For instance, the Journal is super cool. It lets you make notes in ink (or by text), it can translate, etc. Most importantly, you can/search/ using ink.
I have tried using Journal for taking notes. It makes for a slick demo, but ultimately, I find a keyboard (even a one-handed keyboard) more efficient. Note that few of the features in Journal are novel--similar software has been around for decades.
Note: the Ink interface is/not/ the same as a mouse interface.
You should tell that to Microsoft: most of the software running on Tablet PC has been very poorly adapted to a pen interface and feels like it's been written for a mouse.
I have a couple of Tablet PCs. The handwriting recognition that comes with Tablet PC is largely useless. Furthermore, ink handling is poorly integrated into the OS.
That means that when you use a Tablet PC, you are reduced to using the PocketPC character recognizer or the on-screen keyboard. And for that, Linux has equivalents that are as good or better (xscribble and xvkdb).
So far, there hasn't been much demand for connected handwriting recognition for Linux, or for ink software, because there haven't been many tablets. Now that tablets are fairly affordable, thanks to Microsoft, that is likely going to change. Open source operates in response to supply and demand; it's not usually first, but it usually fills the needs of users.
There is another big disadvantage of 802.11: just about any use of it is based on networking protocols, foremost TCP/IP. Networks are a pain to configure, and 802.1x, which you need for 802.11 security, is making things even worse.
Bluetooth, on the other hand, creates virtual serial connections by pairing devices. Pairing is a process normal human beings understand: put the devices next to one another, push a button, maybe enter the same code into both, and it works. Alternatively, Bluetooth devices can also discover each other and talk in an untrusted mode. And all those things work in any combination, something that would make your head spin if you tried it with network-based abstractions.
Maybe ZeroConf will eventually help make 802.11 usable, but so far, there is just no comparison: 802.11 requires the skills of a network administrator, while Bluetooth is usable for regular people.
Bluetooth is widely used outside the US. And it works well for applications beyond headsets, like synchronizing PDAs and desktops, mobile web access from your PDA, and wireless printing. Bluetooth is far more secure for things like wireless keyboards and will probably take over in that area.
Bluetooth is easier to configure and administer than 802.11a/b/g--people can just do it themselves. And Bluetooth has much better battery life and smaller antennas.
I don't understand the reluctance of US cell phone carriers to offer Bluetooth-capable phones--they are not significantly more expensive than equivalent non-Bluetooth phones. I sometimes think that they don't offer it because they want to control how you access the Internet through their networks. With Bluetooth, you can easily and comfortably use your laptop or PDA, and your own software, to access the Internet through your cell phone. IR and wired, OTOH, iareso cumbersome that most people don't bother, if they are even available.
Look for Bluetooth for your next cell phone and PDA. Consider getting a Bluetooth access point for better battery life from your PDA and laptop. Bluetooth isn't expensive and it's pretty nice.
Note that there are long-range versions of Bluetooth (300ft) and that there are high-speed versions in development.
no-one is liable beyond the point at which SCO could have provided them with information to correct the matter.
SCO will take the position that they have provided everybody with the information to correct the matter: "Linux" is infringing, therefore you should stop using Linux.
They are approaching this like they would approach copyright and contractual violations by a single big company like, say, Sun. For a lawsuit against a company like that, their behavior makes sense: the entire product would be at risk, violations would be determined by a third party expert under NDA, etc.
What they are missing is that Linux is not like Solaris. Linux is a loose aggregation of independently developed pieces of software. Even if SCO succeeds in making claims against parts, it would have negligible impact on the whole.
Basically, SCO's legal strategy is as outdated as their software.
It would be pretty pointless to change the code overnight.
It wouldn't be "pointless" at all. The goal is not to hide past infringement, it is to avoid future infringement. It would mean that Linux users could use the next release of the kernel without worrying about future violations of SCO's copyrights or patents.
If the code is there, it will be found.
Nobody is trying to hide anything. People would still be liable for past violations, but they would be liable for that anyway.
If you unknowingly violate someone's copyright and you take quick steps to fix it, you are probably going to get off easily. SCO is trying to create a situation where they are informing everybody that they are violating their copyright but not permitting them to fix it (other than by buying SCO's software), and that's just sleazy. It probably won't fly either. Once the source files are identified, they will get rewritten from scratch, and their claims will be history.
That maybe SCO are telling the truth - that maybe there is ripped off code? Undoubtedly if the claim was that MS had included GNU code in their apps, people would automatically presume guilt;
Yes, and they would be right: we can look at the GNU code, we can trace its history, and therefore we can determine whether inclusion of it in Windows constitutes a copyright violation.
why the immediate defensiveness now?
Because SCO hasn't shown anything. For all we know, both Linux and SCO might have copied the code from BSD or other public sources.
Furthermore, SCO seems to want more than they are due: they seem to want to control entire Linux distributions, code developed by thousands of independent contributors, while their alleged copyright violation is limited to at most a few chunks of code.
If SCO came clear on what the offending source files are (they don't even have to give us their code, they just need to point out the source files and we could probably rewrite the entire files from scratch), the Linux community could fix this before anything even went to trial. They could still go around trying to sue individual users for past copyright violations, but that wouldn't give them much.
But they don't tell us what the problem is because they think they are going to extort money out of the entire Linux community in perpetuity. It's not going to work, no matter what copyright violation may or may not have occurred.
Even if the analysts are correct, the most likely cause of this is that both projects copied code out of BSD or some other public domain source. Without some definitive proof that SCO actually holds the copyright on the code in question, detection of copied code is worthless.
We don't want Linksys's proprietary code, we simply want them to comply with the license, whatever that entails. That means, among other things, identifying to their customers exactly which GPL'ed code they are using in their product and providing that software. What that compliance is good for is a secondary question.
I think that just knowing that the thing is running Linux would be useful for me because I might install additional servers on it (better DNS, for example).
But it's also a PR thing for Linux: if it were widely known that every Linksys and every Belking router is running embedded Linux, more companies might end up using Linux themselves.
You are assuming that a challenge to GPL'ed code involves an attack on the GPL license. I don't think that's likely to be the case.
A company could (and probably) would challenge the copyright. They might argue that the GPL'ed code has effectively become public domain, and hence it doesn't matter what the license says. Or, they might argue that the code that there are no damages, and that therefore they aren't liable for more than zero dollars (i.e., nothing) even if they have technically violated copyright law.
If they aren't violating the terms of the GPL, then it should be possible to replace the GPL'ed versions of the software with recompiled versions and obtain a running system. That would be quite interesting because it would still allow us to add features and fix bugs in the GPL'ed portions of the code.
First, as someone else already said, just becuase it uses a linux kernel doesn't mean they modified anything, it could be a stock kernel. If they wrote userspace drivers and/or kernel modules using existing interfaces for their custom hardware, they are not obligated to release anything.
Regardless of whether it is a stock kernel or not, they are obligated to identify the fact that they are using GPL'ed code and make an offer to buyers to give them the source code. That is a key requirement of the GPL. I have bought several Linksys APs, and I assure you I have not received such information or an offer.
but the fact is: If you don't accept the GPL as valid, then copyright law still stands, and says you can't redistribute, or make derivitive works.
Yes, but the argument against the GPL is likely to involve an argument against the copyright (or both the copyright and the license). One day, a company like Linksys is going to try to make an argument that GPL'ed software is, effectively, public domain and does not enjoy copyright protection. Or, they are going to argue that there technically is a copyright violation but that the commercial value of the software is $0 and that therefore the penalty for their copyright violation should be $0 as well (even with "triple damages").
Probably their best way out is either get the NDAs released [unlikely], or find out the individual authors of their modules, and work out individual licensing agreements [difficult, but possible] that keep it outside the GPL.
It's too late for that: whether they do or do not release the source code at this point, they have already lost their right to release the binary. And their GPL violation is not that they haven't put up the source code for FTP somewhere, the GPL violation is that they didn't identify the product as using GPL'ed code in the first place, accompanied by an offer to make the source code available.
That said, I have to think about SCO, and think that one shouldn't take a "All your codebase are belong to us" approach. My feeling is that trying to knock others out to get what you want, is kindof evil. And that goes in both directions.
If someone has violated SCO's copyright in the way they claim, they should be punished severely: copyright violations like those claimed by SCO threaten not only companies, they threaten the very existence of open source software. (However, I believe that SCO's claims are bogus, so I don't see much danger of that happening.)
Likewise, if Linksys has violated the terms of the GPL, they should be punished severely. Linksys's behavior, shipping GPL'ed code without identifying it as such, is a fundamental violation of the GPL, and if the only consequence is that companies have their wrists slapped when found out (and it has taken years to find this out about Linksys), it undermines the whole idea of the GPL.
I was filling in grad school applications a couple of years back, many of them were editable PDFs.
Editable PDFs are not round-trip. Neither are RTFs. Both lose information.
The way MS Office works is that a saved document is simply a persisted COM object, the object that represents the document in memory. That's why it keeps changing, because the functionality and hence internal structure of that class changes with every new release.
Yes, Microsoft has discovered that bad software engineering and format lock-in go hand-in-hand. That doesn't mean either is desirable or defensible.
I doubt MS has someone whose job it is to obfuscate things
Of course they don't. They probably don't even have a software engineer that knows how bad their software engineering is. Why should they bother? They are making billions of dollars with the status quo. Given Microsoft's market position, the worse their software engineering, the more money they make, at least up to a point.
Why are there tools like wv on my SGI machine to read.doc files?
Because a lot of people are working very hard reverse engineering Microsoft's formats. Unfortunately, wv doesn't work very well.
That screeching sound is the sound of the Microsoft FUD machine, lobbying machinery, and PR machinery kicking into high gear. Expect another concerted effort by Microsoft trying to discredit Linux, effectively bribe government officials, and "give away" Windows for free.
Slashdot Mirror
Thus, one could very easily implement a protocol that does everything you just described,
Yes, "one could". But my point is: "one hasn't". There are no standards, no device support, nothing, for using 802.11 that way.
Conversely, Bluetooth could also be used like 802.11, but it isn't. Its TCP/IP encapsulation is based on PPP, and that is quite deliberate: it fits Bluetooth's usage profile much better.
it's just that maybe it could easily die without all that much trouble, if one were to take the truly interesting bits and place them atop 802.11.
Yes, and you'd end up with something that's more expensive, more power hungry, and with not hardware support.
Few people know how to write cursive anymore. Even adults have mostly forgotten and write some kind of odd mix of cursive and printed. That didn't start with computers, it started with those "please print and write one letter per box" forms.
Cursive was never designed for the modern world anyway--it combines being hard to read with being slow to write. It was designed by artists for appearance. Think of it as 19th century web design. It's completely obsolete.
I understand, these two still lag a little behind the PocketPC in the technology stakes -- for example, no cursive handwriting recognition (?).
PocketPC doesn't use cursive handwriting either. In fact, both Linux PDA software and Linux PDA hardware is better than what you get for Palm or PocketPC (have a look at the Zaurus 700 Series: 640x480 screen, 8h battery life). There is also plenty of software for those devices, including drivers for just about any CF I/O card you might want. The one big mistake Sharp made was going with a proprietary window system rather than X11--that made their hardware much less attractive to many current Linux users and developers.
In terms of technology, Linux PDAs are ahead of PPC and Palm. Mainly what is missing is marketing, in particular in the US.
Those numbers don't mean much: the best-selling PDA was the Zire, at sub-$100 prices. That skews dollar-based market share numbers in favor of the more expensive PocketPC handhelds.
In any case, Palm still has a better UI and applications, while Pocket PC has a slightly better OS. But both are pretty awful. It's MacOS vs. Windows all over again. One company can't do operating systems to save their lives, and the other one does a uniformly mediocre job. Let's hope that Linux gives us a serious alternative for handhelds as well, because Palm and Microsoft are screwing it up.
I'd like to know if you've ever actually used the MS ink software
Yes. I don't comment on things I haven't used.
we use it here for interactive whiteboard we have, and the character regognition is stunning.
I'd agree it's "stunning", but not in a good sense.
I can scrawl something onto the board (never a particularly inspiring sight), and it will usually interpret it how I wanted it to - the times it didn't, you wouldn't fault a human for reading it wrong.
Unfortunately, the software hallucinates: it doesn't actually recognize things very well, it just takes the closest match out of a limited vocabulary. That makes it unusuable for most serious applications.
Apart from the failings of the recognition engine itself, even worse is when and how the ink recognizer gets invoked: it's inconsistent among applications, and you can't "just write" things. Try enabling the full screen ink mode--it's actually pretty funny in how bad it is.
This is the single biggest advantage that MS has over Linux in PDAs and tablets.
I think that amounts to saying that Tablet PC and PocketPC doesn't really have an advantage over Linux on PDAs and tablets, because that kind of software is essentially useless in practice.
People use character-at-a-time recognizers because they work better. If they are well-designed, character-at-a-time recognizers are even faster than regular handwriting. That's, ultimately, why Palm won out over Newton.
Character support is like Palm input. One character at a time. The "ink" is one word at a time, like you were actually writing notes.
That's exactly what I said. X11 has support for pen input, so you can build whatever recognizer you like. And there are several character recognizers available already, but no good word-level recognizers.
And to alot of people who are used to writing notes with a pen and paper, its a big difference.
It would be if Tablet PC's word-level recognizer and ink support was actually usable. It isn't. It's basically junk. Maybe they'll get it right in another couple of releases, but by then, you'll probably see good Linux alternatives already.
Until then, Linux and Tablet PC are about equal when it comes to ink: character-at-a-time and on-screen keyboard input is the only stuff that really works for entering text.
Don't be silly: Microsoft didn't invent any of this stuff either. Pen-based applications and handwriting recognition go back to the 1960's.
And even in the modern PC era, it's not exactly anything new. Journal is a descendent of Aha! InkWriter, something that Microsoft didn't develop but simply bought. And X11 has had pen input support years before Windows XP.
All Microsoft has contributed with Tablet PC to the world of pen computing is that they have finally created a market for the hardware. This means that, finally, open source developers have a good target to develop to.
To the degree that Linux/X11 pen applications will look like Microsoft Tablet PC, it's superficial, and mostly to make users feel more comfortable.
Well, first you get Linux to run on Tablet PC hardware, then you develop the ink software. This may take Microsoft years to do and billions of dollars, but I suspect it will take Linux developers a few months, provided anybody really cares.
But you can't really do anything important (system-config type stuff) without resorting to a CLI
Sure you can. You can use Webmin for a web-based GUI, and it lets you administer pretty much everything on a Debian system. As an added bonus, it works pretty much the same way with several other Linux and UNIX flavors.
(There are a number of other GUI-based configuration tools for Linux as well.)
Can someone out there create a linux-equivalent to the ink applications for TabletPC?
/search/ using ink.
/not/ the same as a mouse interface.
Yes. In fact, a lot of software already exists. X11 has been used for more than a decade with tablets (Wacom, etc.), so all the pen input and character recognizer support is there. Furthermore, Gtk+ and a few other toolkits have low-level support for pen input.
In addition, the Linux-based handhelds already use pen input, so there is experience with, and support for, Linux and X11-based pen-based applications, although those are, of course, for small-screen devices.
For instance, the Journal is super cool. It lets you make notes in ink (or by text), it can translate, etc. Most importantly, you can
I have tried using Journal for taking notes. It makes for a slick demo, but ultimately, I find a keyboard (even a one-handed keyboard) more efficient. Note that few of the features in Journal are novel--similar software has been around for decades.
Note: the Ink interface is
You should tell that to Microsoft: most of the software running on Tablet PC has been very poorly adapted to a pen interface and feels like it's been written for a mouse.
I have a couple of Tablet PCs. The handwriting recognition that comes with Tablet PC is largely useless. Furthermore, ink handling is poorly integrated into the OS.
That means that when you use a Tablet PC, you are reduced to using the PocketPC character recognizer or the on-screen keyboard. And for that, Linux has equivalents that are as good or better (xscribble and xvkdb).
So far, there hasn't been much demand for connected handwriting recognition for Linux, or for ink software, because there haven't been many tablets. Now that tablets are fairly affordable, thanks to Microsoft, that is likely going to change. Open source operates in response to supply and demand; it's not usually first, but it usually fills the needs of users.
There is another big disadvantage of 802.11: just about any use of it is based on networking protocols, foremost TCP/IP. Networks are a pain to configure, and 802.1x, which you need for 802.11 security, is making things even worse.
Bluetooth, on the other hand, creates virtual serial connections by pairing devices. Pairing is a process normal human beings understand: put the devices next to one another, push a button, maybe enter the same code into both, and it works. Alternatively, Bluetooth devices can also discover each other and talk in an untrusted mode. And all those things work in any combination, something that would make your head spin if you tried it with network-based abstractions.
Maybe ZeroConf will eventually help make 802.11 usable, but so far, there is just no comparison: 802.11 requires the skills of a network administrator, while Bluetooth is usable for regular people.
Bluetooth is widely used outside the US. And it works well for applications beyond headsets, like synchronizing PDAs and desktops, mobile web access from your PDA, and wireless printing. Bluetooth is far more secure for things like wireless keyboards and will probably take over in that area.
Bluetooth is easier to configure and administer than 802.11a/b/g--people can just do it themselves. And Bluetooth has much better battery life and smaller antennas.
I don't understand the reluctance of US cell phone carriers to offer Bluetooth-capable phones--they are not significantly more expensive than equivalent non-Bluetooth phones. I sometimes think that they don't offer it because they want to control how you access the Internet through their networks. With Bluetooth, you can easily and comfortably use your laptop or PDA, and your own software, to access the Internet through your cell phone. IR and wired, OTOH, iareso cumbersome that most people don't bother, if they are even available.
Look for Bluetooth for your next cell phone and PDA. Consider getting a Bluetooth access point for better battery life from your PDA and laptop. Bluetooth isn't expensive and it's pretty nice.
Note that there are long-range versions of Bluetooth (300ft) and that there are high-speed versions in development.
no-one is liable beyond the point at which SCO could have provided them with information to correct the matter.
SCO will take the position that they have provided everybody with the information to correct the matter: "Linux" is infringing, therefore you should stop using Linux.
They are approaching this like they would approach copyright and contractual violations by a single big company like, say, Sun. For a lawsuit against a company like that, their behavior makes sense: the entire product would be at risk, violations would be determined by a third party expert under NDA, etc.
What they are missing is that Linux is not like Solaris. Linux is a loose aggregation of independently developed pieces of software. Even if SCO succeeds in making claims against parts, it would have negligible impact on the whole.
Basically, SCO's legal strategy is as outdated as their software.
It would be pretty pointless to change the code overnight.
It wouldn't be "pointless" at all. The goal is not to hide past infringement, it is to avoid future infringement. It would mean that Linux users could use the next release of the kernel without worrying about future violations of SCO's copyrights or patents.
If the code is there, it will be found.
Nobody is trying to hide anything. People would still be liable for past violations, but they would be liable for that anyway.
If you unknowingly violate someone's copyright and you take quick steps to fix it, you are probably going to get off easily. SCO is trying to create a situation where they are informing everybody that they are violating their copyright but not permitting them to fix it (other than by buying SCO's software), and that's just sleazy. It probably won't fly either. Once the source files are identified, they will get rewritten from scratch, and their claims will be history.
That maybe SCO are telling the truth - that maybe there is ripped off code? Undoubtedly if the claim was that MS had included GNU code in their apps, people would automatically presume guilt;
Yes, and they would be right: we can look at the GNU code, we can trace its history, and therefore we can determine whether inclusion of it in Windows constitutes a copyright violation.
why the immediate defensiveness now?
Because SCO hasn't shown anything. For all we know, both Linux and SCO might have copied the code from BSD or other public sources.
Furthermore, SCO seems to want more than they are due: they seem to want to control entire Linux distributions, code developed by thousands of independent contributors, while their alleged copyright violation is limited to at most a few chunks of code.
If SCO came clear on what the offending source files are (they don't even have to give us their code, they just need to point out the source files and we could probably rewrite the entire files from scratch), the Linux community could fix this before anything even went to trial. They could still go around trying to sue individual users for past copyright violations, but that wouldn't give them much.
But they don't tell us what the problem is because they think they are going to extort money out of the entire Linux community in perpetuity. It's not going to work, no matter what copyright violation may or may not have occurred.
Even if the analysts are correct, the most likely cause of this is that both projects copied code out of BSD or some other public domain source. Without some definitive proof that SCO actually holds the copyright on the code in question, detection of copied code is worthless.
We don't want Linksys's proprietary code, we simply want them to comply with the license, whatever that entails. That means, among other things, identifying to their customers exactly which GPL'ed code they are using in their product and providing that software. What that compliance is good for is a secondary question.
I think that just knowing that the thing is running Linux would be useful for me because I might install additional servers on it (better DNS, for example).
But it's also a PR thing for Linux: if it were widely known that every Linksys and every Belking router is running embedded Linux, more companies might end up using Linux themselves.
You are assuming that a challenge to GPL'ed code involves an attack on the GPL license. I don't think that's likely to be the case.
A company could (and probably) would challenge the copyright. They might argue that the GPL'ed code has effectively become public domain, and hence it doesn't matter what the license says. Or, they might argue that the code that there are no damages, and that therefore they aren't liable for more than zero dollars (i.e., nothing) even if they have technically violated copyright law.
If they aren't violating the terms of the GPL, then it should be possible to replace the GPL'ed versions of the software with recompiled versions and obtain a running system. That would be quite interesting because it would still allow us to add features and fix bugs in the GPL'ed portions of the code.
First, as someone else already said, just becuase it uses a linux kernel doesn't mean they modified anything, it could be a stock kernel. If they wrote userspace drivers and/or kernel modules using existing interfaces for their custom hardware, they are not obligated to release anything.
Regardless of whether it is a stock kernel or not, they are obligated to identify the fact that they are using GPL'ed code and make an offer to buyers to give them the source code. That is a key requirement of the GPL. I have bought several Linksys APs, and I assure you I have not received such information or an offer.
but the fact is: If you don't accept the GPL as valid, then copyright law still stands, and says you can't redistribute, or make derivitive works.
Yes, but the argument against the GPL is likely to involve an argument against the copyright (or both the copyright and the license). One day, a company like Linksys is going to try to make an argument that GPL'ed software is, effectively, public domain and does not enjoy copyright protection. Or, they are going to argue that there technically is a copyright violation but that the commercial value of the software is $0 and that therefore the penalty for their copyright violation should be $0 as well (even with "triple damages").
Probably their best way out is either get the NDAs released [unlikely], or find out the individual authors of their modules, and work out individual licensing agreements [difficult, but possible] that keep it outside the GPL.
It's too late for that: whether they do or do not release the source code at this point, they have already lost their right to release the binary. And their GPL violation is not that they haven't put up the source code for FTP somewhere, the GPL violation is that they didn't identify the product as using GPL'ed code in the first place, accompanied by an offer to make the source code available.
That said, I have to think about SCO, and think that one shouldn't take a "All your codebase are belong to us" approach. My feeling is that trying to knock others out to get what you want, is kindof evil. And that goes in both directions.
If someone has violated SCO's copyright in the way they claim, they should be punished severely: copyright violations like those claimed by SCO threaten not only companies, they threaten the very existence of open source software. (However, I believe that SCO's claims are bogus, so I don't see much danger of that happening.)
Likewise, if Linksys has violated the terms of the GPL, they should be punished severely. Linksys's behavior, shipping GPL'ed code without identifying it as such, is a fundamental violation of the GPL, and if the only consequence is that companies have their wrists slapped when found out (and it has taken years to find this out about Linksys), it undermines the whole idea of the GPL.
I was filling in grad school applications a couple of years back, many of them were editable PDFs.
.doc files?
Editable PDFs are not round-trip. Neither are RTFs. Both lose information.
The way MS Office works is that a saved document is simply a persisted COM object, the object that represents the document in memory. That's why it keeps changing, because the functionality and hence internal structure of that class changes with every new release.
Yes, Microsoft has discovered that bad software engineering and format lock-in go hand-in-hand. That doesn't mean either is desirable or defensible.
I doubt MS has someone whose job it is to obfuscate things
Of course they don't. They probably don't even have a software engineer that knows how bad their software engineering is. Why should they bother? They are making billions of dollars with the status quo. Given Microsoft's market position, the worse their software engineering, the more money they make, at least up to a point.
Why are there tools like wv on my SGI machine to read
Because a lot of people are working very hard reverse engineering Microsoft's formats. Unfortunately, wv doesn't work very well.
That screeching sound is the sound of the Microsoft FUD machine, lobbying machinery, and PR machinery kicking into high gear. Expect another concerted effort by Microsoft trying to discredit Linux, effectively bribe government officials, and "give away" Windows for free.