The Real Reason For Microsoft's TomTom Lawsuit
Glyn Moody writes "We now know that Microsoft's lawsuit isn't just against TomTom, but against Linux too: but what exactly is Microsoft hoping to achieve? Samba's Jeremy Allison has a fascinating theory: 'What people are missing about this is the either/or choice that Microsoft is giving Tom Tom. It isn't a case of cross-license and everything is ok. If Tom Tom or any other company cross licenses patents then by section 7 of GPLv2 (for the Linux kernel) they lose the rights to redistribute the kernel *at all*. Make no mistake, this is intended to force Tom Tom to violate the GPL, or change to Microsoft embedded software.' Maybe embedded Linux is starting to get too popular."
You lose all rights to DISTRIBUTE that code. You can still use that code in perpetuity, though.
"If we let things terrify us, life will not be worth living."
- Seneca
Actually, the GPL forbids restricting other people's freedom.
It is, and should be, a GPL violation to secretly get a patent license. If TomTom were to cave to MS without getting slapped with a GPL violation, then anyone who uses tomtom's work would be opening themselves up to patent infringement suits.
Please RTFM and actually read the GPL. A good grep would be "they do not excuse you". Search the GPL for that text and you'll zero in on what I think is a very critical "failsafe" in the GPL.
You seem to have a misunderstanding of what the GPL is. It is a method of payment. TomTom using GPL'd software must abide by the payment method. That is, by providing the source for use or change by the people who they are selling to. Instead of dealing with dollars they deal with IP.
The problem at hand is that MS feels that TomTom should be paying for their patents, which would violate the GPL payment method.
You should be marked troll as you are obviously trolling for this response.
Gates (and Allen) developed MBASIC, and DISK BASIC. DISK BASIC used the "FAT" system to control free space.
CP/M did NOT use the same scheme. Instead, CP/M built up free space maps by scanning the directory. It also did not use a linked list. Personally, I thought FAT was weak then, and still is....
But the "industry" adopted it. It was allowed; we had a (at least) minimal common system for file systems. Enhanced to support directories and sub-directories.
Then, Microsoft designed a long filename system on top of it, that was back-compatible with the old method. THAT was patented. And, no, it wasn't even the "obvious" solution -- that would have been a mapping file.
What does this mean? It means that the long filename code SHOULD be ripped out. 8.3, baby! You want longname mapping? Linux has UMSDOS on top of FAT -- same result, no patent violation. Or, just use short names. Or, build a program that reindexes MS FAT longnames into UMSDOS (for read compatibility). Just don't write that format. It can be argued (I would try) that ANY longnames in MS FAT format that were found on a FAT filesystem then MUST have come from an MS patent licensee (because our proposed system wouldn't generate the MS FAT longname format). So, there are solutions. Maybe UMSDOS is too "crufty" to be resurrected, but it strikes me that something like posixovl.fuse could be used (with modifications).
Microsoft was creative with the MS FAT longname solution. Either deal with it, or get the patent overturned.
Just another "Cubible(sic) Joe" 2 17 3061
one of the worst configuration file formats ever
Wrong.
I hold up for example: XML, the Windows Registry, and sendmail.cf
Just another "DOJ fascist authoritarian totalitarian bootlicker" -- Zeio
I don't know why companies just don't get *BSD working for them instead Linux. It would save them a lot of headaches.
Maybe because companies like Microsoft have a history of stealing BSD code, making minor changes, and then patenting their implementation. This is why Ted Tso' said he would use the GPL for Kerberos instead of the BSD license if he had it to do over again.
sendmail.cf
Gah! Noooooo!
You have invoked the name of ultimate evil, dooming us all!
You should edit sendmail.mc (evil light) instead and process it with m4.
Nothing could be more intuitive.
I don't know why companies just don't get *BSD working for them instead Linux. It would save them a lot of headaches.
Because the primary reason for the success of Linux is that it forces everyone to share their improvements. You get an exponential return on investment. The best you can ever hope for with BSD is an incremental return.
The primary reason for success of Linux is a combination of timing and luck. When the BSD project's viability was in serious question due to the AT&T lawsuit, Linux hit its stride.
Moreover, your response demonstrates a common fallacy: the idea that, if not forced to share improvements, companies will not do so.
The reality -- as usual -- is much more complex:
I would argue that Linux has succeeded *in spite of* the GPL. Speaking with those in the embedded hardware industry, it's clear that Linux has a foothold because of its brand name, not because of significant technical differentiation. Many embedded hardware vendors -- even the major ones -- don't even understand the implications of the GPL! (see the Linksys GPL violations)
If you observe the BSD projects, you'll note that features, bug fixes, and developer time is often provided by corporations that leverage the BSD licensed code in otherwise closed source products.
To quote Juniper's VP of Foundation Technologies, Naren Prabhu:
Juniper benefits from the powerful collaboration between leading universities, individuals, and commercial organizations developing FreeBSD to advance the operating system functionality. The FreeBSD release system provides Juniper with a roadmap for features and a stable base for our code, while its practical licensing enables Juniper to develop intellectual property for advancing high-performance networking. Juniper employs many active FreeBSD developers that continually contribute to the FreeBSD project to further its development as a leading operating system.
I wouldn't be so quick to point to the GPL as a recipe for success. When you force individuals to choose between your way or the highway, many of them will choose the highway. The BSD project's more pragmatic stance has allowed corporations to contribute as they are able to do so, and has resulted in an extremely productive, ongoing relationship with commercial software vendors.
UDF is an ISO/IEC standard, so the format itself is not patent encumbered.
Um, that doesn't mean it's not patent encumbered. MP3 is patent-encumbered all to hell, and it's an ISO/IEC standard.