Apple buys cups
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.
Posted Jul 19, 2007 1:58 UTC (Thu)
by jwb (guest, #15467)
[Link] (7 responses)
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?
Posted Jul 19, 2007 2:32 UTC (Thu)
by jwb (guest, #15467)
[Link] (4 responses)
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.
Posted Jul 19, 2007 2:38 UTC (Thu)
by dwheeler (guest, #1216)
[Link] (1 responses)
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).
Posted Jul 19, 2007 9:57 UTC (Thu)
by NRArnot (subscriber, #3033)
[Link]
Posted Jul 19, 2007 5:26 UTC (Thu)
by malor (guest, #2973)
[Link] (1 responses)
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.
Posted Jul 19, 2007 8:48 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link]
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.
Posted Jul 19, 2007 23:34 UTC (Thu)
by giraffedata (guest, #1954)
[Link]
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.
Posted Jul 19, 2007 4:22 UTC (Thu)
by thedevil (guest, #32913)
[Link]
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.
Posted Jul 19, 2007 11:25 UTC (Thu)
by danscox (subscriber, #4125)
[Link]
I've not seen it for a number of years, so it may well be dead, now.
Any others?
Danny
Posted Jul 19, 2007 11:55 UTC (Thu)
by wawjohn (guest, #509)
[Link]
I had it working in production on an invoicing system for another client,
Posted Jul 19, 2007 12:09 UTC (Thu)
by rfunk (subscriber, #4054)
[Link] (7 responses)
LPR/LPRng configuration, on the other hand, is quite straightforward, and
The one thing that CUPS makes easy and LPR/LPRng makes hard is selecting
Posted Jul 19, 2007 16:04 UTC (Thu)
by bkw1a (guest, #4101)
[Link] (2 responses)
CUPS does, indeed make it easy for the end user to add printers
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
Posted Jul 19, 2007 17:32 UTC (Thu)
by smoogen (subscriber, #97)
[Link]
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.
Posted Jul 19, 2007 18:41 UTC (Thu)
by mightyduck (guest, #23760)
[Link]
lpr -P printer myfile.ps
The printers are automatically created on the users desktop via broadcast
Posted Jul 19, 2007 17:47 UTC (Thu)
by emk (subscriber, #1128)
[Link] (3 responses)
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.
Posted Jul 19, 2007 17:54 UTC (Thu)
by rfunk (subscriber, #4054)
[Link] (2 responses)
Posted Jul 21, 2007 20:37 UTC (Sat)
by cortana (subscriber, #24596)
[Link] (1 responses)
Posted Jul 22, 2007 17:06 UTC (Sun)
by foom (subscriber, #14868)
[Link]
http://www.cups.org/articles.php?L479
Posted Jul 19, 2007 20:21 UTC (Thu)
by oak (guest, #2786)
[Link] (1 responses)
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...
Posted Jul 26, 2007 10:50 UTC (Thu)
by arcticwolf (guest, #8341)
[Link]
Posted Jul 26, 2007 9:50 UTC (Thu)
by muwlgr (guest, #35359)
[Link]
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 :>
Posted Jul 26, 2007 14:58 UTC (Thu)
by ofeeley (guest, #36105)
[Link] (1 responses)
Or are they buying reverse-engineered, hand-created, community originated PPDs which they'll slot into their own framework?
Posted Jul 31, 2007 10:29 UTC (Tue)
by dr_lha (guest, #86)
[Link]
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).
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
Apple buys cups
Ah, I see. I was looking in the COPYING file which does not mention the trademark.Apple buys cups
They're not necessarily incompatible, but there are definitely issues.
Not necessarily incompatible, but there are definitely issues
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).Not necessarily incompatible, but there are definitely issues
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. Apple buys cups
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.Apple buys cups
Apple buys cups
Given that ESP is now owned by Apple,
The filter problem is solved well enough by foomatic.I still use lpr at home
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.Anyone Remember MDQS?
Years ago, frustrated with LPR, I used David Chappell's PPR spooler PPR spooler still exists
(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.
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.
I have to take a bit of issue with the description and history in the CUPS vs Sun vs LPRng
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").
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.
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.)
I agree with your comments about CUPS vs. LPRng. CUPS is very CUPS vs Sun vs LPRng
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.
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.
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.
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.CUPS vs Sun vs LPRng [How many printers do you need]
Have you ever used CUPS or are you just talking out of your rear end? CUPS vs Sun vs LPRng
With CUPS the user doesn't even have to know the printserver, the command
would be
(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.
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).CUPS vs Sun vs LPRng
That only works if all those strange networks have printer broadcasting turned on -- IOW, CUPS autodiscovery
those "strange" networks are also running CUPS.
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
I guess you should never let some facts get in the way of a good troll. From the release notes for CUPS autodiscovery
CUPS 1.3b1:
- Added support for DNS-SD (aka "Bonjour") printer sharing (STR #1171)
> 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.Apple buys cups
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
And what about access control (except host-based) ?Apple buys cups
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)
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?So why did Apple need CUPS?
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. So why did Apple need CUPS?
