[Openicc] ColorVision Open Source Policy

Robert Krawitz rlk at alum.mit.edu
Tue Nov 13 04:11:59 PST 2007


   From: "Hal V. Engel" <hvengel at astound.net>
   Date: Mon, 12 Nov 2007 20:49:40 -0800

   On Monday 12 November 2007 19:02:34 Robert Krawitz wrote:
   >    From: "Hal V. Engel" <hvengel at astound.net>
   >    Date: Mon, 12 Nov 2007 17:21:07 -0800
   >
   >    In a follow up from C. David Tobie of ColorVision he wrote:
   >
   >    "We have supported Linux for years, for specialty clients such as
   >    Disney. We continue to consider the possibility of a display
   >    calibration solution for end users on Linux. But no one on
   >    Linux/Unix,BSD ever contacts us and asks about products they can
   >    purchase from us for those platforms, they always ask if we have an
   >    SDK, so they can write something themselves. Its a very different
   >    type of market.."
   >
   > The fact that he says people are asking for an SDK suggests to me just
   > how wide the gulf is.  I think it's much more likely that people are
   > asking for the programming specs for the hardware, not an SDK.  A
   > proprietary interface to a binary-only library with functionality
   > restricted to what ColorVision thinks is important isn't likely to be
   > too interesting to the kind of hard core *IX people who want this kind
   > of device.

   In fact in my request to them I stated that I suspected that their
   SDK was of little use to me since I thought that it was very likely
   that it did not support the platforms I needed and that what I
   needed were device interface specs.  As you can see he ignored that
   part of the request like it never existed.

I suspect that what you were asking was simply so foreign to him that
he translated it into terms that were more meaningful to him.

   On the other hand I suspect that the functionality supported in the
   vendors driver/library would be enough to do about anything that is
   needed in this case.  The real issue is that the driver is likely
   never going to be available for the platforms that we support not
   that the driver/library is crippled or has limited functionality.
   After all they use this same driver/library to support their own
   software and at least the higher end versions of their software are
   very feature rich.

That would assume that they'd actually document all those goodies.

   > Again, there are enough self-proclaimed leaders in the community who
   > are willing to live with this situation that it's easy for a company
   > with proprietary leanings to miss the other side of it.

   But in this case the vendor is not even providing closed drivers of
   any sort (good or bad) for anything other than Windows and OS/X and
   they will not even provide the API documentation for the drivers if
   this is going to be used by an open source project even on one of
   the supported platforms.  So this is one case where even those
   "self-proclaimed leaders in the community" you refere to have
   nothing to "live with".

Yup, but those self-proclaimed leaders aren't particularly interested
in anything as hifalutin' as color management.  Most of them only seem
interested in mass market numbers and trying to be "more Windows than
Windows" for newbies, and aren't interested in the high end.  I've
seen this kind of thinking in the printing community as well; all
these people are interested in is "gee, I can print my spreadsheet to
an automatically detected printer!".  They're not interested in color
management, linearization, or anything else esoteric.  So what happens
is that these vendors get the messages that "proprietary is fine" and
"Linux isn't interested in anything high end".

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton


More information about the openicc mailing list