Is Apple a good open source citizen?

It’s no secret Apple’s Safari Web browser borrows code from KHTML, an open source rendering library. Apple even advertises the fact on its Web site. But when it comes to the code Apple seeds back to the community, the KHTML developers are far from pleased, according to a blog post by Zack Rusin.

Rusin and others cite numerous gripes: Apple uses an incompatible version-control system to manage its code; Apple links to its own proprietary APIs rather than open source ones; Apple writes patches in Objective-C rather than C++; Apple’s coding style is inconsistent, and it differs from the KHTML group’s.

Wait a minute. I thought Apple was using free software. What’s going on?

Responding to Rusin’s complaints, Apple’s Dave Hyatt asked what the company could do better. Rusin posted a list of suggestions, many of them good (albeit unlikely to be implemented). Opening a dialogue was the best suggestion.

But Rusin also wrote, “At some point the open source ideals which we apply to KHTML and [Apple’s] commercial setup … went in two different directions.”

I couldn’t disagree more.

The loosely connected network of open source developers is often described as a “community.” Real-world communities have rules — traffic laws, for example. If I agree to obey stop signs, observe speed limits, not drive while intoxicated, and mind countless other stipulations, then the community grants me the right to drive a car.

The open source community has rules, too, and these rules are laid out in the various licenses under which open source code is published. Although it may not always be the most cooperative company, everything Apple has done with KHTML code has been in compliance with the letter of the GNU LGPL (Lesser General Public License) — a point no one has even tried to dispute.

Should I be called a bad driver if, despite following all the rules of the road, I don’t offer free rides to the DMV employees who issued my driver’s license? Similarly, by obeying the terms of KHTML’s open source license, Apple is upholding every ideal it was asked to uphold. If the KHTML team now feels there are still more ideals they’d like upheld, they should adjust their licensing terms.

More telling, I think, is Rusin’s comment that KHTML developers are tired of being called “lazy” for not incorporating all of Apple’s changes into the main KHTML code base, when in fact many of Apple’s changes are incompatible. OK, that’s a fair complaint, but those jeers are hardly Apple’s doing.

No, what we’re seeing is nothing more than a good old-fashioned culture clash. Rusin and his cohorts probably never expected to butt heads with corporate policies when they started writing open source software. That doing so rubs them the wrong way should be no surprise. The real shame, though, would be if this dustup discouraged other companies from getting involved with open source.

It’s probably unrealistic to expect Rusin or any other open source developer to act as an ambassador for the movement. Still, more ambassadors may be exactly what are needed. Commercial organizations are contributing more code to open source projects than ever before, and the results from the users’ perspective have been overwhelmingly positive. If the momentum behind open source is going to continue to build, companies and independent developers must find a way to get along — even if they don’t always agree on practices.