Slashdot

Sometimes I manage to make valid points and things are good, but hardly worth remembering. My favorites are the times I manage to nail a solid response to common Slashdot drivel. This is where I'm going to start tracking my favs in perpetuity. Here we goes:

MS Doesn't Brainwash PHBs

Getting anything onto a handset takes a very close relationship with the handset maker. That real estate is extremely limited and every bit is accounted for. From MS's financials, they are subsidizing their phone OS to gain traction and that's a dangerous gift for the handset makers to fall for. If MS does manage to capture a majority of the handset market, handset makers can expect them to raise prices and eat into their profit margins.

That said, Nokia is the big fish to contend with in handsets. Due to Symbian, MS won't get Nokia to buy in unless they can get everybody else to buy in first. MS has gotten Samsung, Siemens and now Motorola to at least try their OS. They've even gotten Ericsson to dabble in portions of it. Although they've yet to make quantifiable inroads, the relationships required to turn up the heat are well established and cannot be taken lightly by the remaining of the Big 8, namely Nokia, LGE, Panasonic, and NEC. Keep you eye on the Japanese handset market, they (not Europe or the Americas) dictate the direction of the handset market. If the Embedded Linux Consortium holds together, it could pose the single most significant barrier to the MS Smartphone ever gaining traction.

The current darth of business method patents can all be traced back to the State Street Bank vs. Signature Financial Group case heard before the Supreme Court in 1996. More information on the case is available here.

This article is a WIP ...

Looks like SCO's case against Linux had yet another leg kicked out from under it. Due to some craft detective work, it appears that basis of virtually all of the infringing code SCO claims is in Linux was actually contributed by SCO developers post-Caldera acquisition.

This particular link details many submissions by Chris Hellwig while employed by SCO. These submissions appear to center around ABI and JFS, both points of infringement according to SCO.

This second link details the submissions of Tigran Aivazian which center on the Kernel core and microcode.

If these developers contributed code to Linux, it's entirely likely that they used that same code back in the SCO product line. In this case, there was no misappropriation as SCO currently claims and the issue is effectively moot.

With regards to the GPL and copyrights, there is a Copyright notice in the Linux kernel code from Caldera. Remember, Linux is the "program/work" released under the GPL, each individual file need not bear a copyright notice. Also, a quick grep reveals that there are many contributions from "sco.com", "caldera.com", and "caldera.de" email addresses. That said, SCO has stated that the 2.2 kernel is not infringing, this means that the infringing code was inserted in the 2.4 timeframe which dates to January 30, 2001. The oldest development release of 2.4 I could locate was dated August 11, 2000. Not so ironically, Caldera purchased SCO on August 2, 2000, so code donated by Caldera from the SCO code base to 2.4.0 would fall under the GPL. All that time between August and January was available for Caldera (ie. ex-SCO) developers to donate SCO code to Linux.

This is just a discussion piece. The idea is to list the top reasons why many hardware vendors do not provide Linux drivers for their hardware. Although there is no blanket answer for this question, the following list is my first crack at it:

1) There are already open source drivers for the chipsets used in the products

2) They have no Linux trained engineers to write and support the drivers in the first place

3) They are afraid of the GPL'd nature of Linux

4) The drivers contain 3rd party code and the 3rd party will not approve a Linux platform release.

5) They don't believe that providing a Linux driver will have a material impact on sales

6) They don't want to risk angering MS and risk loosing access to driver bundling and/or early software releases

7) The drivers rely heavily on infrastructure built into Windows (ie. Win-Modem drivers)

8) They are reselling rebranded 3rd party hardware

9) They prefer to release technical specifcations and let the community build open source drivers that can be directly incorporated into the kernel source tree

10) They are working on drivers but have not released them to the public

This is not meant to be a comprehensive list but I believe it covers most of the reasons I've heard either in person or via postings. I didn't want to get into rebuffing any of these points since that could get very verbose. These points are just here for discussion purposes.