It's *NOT* over : now we have the MS patents FUD
on
SCO Loses
·
· Score: 2, Informative
So, do you really think that the FUD campaign to bring legal uncertainty upon Linux is now over ? Think about it twice.
Microsoft (which has good lawyers, and was probably able to predict this SCO judgment) just alleged the "235 Microsoft owned patents' Linux infringement" just some month ago ! Coincidence ? Anyway we're still in the same situation as before (but without the SCO "proxy"): Linux (and it's users) are still tainted by muddled intellectual property claims, and is therefore victim of (bogus, but still) legal uncertainty.
Coincidence ? Novell was the one large linux actor to buy Microsoft "virtual 235 infringed patents" licenses: now no one but Novell can claim IP virginity (having Unix property and MS "alleged patents" licenses) without FUD threat when using Linux, and can now, thanks to this judgment and they licenses with Microsoft, racket Linux users. No wonder why they're pushing so hard for MS technologies (Mono/C#, exchange-compatible server,...) on the Linux desktop.
One should note that, un like H.264, AAC is heavily patented.
So, to stay on topic (unencumbered high-quality AV technologies) one may prefer use H.264 with Vorbis audio and Matroska container.
Such kernels developers feedback are very precious and insightful for us,
customers. It's not only a matter of freedom an principles, it's about quality.
Be sure that - whatever the OS you use, being Linux, OpenBSD or FreeBSD -,
when a vendor behaves that bad and is so reluctant in providing open access to
documentation, you won't have a good driver nor a good support.
Those vendors behaviours are usually symptoms of a "closed" attitude, secrecy centerd, so even
when we accept NDA, we can't expect them to disclose the whole needed
informations (like, say, all firmwares versions bugs that needs a
workaround in drivers level, know bad behaviour of their chipsets etc).
This
attitude will also discourage some knowledgeable developers to help to improve the
driver, to fix bugs etc. Requiring NDA will prevent OSS kernel
developers to share sensitive informations regarding their experience with the
device (between OS, and even sometime inside the same kernel dev
team).
So for now, if you need a stable encryption accelerator device, consider
choosing an other vendor. Look out for Via C3, or SafeNet (and even some
Broadcom) chipsets: those vendors plays the game well, don't seat on their
customers (we) and the developers needs. They don't even hide behind a "U.S. export
laws restrictions" argument, and didn't faced trials, proving the
hypocrisy of HiFn assertions.
I fully agree, indeed the Linux developers are innocent there. By no means I was charging them: they are the one who actually write the free softwares !
And yes, commercializers are guilty ; but, to some extent, their user community have a responsability too: they (the users) had means to make commercializers/distros change their mind. They didn't, despite TdR and RMS calls for help.
That's why I'm talking about this here, I want this little slashdot post contribute to pass the message among free software users: we're responsible too. When needed, we should educate our software providers (aka commercializers aka distros), we should tell them that we expect them to play the rules fairly. They'll listen us, we're the user base, and after all, we're also their marketing & PR force.
But still, if the driver was developed under NDA and is bloated of "magic numbers" (as often in drivers under NDA, the implementation can't contain too much comment/infos), practicaly, we're near to loose one of the fundamentals rights supposedly granted by the GPL: the right to modify and re-use it. Well, you have this right, but you can hardly use it.
In practice, source code designed to hide IP secrets is in-between normal source code and binary exec. That's why, by the way, OpenBSD devs never accept and never signs NDA, as stated there
http://www.openbsd.org/goals.html for instance.
No, the problem he is talking about was not with Stallman.
In fact there were two differents campaigns goals, about two very different kinds of "blobs":
For obtaining the right to redistribute firmwares with the system. With recent wireless chipsets, the firmware is often loaded in the hardware at runtime, so it should be provided separetly (a scale economy compared to providing a flash memory onboard). So even BSD or MIT licences were acceptables here: the firmware is to be loaded and executed on the chipset, not in the main system memory nor in the kernel. It's not ideal, but we're used to accept this with eg. PC Bios, or any other drivers. I understand that it could be non orthodox for Stallman, but this is not the vital part of what Theo asked for (it was rather secondary).
For obtaining proper chipsets documentations and specifications so that any free OS can write his proper driver. And NOT a driver (mostly binary, but even free) from the vendor, nor specs under NDA. This was the crucial part.
But by no way the vendors provided any BSD drivers replacement for any blob (really, they don't care about OpenBSD). Some (Ralink, Atmel) agreed to redistribute the firmwares under MIT like licences anyway.
And from Theo words, Stallman was found very supportive on this work (but not the Linux distros makers & users).
The problem was with the second point, obtaining the hardware specs and not a binary "blob" driver. Theo de Raadt was replied by some vendors that (citing from memory) "you just have to sign our agreement and accept our binary blob drivers, look, many distributions (namely Mandriva, Ubuntu and Suse) agreed so it's an acceptable proposal, and you've no other choice". Theo was chocked by those replies, and chocked that only the FSF helped on his lobbying: the Linux distros makers wheren't supportive, rather the opposite, and the users of those distros didn't react to such a betrayal. It's somewhat similar to the recent Sun's Java redistribution licence for Linux (except that it's about kernel code, more sensitive).
If you're interested on this story, I can find propers links, but most of it was covered on www.kerneltrap.org and www.undeadly.org, so you'll easily find the full story.
>
Far too many people have a careless 'U.S.A. laws suck, merge it anyway' attitude
Sometimes, like at this point, it's the right attitude.
I second this. IP owner are kinda terrorists (presuring gvt agencies, senates, parliaments, etc), and succeed well in spreading fear.
There's lot of irrational going on this matter:
There's already drivers reverse engenered & implemented by the same person on the Linux kernel. Accepting this one would be consitent. What's so special with wireless ?
For mosts drivers, we don't know such details about the way it was implemented. The status quo up to now, for drivers writers is: you know that you must provide your own original implementations, we can't verify (eg. the code could be stolen from solaris, or anything) but we give you confidence, you're responsible. Why don't we credit the developers of RE drivers such a confidence, that they have done a pretty original and new implementation (that's arguably proovable on a court, then) ? that'd be consistent.
Linux users, developers, corporations and distributions come from all over the world (SUSE is German, Mandriva is French...). Linux don't try that hard to comply with zeale to all insane rules on all involved countries, but try to behave fair regarding intelectual property. So far, we weren't hurt (and for the precise case we discuse: OpenBSD didn't undergo lawsuits). It'd be consistent to adopt the same approach for the most stupid U.S. potentials but improbables risks.
There's many pathes where the kernel can be fucked up by U.S. IP lawyers. In particular, in the patents area. Why the hell do we bother with this detail on "clean room reverse engenering" sudently ?
When a driver is RE in a country outside U.S., what difference it makes that it's RE ?
Clean room RE is over zealous. It's inconsistent to require spending time & ressources on this.
Meanwhile, Linux devs will know that (on wireless land only !), it's controversial to do self RE. So, for instance, they will hardly write a replacment for the Intel 3945ABG binary crap (can't be done without RE). We're hooked to Intel ! we dismiss our freedom for big vendors fear. Too bad.
Now, let's hope that someone in the Nokia Maemo community will handle this source and port it to the Nokia 770 platform. Would be ironic !
A browser was the main free and open source component lacking on Nokia 770. If good enough, it could definitively take place of Opera, so the price of N770 could be cutted down a little bit, ironicaly, improving this Nokia product.
Anyway, for anybody: porting an app from Symbian platform to something like Qt/pe or Gnome over POSIX or win32 platform is a rather hard and long job. The open sourcing of this browser won't have any impact until it's made portable. Until then Opera is alone on the race (given that Opera developers do the port themself, and that most of this work is already done: Opera works flawlessly on Win32, Symbian, Linux, *BSD, Mac OS X, Palm OS, Solaris, QNX, OS/2, Blackberry...).
Just a dream: let's hope that - before Nokia browser become portable and ubiquitous on embedded market - Opera will counter attack by open sourcing his product...
Well in fact that's not many "differents wheels", rather the contrary !
Vim 7.0 uses the OpenOffice.org dictionnaries (and OOo algos to take the power of them). That's why we had 40 supported languages yet at the release.
And that's exactly what happened to FF 2: it took the well done work from OOo and based he speelcheck feature on that strong base (see http://dictionaries.mozdev.org/), again, that why he support yet 40 languages.
So the morality ?
I would like that reviewers put this common OOoDict heritage more in perspective, so people willing to contribute on a dictionnary could know where to start. There many more languages needed to be supported (so: any contribution will benefit at least OOo, vim 7 and firefox). Amen.
Slashdot Mirror
So, do you really think that the FUD campaign to bring legal uncertainty upon Linux is now over ? Think about it twice.
...) on the Linux desktop.
Microsoft (which has good lawyers, and was probably able to predict this SCO judgment) just alleged the "235 Microsoft owned patents' Linux infringement" just some month ago ! Coincidence ? Anyway we're still in the same situation as before (but without the SCO "proxy"): Linux (and it's users) are still tainted by muddled intellectual property claims, and is therefore victim of (bogus, but still) legal uncertainty.
Coincidence ? Novell was the one large linux actor to buy Microsoft "virtual 235 infringed patents" licenses: now no one but Novell can claim IP virginity (having Unix property and MS "alleged patents" licenses) without FUD threat when using Linux, and can now, thanks to this judgment and they licenses with Microsoft, racket Linux users. No wonder why they're pushing so hard for MS technologies (Mono/C#, exchange-compatible server,
One should note that, un like H.264, AAC is heavily patented. So, to stay on topic (unencumbered high-quality AV technologies) one may prefer use H.264 with Vorbis audio and Matroska container.
Such kernels developers feedback are very precious and insightful for us, customers. It's not only a matter of freedom an principles, it's about quality.
Be sure that - whatever the OS you use, being Linux, OpenBSD or FreeBSD -, when a vendor behaves that bad and is so reluctant in providing open access to documentation, you won't have a good driver nor a good support.
Those vendors behaviours are usually symptoms of a "closed" attitude, secrecy centerd, so even when we accept NDA, we can't expect them to disclose the whole needed informations (like, say, all firmwares versions bugs that needs a workaround in drivers level, know bad behaviour of their chipsets etc). This attitude will also discourage some knowledgeable developers to help to improve the driver, to fix bugs etc. Requiring NDA will prevent OSS kernel developers to share sensitive informations regarding their experience with the device (between OS, and even sometime inside the same kernel dev team).
So for now, if you need a stable encryption accelerator device, consider choosing an other vendor. Look out for Via C3, or SafeNet (and even some Broadcom) chipsets: those vendors plays the game well, don't seat on their customers (we) and the developers needs. They don't even hide behind a "U.S. export laws restrictions" argument, and didn't faced trials, proving the hypocrisy of HiFn assertions.
I fully agree, indeed the Linux developers are innocent there. By no means I was charging them: they are the one who actually write the free softwares !
And yes, commercializers are guilty ; but, to some extent, their user community have a responsability too: they (the users) had means to make commercializers/distros change their mind. They didn't, despite TdR and RMS calls for help.
That's why I'm talking about this here, I want this little slashdot post contribute to pass the message among free software users: we're responsible too. When needed, we should educate our software providers (aka commercializers aka distros), we should tell them that we expect them to play the rules fairly. They'll listen us, we're the user base, and after all, we're also their marketing & PR force.
Indeed having it GPL counts a lot.
But still, if the driver was developed under NDA and is bloated of "magic numbers" (as often in drivers under NDA, the implementation can't contain too much comment/infos), practicaly, we're near to loose one of the fundamentals rights supposedly granted by the GPL: the right to modify and re-use it. Well, you have this right, but you can hardly use it.
In practice, source code designed to hide IP secrets is in-between normal source code and binary exec. That's why, by the way, OpenBSD devs never accept and never signs NDA, as stated there http://www.openbsd.org/goals.html for instance.
In fact there were two differents campaigns goals, about two very different kinds of "blobs":
- For obtaining the right to redistribute firmwares with the system. With recent wireless chipsets, the firmware is often loaded in the hardware at runtime, so it should be provided separetly (a scale economy compared to providing a flash memory onboard). So even BSD or MIT licences were acceptables here: the firmware is to be loaded and executed on the chipset, not in the main system memory nor in the kernel. It's not ideal, but we're used to accept this with eg. PC Bios, or any other drivers. I understand that it could be non orthodox for Stallman, but this is not the vital part of what Theo asked for (it was rather secondary).
- For obtaining proper chipsets documentations and specifications so that any free OS can write his proper driver. And NOT a driver (mostly binary, but even free) from the vendor, nor specs under NDA. This was the crucial part.
But by no way the vendors provided any BSD drivers replacement for any blob (really, they don't care about OpenBSD). Some (Ralink, Atmel) agreed to redistribute the firmwares under MIT like licences anyway.And from Theo words, Stallman was found very supportive on this work (but not the Linux distros makers & users).
The problem was with the second point, obtaining the hardware specs and not a binary "blob" driver. Theo de Raadt was replied by some vendors that (citing from memory) "you just have to sign our agreement and accept our binary blob drivers, look, many distributions (namely Mandriva, Ubuntu and Suse) agreed so it's an acceptable proposal, and you've no other choice". Theo was chocked by those replies, and chocked that only the FSF helped on his lobbying: the Linux distros makers wheren't supportive, rather the opposite, and the users of those distros didn't react to such a betrayal. It's somewhat similar to the recent Sun's Java redistribution licence for Linux (except that it's about kernel code, more sensitive).
If you're interested on this story, I can find propers links, but most of it was covered on www.kerneltrap.org and www.undeadly.org, so you'll easily find the full story.
Sometimes, like at this point, it's the right attitude.
I second this. IP owner are kinda terrorists (presuring gvt agencies, senates, parliaments, etc), and succeed well in spreading fear. There's lot of irrational going on this matter:
- There's already drivers reverse engenered & implemented by the same person on the Linux kernel. Accepting this one would be consitent. What's so special with wireless ?
- For mosts drivers, we don't know such details about the way it was implemented. The status quo up to now, for drivers writers is: you know that you must provide your own original implementations, we can't verify (eg. the code could be stolen from solaris, or anything) but we give you confidence, you're responsible. Why don't we credit the developers of RE drivers such a confidence, that they have done a pretty original and new implementation (that's arguably proovable on a court, then) ? that'd be consistent.
- Linux users, developers, corporations and distributions come from all over the world (SUSE is German, Mandriva is French
...). Linux don't try that hard to comply with zeale to all insane rules on all involved countries, but try to behave fair regarding intelectual property. So far, we weren't hurt (and for the precise case we discuse: OpenBSD didn't undergo lawsuits). It'd be consistent to adopt the same approach for the most stupid U.S. potentials but improbables risks.
- There's many pathes where the kernel can be fucked up by U.S. IP lawyers. In particular, in the patents area. Why the hell do we bother with this detail on "clean room reverse engenering" sudently ?
- When a driver is RE in a country outside U.S., what difference it makes that it's RE ?
Clean room RE is over zealous. It's inconsistent to require spending time & ressources on this.Meanwhile, Linux devs will know that (on wireless land only !), it's controversial to do self RE. So, for instance, they will hardly write a replacment for the Intel 3945ABG binary crap (can't be done without RE). We're hooked to Intel ! we dismiss our freedom for big vendors fear. Too bad.
Now, let's hope that someone in the Nokia Maemo community will handle this source and port it to the Nokia 770 platform. Would be ironic !
...).
...
A browser was the main free and open source component lacking on Nokia 770.
If good enough, it could definitively take place of Opera, so the price of N770 could be cutted down a little bit, ironicaly, improving this Nokia product.
Anyway, for anybody: porting an app from Symbian platform to something like Qt/pe or Gnome over POSIX or win32 platform is a rather hard and long job. The open sourcing of this browser won't have any impact until it's made portable.
Until then Opera is alone on the race (given that Opera developers do the port themself, and that most of this work is already done: Opera works flawlessly on Win32, Symbian, Linux, *BSD, Mac OS X, Palm OS, Solaris, QNX, OS/2, Blackberry
Just a dream: let's hope that - before Nokia browser become portable and ubiquitous on embedded market - Opera will counter attack by open sourcing his product
Well in fact that's not many "differents wheels", rather the contrary !
Vim 7.0 uses the OpenOffice.org dictionnaries (and OOo algos to take the power of them).
That's why we had 40 supported languages yet at the release.
And that's exactly what happened to FF 2: it took the well done work from OOo and based he speelcheck feature on that strong base (see http://dictionaries.mozdev.org/), again, that why he support yet 40 languages.
So the morality ?
I would like that reviewers put this common OOoDict heritage more in perspective, so people willing to contribute on a dictionnary could know where to start. There many more languages needed to be supported (so: any contribution will benefit at least OOo, vim 7 and firefox).
Amen.