Re: [Gimp-print-devel] OSX support (Was Re: CITIZEN photo printers)

[Robert K. <rl...@al...>]

Sorry for the delay; I wanted to think before I wrote.

On Thu, 15 Feb 2018 14:59:36 -0500, Solomon Peachy wrote:
> On Sun, Feb 11, 2018 at 01:09:50PM -0500, Solomon Peachy wrote:
>> Can you provide some specifics to what you mean by "commercial grade"?  
>> Gutenprint is already widely used for commercial purposes (such as photo 
>> kiosks) and it is not clear how Gutenprint may be lacking in this 
>> regard.  Are you perhaps interested in using Gutenprint as the basis of 
>> an application SDK, or looking to replace your current OSX drivers?
>
> Gary and I have done a few rounds of off-list discussion, but he's going 
> to be out of the office for a few days so it seemed like time to bring 
> it back into the open to see what everyone else thinks.

Thanks for taking point on this.

> Essentially, Citizen is considering using Gutenprint as the basis of 
> their future OSX drivers.  Thanks to customer demand, they are also 
> interested in providing official Linux support too.
>
> =46rom our discussions, it appears as if the core printer support is 
> already essentially complete and fairly well tested, so I expect there 
> will only be a little bit of work to be done on the hardware enablement 
> front (essentially fixing any bugs uncovered by a proper QA cycle with 
> real hardware, and possibly tuning the output or creating an ICC profile 
> to match what their existing drivers generate)
>
> So while that is all good and beneficial for all involved, I believe 
> they're really looking for a one-stop vendor relationship that can, for 
> appropriate consideration, produce an installable driver package for 
> them, and provide ongoing maintainence and feature releases as bugfixes, 
> hardware, and new OS releases warrant.  They would handle end-user 
> support.

We're not a corporate entity that can contract with outside parties
for something like this.  If someone wants to contract with them to do
this, that's their business, but I'm not going to be that person and
I'm not going to commit to a particular release cycle for this
purpose.

My personal preference -- and again, I'm speaking my own opinion here,
although it's a little hard to separate from my role as Gutenprint
project lead -- would be for an engagement model similar to Datamax
O'Neill, where Steve is seconded to the project and participates
actively, with commit privileges and all that.  That engagement
doesn't have to take the form of an employee in the legal sense; a
consultant/contractor could do this perfectly well.  I'm more
comfortable with that because things aren't going to simply get thrown
over the fence at us.  If someone in that position wants a release to
align with their needs, I'm a lot more receptive to doing it, since
the person making the request has skin in our game too.

> That's a reasonable wish, but what's unclear is the level of polish 
> they're after -- eg are they okay with a generic Gutenprint driver 
> package not unlike we already supply today, or would they want some sort 
> of unique-to-citizen release? Would they want unique-to-OSX features, 
> like a spiffier control panel or status monitor?  And (rather 
> importantly) are the terms of the GPL acceptible?

GPL needs to be a given.  There are ways of layering something
proprietary on top of Gutenprint without violating the GPL, and while
that's legal, it's not something I want to distribute in Gutenprint.
And I really want the license terms to be fully GPL2+ compliant, not
"GPL2-only" or "GPL3-only" or "GPL3+".  A variety of license terms can
lead to all manner of problems, some of which might not be anticipated
up front.  If someone wants to license something layered (using the
libgutenprint API) as MIT, I think that's OK because the MIT terms are
compliant with the GPL.  But nothing that's more restrictive in any
way than GPL2+ is OK (remember, copyright is held by individuals, so
basically anyone who has contributed to the core can effectively veto
any change, so I'm not claiming any particular privilege here).

I'm not entirely averse to distributing components that are by their
nature specific to a particular make or model.  We already have a few
of those, escputil and the dyesub backend.  A nice control panel or
status monitor would be a useful contribution, as long as it's not
gratuitously tied to a particular make or requires use of components
that are not themselves GPL2+-compliant.  But if they wanted to donate
a control panel or status monitor with a reasonable and extensible
architecture, and instantiate only Citizen printers in it, that's
perfectly fine.  It's not their job to support other printers; if we
want to support other printers in it, it's reasonable for them to tell
us that we have to do the heavy lifting.

And if they want to do a really good job with Citizen printers,
supporting capabilities and quality that we don't support elsewhere,
that's also perfectly good.  If it means that we have to make some
architectural changes to support those capabilities, I'm all ears,
especially given where we are with 3.0.

> On the Linux front, exising Linux distro channels are probably okay if 
> they are recent enough, but for older/enterprise/LTS-type distros it 
> would be highly advantagous if we could provide more up-to-date OS 
> packages.  That would tie nicely into the CI system we've been talking 
> about for a while.

True, although then we have the problem of which distributions we
support and having the infrastructure to support them.  We've done
pretty well (and I don't think it's an accident) at avoiding
hidden dependencies and assumptions, and I'm reasonably confident that
if we were, say, to build a RHEL 5 package it would work.  But we'd
still need to maintain all that.

> Personally, I don't think Gutenprint as a project is in a position to 
> provide much more than we already do, mostly due to our very limited 
> resources and expertise with respect to OSX.  Of our current-ish 
> contributors, only Steve has the ability to even generate OSX builds, 
> and we're entirely reliant upon him to test those builds.

...which, of course, is our big exception to the "no
distribution-specific bits".  OS X isn't a distribution in the
traditional Linux sense; it's a huge, essentially undifferentiated
blob, and add-ons are only distributed through the store, which
doesn't allow GPL anyway.

> I'm also not terribly fond of Apple, but if improving things for OSX 
> gains us additional resources to make Gutenprint better for Linux and 
> other Free Software platforms.. it's worth considering.

My general take is that portability is a good thing.  It helps weed
out hidden bugs and dependencies that could go from the latent to the
real at any time.  It also increases the user base, which also helps
catch problems and push improvements.
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

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