|
|
Subscribe / Log in / New account

Apple buys cups

One of the more strongly discussed bits of news over the last week is the announcement that Apple has bought CUPS (the Common Unix Printing system) and hired Michael Sweet, the project's primary developer. Indeed, this deal happened back in February; it just took a little while for the people involved to get around to telling the rest of the world about it. There is a great deal of concern over what this deal might mean, though most of it is probably unnecessary. Still, there are some lessons to be learned here.

CUPS is an important part of our core infrastructure. Those of us who can think back to the days of trying to create lpr input and output filters to make a specific printer work can only be thankful that CUPS came along. It could easily be said that lpr lasted at least ten years longer than it should have, but, over that time, there were no real attempts to create a viable alternative. Projects like LPRng were mostly trying to create a slightly better version of the same thing. Then, there was the print system which Sun inflicted on users of early Solaris releases (who, as your editor can attest, were already suffering enough as it was); replacing that system with some version of lpr was a common thing to do. It took CUPS to implement contemporary printing protocols, support current hardware, and generally make the life of printer administrators easier - though, as any administrator who has lost a day to an obscure printer problem will say, things could get a lot better yet.

CUPS has always been a corporate-owned free software project, meaning that it carries all of the potential problems that any other such project has. When a single company owns a project it can strongly control its development direction, take the code private, grant license exemptions at will, abruptly sell the code to somebody else, and so on. Many companies which own projects do many of these things. Dealing with corporations has its risks; it has often been said that the corporate personality is best compared to that of a schizophrenic adolescent. Even so, such relationships have worked out well for the free software community with very few exceptions.

In this case, the ownership of CUPS has been passed from Easy Software Products (ESP) to Apple. Since contributors to CUPS are required to assign the copyrights to their work, ESP was entirely within its rights to make this sale. There are few constraints on what Apple can do with this externally-contributed code in the future; if it chooses, the company could certainly treat the code in ways that the original authors would not like. This risk is inherent in the transfer of copyrights; any free software developer who is contemplating signing a copyright transfer agreement should always think hard about who the receiving party is and what they could do in the future. The usual rule for dealing with companies - assume the person you negotiated the deal with will be immediately replaced by somebody who hates you - applies in this sort of situation.

The worst thing that Apple can do, in any case, is to take future releases of CUPS private. The current, GPL-licensed releases will remain available and free. Should this happen, the community will have to pick up from the last free version and create a fork; it certainly would not be the first time such an action proved to be necessary. For now, though, the announcement of the sale says "CUPS will still be released under the existing GPL2/LGPL2 licensing terms, and I [Mr. Sweet] will continue to develop and support CUPS at Apple." Given that certain aspects of CUPS development - supporting hundreds of printers, for example - are best done in the community setting, it is not hard to believe that this state of affairs could continue indefinitely.

Apple just might create enhanced versions of CUPS for its own operating system or as a commercial product. The company has already published a GPL exception policy allowing proprietary derived products to be made from CUPS - as long as they are distributed exclusively for Apple's operating systems. So Apple's version of CUPS might have shinier widgets or a few more printer drivers. Not the best of situations, but it is not all that different from the rights Sun gives itself with the OpenOffice.org code base. OpenOffice.org lacks features, fonts, and clip art found in StarOffice, but few OpenOffice.org users have complained that they felt cheated. Companies like MySQL make a nice living selling GPL exceptions to GPL-licensed code, including code contributed by outsiders.

The real threat, perhaps, is that Mr. Sweet will find himself carrying a lot of Apple-specific responsibilities (his statement in the sale announcement carefully did not say how much he would continue working on CUPS) and that the rate of outside contributions might slow as developers worry about what Apple might do. That could significantly slow the rate at which CUPS moves forward, to the community's cost.

One other potential problem is the CUPS trademark policy which has been announced by Apple. It requires permission to use the CUPS name with any derived product; a distributor who applies any patches at all, even security fixes, would be affected by this policy. The good news here is that, if this policy becomes a problem, the name of the print system could be changed to "mugs" or some such and few users would even notice.

On the other hand, what this deal might do is bring more resources to the development of CUPS and contributions from a company which, for all its faults, is known to pay a great deal of attention to the end user's experience. Development could speed up and head in directions which make CUPS easier to use than it is now. That would be an outcome which would be hard to complain about.


to post comments

Apple buys cups

