On Fri, Nov 19, 2010 at 3:43 PM, jtd <[email protected]> wrote: > On Friday 19 November 2010 11:18:03 Andrew Lynn wrote: >> On Fri, Nov 19, 2010 at 4:16 AM, Narendra Sisodiya >> >> <[email protected]> wrote: >> > Let me put my voice on the biggest hurdle in FOSS adaptation. >> > This hurdle is "Proprietary Hardware Drivers" >> > In India we recently established a "Open Standard Policy".It is >> > the great success of FOSS communities and our leaders. >> > In the same way we need to have a policy on Hardware selling. >> > This policy must specify that "Anything which Govt is buying must >> > have a Open Specification of their Driver." >> > >> > Why this is important ? >> > >> > Let me explain by an example. >> > A school from my town has purchased hardware 1 year ago. At the >> > time of purchase they are not knowing about Linux. Now even If >> > they want to move they have to take expert consultancy to install >> > Linux. Because many a time some device refuse to work with >> > GNU/Linux because GNU/Linux do not have proprietary drivers. For >> > example some WebCam do not work directly on GNU/Linux or most of >> > the whiteboards which is a high trend in schools etc. >> > >> > Dear all FOSS advocates, You need to remember that you can visit >> > a school or college and try for installing GNU/Linux BUT you >> > can't change hardware from a system. We must have a clear policy >> > that says - "every device must have a open specification or >> > driver for all available operating systems". >> > >> > We seriously need to blacklist proprietary driver and hardware >> > from market and stop their sell. >> > Proprietary hardware is one from of monopoly which is more >> > dangerous then proprietary software, > > I agree fully with the above. > >> >> This needs more of a debate. There are existing hardware >> compatibility lists e.g.[1], which serve as advisories, but have >> limited impact on policy. > > The hardware compatability lists are a community provided service, > which has nothing to do with crooked vendors. > These are lists from which you would derive a white/black list. They exist. This thread is to work through a procurement policy which encourages and allows FOSS adoption. You need to expand on crooked vendors: Are they vendors who intentionally keep feature specifications obfuscated to protect their market? What about smaller vendors who can mass produce excellent products but are tied to upstream third party patent encumberences - should they be excluded?
>> >> While no one would question the argument that proprietary drivers >> pose a severe restriction for widespread FOSS adoption, it is >> important to provide space to integrate proprietary drivers if no >> viable FOSS drivers are available - at risk to killing FOSS >> adoption by allowing only basic features. > > Did I get that right? proprietary drivers killing FOSS. The government > is the biggest IT purchaser. Having set guidelines on using FOSS, > they must insist that ALL HARDWARE procured by the government must > have their specifications mandatorily open. What happens when a > hardware vendor winds up in the hands of an inimical foreign > government? You cant hold your IT systems hostage to some vendor > hardware. > What you specify is an ideal case, but requires a phased implementation. We are looking at two extremes: One which is to insist on open standards for all hardware, and the other be damned as long as it runs - perhaps even permitting an ndiswrapper approach to the use of these drivers. The practical issue is that due to its hugh market share, MS-Windows is the defacto standard with desktop and related computers, and if devices are to survive, all they need is a driver compatible with Windows.There are a large number of areas where specific hardware devices are required which do not have open standards. There are also a large number of inexpensive devices produced in the third world which simply do not have FOSS drivers - probably due to lack of skills to create these locally. "Government" is not a single entity with a singular purpose, and I reiterate my earlier point: Without a fully featured driver, you get a crippled system. This is not so much of a problem for the server market, and your question related to control by foreign entities has become an issue for specialised markets such as telecommunications. For mission critical systems, by all means insist on open standards. How would you advise me to be academically competitive without GPU computing or OpenGL when they are required for my work? Or for the hugely growing IT enabled design, animation and CG-in film industry? Leave FOSS out, because it cannot run on the existing state-of-the-art hardware with existing open drivers? >> it is probably a better >> idea to look at a white list with a layered acceptance criteria to >> filter hardware at procurement. > > A blacklist alongside is a must. carrot-stick etc. > There are practical issues with procurement: It is better to define what can be procured, rather than list what cannot. This is not just a matter of semantics - if we stick to a black-list, it MUST be comprehensive, as the obvious interpretation is what can be procured is (Universe -minus- blacklist). >> >> To seed this discussion I propose that one such layered approach >> could be to define a policy such as: >> >> All hardware procured should be (additionally) certified to >> demonstrate the integration of all in-built and specified >> peripheral devices using all features/functionalities on the device >> with at least three community based popular GNU/Linux distributions >> namely Fedora, Open-Suse and Debian, through the following criteria > > does not cut it at all. The average life of a distro is around 6 > months. What happens after 3 years?. Throw away all that hardware?. > My choice of these distros is that they were midway upstream, full featured, and have sufficient community interest both for support and to keep them alive. I did mention we need some way to deal with redundancy, and specified stable and testing. Perhaps Narinder Sisodiya's reply that we adopt a distro like BOSS/SchoolOS as a benchmark is a good idea. >> >> (1) Devices should adhere to the specifications of the Linux >> Kernel[2] (AND) > > You mean the drivers should adhere to the coding standards of the > kernel. linux does not specify the innards of any hardware (byte > ordering, or cache, or network device fifio or whatever). > Not coding standards. Standards for loading and interfacing the driver with the linux kernel. I was assuming the now debated point that the Linux kernel is the defacto standard for GNU/FOSS distros. >> (2) Devices with the source code for the drivers/peripherals >> released under GNU GPLv2/3 license >>(OR) > >> (3) In the inability of the manufacturer to release the driver >> under the criteria (2) above, > > The government shall not procure such devices or recommend such > devices for purchase (eg RBI mandating properitary hardware for > connecting to the NEFT) > The govt. should not procure hardware containing devices for which open standards exist and viable hardware with drivers for these open standards that fully meets the users requirement exist. >> the driver should be available in >> stable and testing repositories compatible with the above named >> mainstream community distributions.[3] > > Bitrot will guarantee any such availability to be worse than useless. > Bitrot will not set in even if the distro has a short half-life, as long as it keeps an active (current) stable and testing repository. Andrew. <snip> _______________________________________________ network mailing list [email protected] http://lists.fosscom.in/listinfo.cgi/network-fosscom.in
