[Openicc] Drop size calibration

[Hal V. Engel]

On Monday 04 February 2008 08:29:03 edmund ronald wrote:
> If the software is not part of any distribution, who cares about
> whether it is or not open source ?
>
> If users can buy a spectrophotometer, insert the CD or download the
> drivers and be up and running, and the manufacturer *supports* any
> distribution which has a given open-source virtualization
> compatibility, surely that is good enough for any user who wants to
> get work done ?
>
> The opinions of open source developers are without importance in such
> a case anyway as the manufacturer software is not part of any
> distribution, is only installed and downloaded by the final user, and
> only communicates by way of files with any open-source packages.
>
> I viciously hate companies who force proprietary and copyright file
> formats on their users. But I also hate "open" apologists who attempt
> to limit the user's rights by falsely invoking open-source legal mumbo
> jumbo. You don't like what software I install on my Linux box at home
> ? Ok - go ahead and take me to court.
>
> Edmund

Edmund,

We have yet to see ANY hardware vendor supply binary drivers that actually 
work for more than a small subset of the platforms that our software runs on.  
From my point of view this is the central issue with binary hardware drivers.  
Until we see one of these vendors deliver a binary driver that actually meets 
the vast majority of our needs most of us will keep on doing what we have to 
do to get things done.  

Your virtual appliance idea is one possible approach that might work with this 
class of devices (but probably not all types of devices).  But there are 
likely to be significant issues implementing the virtual device.   Looking at 
the existing virtualization tools like VMWare and QEMU interfacing this 
virtual device to software running in the host environment is likely 
non-trivial.  Part of the difficultly is that these virtual machines are not 
designed to expose virtualized devices to the host system.  In fact they work 
the other way around by exposing devices (IE. video hardware, USB ports, 
serial ports,  mouse, keyboard...) on the host system to the virtual machine.  
It might be possible to use a network connection between the devices 
virtualized environment and a platform specific (IE. locally compiled source 
code) interface module that runs on the host system to expose an IO channel 
between the virtualized device and software on the host system.  In the end I 
think this kind of approach is overly complex and is also trying to use a 
technological solution to a problem that is not technical in nature.

One other thing to keep in mind is that vendors do not have to open* their 
source code to make it possible for distros and users to build these drivers 
from the vendors closed source code.   Closed source does not mean binary 
only and vendors that claim it does are not being truthful.  There are 
vendors who distribute closed software as source code.  In the early 1990s I 
worked as a DBA supporting Oracle systems.  When we got an upgrade from 
Oracle what we received was a tape or CD with the Oracle source code.  As 
part of doing the upgrade we would build and install the Oracle software much 
like we would do when building and installing something like LProf or the 
GutenPrint drivers on a Linux box.  In other words vendors do have an option 
to distribute their closed drivers in source code form and this in no way 
makes the source code open.  This would mitigate the vast majority of issues 
that we currently have with closed binary drivers without the vendors giving 
up any rights or control over that software.   For example, third party 
patches could be applied as part of the build process to fix problems pendig 
the vendor releasing code with the problem corrected.  Considering that one 
of the largest software vendors in the world does this why can't these 
hardware vendors do the same thing?

I have yet to see any well known open source advocate asking any hardware 
vendor to open* the source code for their drivers.  What we want from the 
vendors is open hardware interface specifications.  This is a very different 
thing and is in no way comparable to requesting that the vendors open their 
driver source code.  

On the other hand any hardware vendor that actually works with the open source 
community on open source drivers gets extra points.  There are major hardware 
vendors that are currently doing this.  This includes Intel and AMD which are 
clearly the two largest hardware vendors in the world.  In both cases the 
vendors supply specifications for both CPU and GPU hardware to the open 
source community and both vendors are currently providing funding and 
internal staff to provide these specifications and to do some of the open 
source coding activity. 

Hal

*Open meaning that the source code can be freely copied, modified and forked 
if there is attribution.


>
> On Feb 4, 2008 4:58 PM, Hubert Figuiere <hfiguiere at teaser.fr> wrote:
> > On Mon, 2008-02-04 at 16:15 +0100, edmund ronald wrote:
> > >  My impression is that Barbieri would be ready to support the OS
> > > developers with measurement hardware if a solution can be found for
> > > the drivers which satisfies both them, their clients and the OS
> > > community.
> >
> > Which mean, for the community, that the driver be released under a Free
> > Software license, and if any firmware has to be uploaded to the device,
> > said firmware MUST be available for redistribution under terms that are
> > compatible with distributing Free Software. [1]
> >
> > Hub
> >
> > [1] it is often acknowledged that the binary firmware, which runs on the
> > device is not part of the driver but of the device. But preventing the
> > distribution of it just cause problem for users that are required to
> > install it by themselves. A click-through license is not compatible with
> > the requirement either. Take example on Intel policy with the iwl3945
> > driver for their wireless card.
> >
> >
> > _______________________________________________
> > openicc mailing list
> > openicc at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/openicc
>
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc