On Thu, 2004-06-03 at 10:52 -0500, Scott Sloan wrote: Hi, "Just great stable drivers" is not a real option. It is the "easy" way out for some hardware vendors, but brings loads of problems for users (loosing support on Linux itself in change of a driver, having to way un uncertain time before the vendor supports Linux updates, etc... etc...). So what you need are 1) Free Software drivers in a license that is both compatible with freedesktop.org's X11 AND the GNU GPL OR 2) at the very least specifications that have enough detail that a skilled set of programmers can create the drivers in 1). Personally, choice 1) is much better for both the hardware manufacturer and users alike, and I would advise to use the GNU Lesser GPL. This way, changes to the software released in the world would have a quid-pro-quod relation with the official version -- which benefits the manufacturer by reducing (sometimes a lot) development, support and maintanbility costs -- and would benefit the users by having Free Software drivers since that way distributions can support hardware straight out of the box, without giving any hassle. This later part is also an important benefit to the manufacturer: If users know that the hardware will JUST WORK[tm] with any recent enough distribution or simply by downloading an update, there is a large incentive for users to buy that hardware. I personally discarded a GEForce 2MX for an ATI 7500, which is quite well supported by the Free Software drivers. I'm glad to know you're in a position that might help turn more hardware manufacturers to our side. Some already do provide the GPL'ed code themselves (for instance, Digi, some stuff from Intel). Regards, Rui

Le jeu, 03/06/2004 à 10:52 -0500, Scott Sloan a écrit : I personaly want drivers with a FOSS license that are integrated in the various upstream projects (kernel, cups, xorg, etc) Feature-completeness is nice but not blocking at first. Same for speed/stability. The major part is releasing them under a good license and getting them into the right OSS project. Speed/stability/completeness are a side-effect of the code review that occurs at that time. So is the fact *someone* will maintain the code in the future. If any manufacturer is not confident enough in its code to get it reviewed and integrated when its hardware is just released, how I am supposed to trust it ? Or expect it to be updated once the next-generation of hardware hits the streets ? As far as I'm concerned, closed drivers (as good as they might be) means future deadware, and me spending precious time trying to rescue it. Closed drivers have no value - or even a *negative* one, since their existence means the manufacturer won't spend time on free ones. They are a fool's trap - even if you don't pay the associated cost at first you *will* pay it sometime. As all the nvidia FC2 users are now discovering. -- Nicolas Mailhot

On Thu, Jun 03, 2004 at 10:52:23AM -0500, Scott Sloan wrote: It depends on the vendor and how they perceive their market and product. If they see Linux as a market that justifies their own investment, engineering and full support then its useful to be able to build relationships between vendors and the relevant community people before they reinvent the wheel and so we can help them do the Linux bits of the job better. If they see no secrets in the interface to their hardware then throwing manuals over the wall to the right people can work very well. Some vendors are doing this routinely, others only to selected people. (And one or two have submitted their own drivers as non-company things to avoid any support assumptions 8)). A great way to test the water here is if people want Linux support for an older "uninteresting" to the vendor product because it carries little risk and lets people test the water. Where it gets hairy is when the vendor is worried about the hardware being cloned or has what they perceive to be very clever stuff at the hardware interface layer, or in software just above it. Nvidia have this problem - they have some rather neat DMA interfaces and context handling (which people have nowdays mostly reverse engineered), and a rather good implementation of GL. That to them is a sustainable competetive advantage so not something they are going to casually give out. This is where it generally gets fun - can you provide some docs, or NDA'd documentation that is sufficient to get good maintainable drivers. I'd also say - don't overlook the possibility that for a given piece of hardware nobody is interested in Linux support. Sometimes it happens and you can throw all the manuals over the wall and nobody cares. It depends what interest customers show (and a little google research can be informative too). There can also be advantages in having Linux support - Linux is growing and there are sometimes first mover advantages in being the vendor that can say "Yes our hardware works with Windows and Linux". That varies by product and how things fit together - the classic case where it is critical is enterprise backup tools. <General lecture mode> I'd say the most important part of all is relationship building - that means being able to appreciate both sides, to understand how you find something that generates value for both sides, and the willingness to be completely honest when you can't. If Linux support makes no sense now - say so. When you come back in two years and the market has changed the honesty then will have earned you respect. If you lied before then you may harm the whole vendor and Linux relationship when it does make sense. </Lecture> Alan