Posted Jul 19, 2007 1:58 UTC (Thu) by jwb (guest, #15467) [Link] (7 responses)

I hope someone will explain how Apple can assert trademark rights on the CUPS name and logo. Other parties have been using the name and logo for years. It isn't even vaguely associated with Apple. I have the last release of CUPS in my home directory and there's nothing in here that puts a separate license on the logo, or asserts any trademark on the name.

Apple buys cups

Posted Jul 19, 2007 2:18 UTC (Thu) by jamesh (guest, #1159) [Link] (6 responses)

The logo and name are fairly well associated with Easy Software Products. The footer of every page in the CUPS web interface (http://localhost:631) asserts that CUPS is a trademark of ESP. The README file that comes with the code also says as much.

Given that ESP is now owned by Apple, why wouldn't Apple be able to assert trademark rights?

Apple buys cups

Posted Jul 19, 2007 2:32 UTC (Thu) by jwb (guest, #15467) [Link] (4 responses)

Ah, I see. I was looking in the COPYING file which does not mention the trademark.

It seems contrary to the idea of free software that I might inadvertently do something with the software that is OK as far as copyright is concerned but somehow runs afoul of trademark law.

Not necessarily incompatible, but there are definitely issues

Posted Jul 19, 2007 2:38 UTC (Thu) by dwheeler (guest, #1216) [Link] (1 responses)

They're not necessarily incompatible, but there are definitely issues.

The whole point of trademark is that users will know (and not be fooled) about exactly what they're getting. So if you want the "official Apple CUPS", trademarks can help you get what you wanted (in the sense that it'd be illegal to claim it for something that was not). From a FLOSS viewpoint, if you can make a change, and it's required that you change the name so that users will know what they're getting, that's okay.

But yes, there are definitely issues. One problem is that OTHER programs will look for specific program names, and taken to extremes this could be a problem. Another is if you can't add patches without a name change as well, that can cause real trouble from logistical problems (distros have had that issue with Firefox).

Not necessarily incompatible, but there are definitely issues

Posted Jul 19, 2007 9:57 UTC (Thu) by NRArnot (subscriber, #3033) [Link]

Precedent (yellow pages / NIS) suggests that program names don't have to be changed. The NIS programs are still mostly named yp*. IANAL but I suspect it would be an issue only if there is a program called precisely cups, rather than cupssomething. (/usr/[share,lib]/cups do exist on my system).

Apple buys cups

Posted Jul 19, 2007 5:26 UTC (Thu) by malor (guest, #2973) [Link] (1 responses)

The GPL gives you rights to the code, but not to the name. You can take the CUPS code and do anything with it that the GPL allows, but you can't CALL it CUPS if Apple doesn't want you to.

Overall, this is a pretty good tradeoff. It lets you modify code and distribute your changes, but it doesn't let you pass off your work as Apple's. By exercising control over the trademark, Apple can ensure its reputation isn't damaged by bugs and misfeatures you introduce, without actually preventing you from creating them. You get the freedoms the GPL cares about, and Apple can protect its good name.

This is the same reason that CheapBytes couldn't sell 'Red Hat Linux' CDs. They could make verbatim copies and sell them, but they couldn't call them Red Hat without permission. They had full rights to the code, but not to the trademark.

Apple buys cups

Posted Jul 19, 2007 8:48 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

Eventually it wasn't even true that CheapBytes could make verbatim copies. Nearly everything _interesting_ on the RHEL CDs or DVD is Free Software, but the contents also include Red Hat's trademarked logo, some branded documentation and contributed demoware, samples of future as-yet non-free software and so on.

Installing “Dave's Linux” and getting a Red Hat branded system is clearly not much more acceptable trademark-wise than just allowing Dave to call it “Red Hat cheap edition” so that had to stop.

So the similar-to-Red-Hat products you can download today are rebuilt from source with the trademarks removed where possible. They're recognisably Red Hat derived, but there's nothing to mislead the user into thinking that it's actually a Red Hat product, and I think that if you asked these other distributors after all this time, they'd agree that's a good thing.

Apple buys cups

Posted Jul 19, 2007 23:34 UTC (Thu) by giraffedata (guest, #1954) [Link]

Given that ESP is now owned by Apple,

A technical correction: ESP isn't owned by Apple; some things that used to be owned by ESP (presumably including the CUPS trademark) are owned by Apple.

Easy Software Products is apparently just an alias of Michael Sweet (and US law doesn't provide for ownership of a person!) Also, I assume Apple won't do business under the ESP name -- the Apple brand is much more valuable.

I still use lpr at home

Posted Jul 19, 2007 4:22 UTC (Thu) by thedevil (guest, #32913) [Link]

The filter problem is solved well enough by foomatic.

If I were an admin required to support dozens of network printers, that would be a different cup of coffee (so to speak), of course.

Anyone Remember MDQS?

Posted Jul 19, 2007 11:25 UTC (Thu) by danscox (subscriber, #4125) [Link]

For awhile there, we used MDQS the Multi-Device Queueing System, written by BRL (Ballastic Research Lab [US tax $ at work]). It was designed to replace lpr and at, and I *think* one more, but it currently escapes me. It had the concept of what form was mounted on what printer(s), and to me, that was one of it's greatest features.

I've not seen it for a number of years, so it may well be dead, now.

Any others?

Danny

PPR spooler still exists

Posted Jul 19, 2007 11:55 UTC (Thu) by wawjohn (guest, #509) [Link]

Years ago, frustrated with LPR, I used David Chappell's PPR spooler
(http://ppr.trincoll.edu/). It worked quite well in getting an old
LaserWriter with an Ethernet connection but no protocols other than PAP
working. It's specifically oriented for PostScript printers, but plays
well with Foomatic.

I had it working in production on an invoicing system for another client,
and it was quite reliable. I haven't kept up with it recently, but a
quick look at the website shows that it is still maintained.

CUPS vs Sun vs LPRng

Posted Jul 19, 2007 12:09 UTC (Thu) by rfunk (subscriber, #4054) [Link] (7 responses)

I have to take a bit of issue with the description and history in the
second paragraph. After running Solaris in the 2.4-7 days, trying to
configure and troubleshoot CUPS always brings back bad memories. CUPS
appears heavily based on that System V print system, and the
interdependencies of different programs and files do not seem to be very
well documented (other than "use lpadmin or the web interface").

LPR/LPRng configuration, on the other hand, is quite straightforward, and
things like magicfilter and foomatic (combined with more printer support
in Ghostscript) made printer configuration in that environment a
pleasure. Well, a pleasure for those of us comfortable with writing
shell scripts and editing well-documented printcap config files, which
admittedly is a shrinking percentage of the Linux userbase.

The one thing that CUPS makes easy and LPR/LPRng makes hard is selecting
different printer options. The old way required either making separate
print queues for different options (resulting in a combinatorial
explosion), abusing some ancient options (I use -i "indent N spaces" to
select N-up printing), or doing custom things (i.e. nothing else supports
it) with LPRng's -Z option. Since modern printers do have so many
printing options, this is really what drives CUPS adoption as far as I'm
concerned. (I currently have a laser printer driven by LPRng and a photo
printer driven by CUPS.)

CUPS vs Sun vs LPRng

Posted Jul 19, 2007 16:04 UTC (Thu) by bkw1a (guest, #4101) [Link] (2 responses)

I agree with your comments about CUPS vs. LPRng. CUPS is very
desktop-centric, and focuses on making life easier for the end user.
I've found it to be a nightmare to manage, though, compared to
something like LPRng, which is focused on the back end.

CUPS does, indeed make it easy for the end user to add printers
without having to know anything about print filters. But how often
do users need to add printers? (Especially in an enterprise
setting.) With LPRng, creating a print queue is straightforward
for the administrator, and the configuration files are understandable
later.

For the end user, LPRng provides the wonderful ability to type:

lpr -P printer@printserver myfile.ps

without having to set up any printers on his/her local machine.

I take the Unixy view that the end user shouldn't need to know
what type of printer he/she's printing to. The print filters on the
print server should take care of this, and all the end user should
need is the printer name. I agree that this raises questions about how
to let the end user tweak the output, but my users have been largely
happy with "-Zsimplex", etc. for a long time.

CUPS vs Sun vs LPRng [How many printers do you need]

Posted Jul 19, 2007 17:32 UTC (Thu) by smoogen (subscriber, #97) [Link]

In an enterprise setting, I see about 10 new printers a day (some are just moved from one network to another but its a lot of changes that seem to occur). Some organizations I have worked for have had 2-3 different printers on each desktop [black & white laster, color inkjet, special printer for slides]. People have made it a work habit to print out a copy of the legal forms etc over on Jack's printer in finance for his report etc etc.

Yes its a phenomenal waste of resources, money, paper, etc... but the problem occurs that when people are not comfortable with technology, they want an environment that they assured has a lot of redundency (in this case printers) in case they cant get something done by that unplanned meeting at 4pm.

CUPS vs Sun vs LPRng

Posted Jul 19, 2007 18:41 UTC (Thu) by mightyduck (guest, #23760) [Link]

Have you ever used CUPS or are you just talking out of your rear end?
With CUPS the user doesn't even have to know the printserver, the command
would be

lpr -P printer myfile.ps

The printers are automatically created on the users desktop via broadcast
(or polling in our case). I just create new printers on my print servers
and I'm done. CUPS is even so smart to combine printers with the same
name from different print servers into one class and use the servers
kind-of round-robin. All the filtering and everything is done on the
server.

CUPS vs Sun vs LPRng

Posted Jul 19, 2007 17:47 UTC (Thu) by emk (subscriber, #1128) [Link] (3 responses)

The other big advantage of CUPS is for laptop users, who roam onto all sorts of strange networks, and need to talk to a wide variety of printers. And CUPS handles this pretty well, though not nearly as well as MacOS X (which has ZeroConf auto-discovery of network printers).

It won't be too long before Linux users can see a list of all the printers on the local subnet, click on one, and print.

CUPS autodiscovery

Posted Jul 19, 2007 17:54 UTC (Thu) by rfunk (subscriber, #4054) [Link] (2 responses)

That only works if all those strange networks have printer broadcasting turned on -- IOW,
those "strange" networks are also running CUPS.

CUPS autodiscovery

Posted Jul 21, 2007 20:37 UTC (Sat) by cortana (subscriber, #24596) [Link] (1 responses)

One thing I'd like to see is for CUPS to adopt DNS-SD for printer discovery. I wonder if Apple's acquisition of the code base will make this more likely. Probably not as they already modify CUPS on OS X to use it, but haven't bothered to contribute the code back upstream.

CUPS autodiscovery

Posted Jul 22, 2007 17:06 UTC (Sun) by foom (subscriber, #14868) [Link]

I guess you should never let some facts get in the way of a good troll. From the release notes for
CUPS 1.3b1:
- Added support for DNS-SD (aka "Bonjour") printer sharing (STR #1171)

http://www.cups.org/articles.php?L479

Apple buys cups

Posted Jul 19, 2007 20:21 UTC (Thu) by oak (guest, #2786) [Link] (1 responses)

> The real threat, perhaps, is that Mr. Sweet will find himself carrying a lot of Apple-specific responsibilities (his statement in the sale announcement carefully did not say how much he would continue working on CUPS) and that the rate of outside contributions might slow as developers worry about what Apple might do. That could significantly slow the rate at which CUPS moves forward, to the community's cost.

I think this could be more of a problem for the Fltk toolkit than CUPS. At least several years ago, Mr. Sweet was pretty active on Fltk (it's used by the Easy Software's tools because Fltk is very lightweight and portable), but I think Apple is more interested in CUPS than Fltk development...

Apple buys cups

Posted Jul 26, 2007 10:50 UTC (Thu) by arcticwolf (guest, #8341) [Link]

I dare say that if any toolkit will die (or at least suffer) just because one user stops contributing to it, it's got more severe problems than that one user possibly disappearing.

Apple buys cups

Posted Jul 26, 2007 9:50 UTC (Thu) by muwlgr (guest, #35359) [Link]

And what about access control (except host-based) ?
What about PAM/LDAP/WinDomain integration ?
What about paper accounting and quotas ?
What about cancelling a task running on LPT printer without having to kill this 'parallel' process by hand ?
(I could continue the list on and on, as could everyone who dealt with CUPS in widely-varying environments)

If I were Apple, of course I would not share improvements in these areas with the public for free. Let the public continue suffer, and have more reasons to migrate to Mac :>

So why did Apple need CUPS?

Posted Jul 26, 2007 14:58 UTC (Thu) by ofeeley (guest, #36105) [Link] (1 responses)

What is Apple replacing with CUPS? I hear a lot of propaganda about how OS X is simple to use compared to GNU/Linux and how Free Software sucks in usability terms, so how come Apple didn't develop a superior situation in-house?

Or are they buying reverse-engineered, hand-created, community originated PPDs which they'll slot into their own framework?

So why did Apple need CUPS?

Posted Jul 31, 2007 10:29 UTC (Tue) by dr_lha (guest, #86) [Link]

The simple answer to this is that the current Mac OS X printing subsystem is CUPS, and a fairly vanilla version at that. Apple basically have just bought the rights to the solution they already use in house.

Most of the Unix stuff in Mac OS X is the same stuff you use on Linux, it just has a pretty front end to make things easy (much like, for example, KDE implements a pretty front end to CUPS).


Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds