In trying to make some sense of the feedback, I realized that many people thought that I had confused the Kerberos code with the The Internet Engineering Task Force specification based on Kerberos.
Indeed, it's the Kerberos reference code that is the source of my complaint, and specifically that its BSD-based license makes it all-too-easy for people to make proprietary extensions. It's also quite true that even if the Kerberos code was covered by the GNU General Public License (GPL), any would-be hijacker could still not be completely thwarted -- they could simply rewrite the whole thing from scratch, avoiding the copylefted code completely, and still mangle the standard. My point is just that it would have been more difficult to subvert Kerberos, not impossible, had the reference code been under the GPL. That's all.
Good place for a trademark?
Most of the responses I received, both personally and in the ZDNet talkback
area, were thoughtful. A few people pointed out that the best way to
really prevent such standards from being subverted is by the
protection of the Kerberos name by trademark. The point is to let
developers make anything they want, but if the finished product subverts
Kerberos and isn't interoperable, it can't call itself Kerberos
anymore.
This may not sound like much, but I think it's important. A company wanting to mangle Kerberos would be free to do so, but would not have the luxury of even paying lip service to a protocol with which it's not totally compatible. Now, while I haven't usually been in favor of using trademarks to impose an open source naming convention, perhaps it would be worthwhile for an open standard like Kerberos that could be hurt by subtle changes in proprietary implementations.
Meanwhile, the lingering effects of last week's column include a number of parallel games of e-mail tag -- those reply-to-a-reply-to-a-reply duets -- with people who took exception to what I'd said. It was an interesting experience, as I was dealing almost simultaneously with people from opposite camps who had no patience with the other point of view. (I'm not going to name most of them since they haven't given me permission, but you know who you are.)
Free for who?
The BSD fans of the group were (perhaps naturally) the more upset, but what
surprised me was the utter contempt with which some hold the GPL. Terms like 'poison pill' and 'author-hostile' were used in characterizing the GPL as something deviously designed to infiltrate
businesses. The common wisdom
here was that if Kerberos had been GPL'd it would be languishing in
obscurity because nobody would be using it. The claim was that commercial
implementors simply stay away from GPL'd code because they don't want to
give up the right to make proprietary extensions -- and besides, most of
them send back their extensions to the freeware pool anyway.
There's some validity to those claims. I've certainly come across genuine corporate fear of the GPL -- execs at one Unix company I knew that was looking at free software referred to the copyleft as a virus. Certainly, this is exactly what the Free Software Foundation would like -- a company's bringing in some free software that would later "infect" other products and cause them to be opened up as well. This politically-driven prospect naturally scares the daylights out of the free-enterprisers in the BSD camp.
Point is, both approaches have their merits -- neither the GPL nor the more wide-open BSD license is the best -- or the worst -- in every situation.
Simply put, if your goal is to get your code into the most possible installations, no matter what these installations do to your code later, you use BSD. If, on the other hand, you don't want your code extended in a proprietary manner, even if the result is less widespread use, you use the GPL. And if you want something partway in the middle, have a look at licensing approaches such as IBM's or what Netscape did for Mozilla. As Matthew Dillon, who weighed in with one of the more sane replies to my column, suggested to me, these two approaches eliminate some of the more objectionable (to some) elements of the GPL. Yet they're both consistent with the commonly accepted open source definition, and it appears to me that they still keep most of the GPL's principles in tact.
Freedom -- of choice
Last week I suggested that the GPL might be a better idea for one specific
kind of software: reference code for interoperability standards. I still
believe that, despite the vitriol. But this is a far cry from saying the
GPL is universally superior to BSD, and I don't believe that at all.
Neither is universally better, and neither is innately friendlier or more
hostile to authors than the other. It all depends on what the author
wants, and the best part of it is that the author has the choice. If you
think a license is hostile, just don't use it, OK?
What was more disturbing than the specifics of the GPL-versus-BSD flames that I'd clearly been unable to avoid, were the sweeping insults and uncompromising dislike each side had for the other's approach. Rather than cheer the software author's choices, the diversity of licensing models, and the realization that there might be more than one way to get there from here, some folks out there exhibit an intolerance that's downright chilling. And the BSD camp certainly has no monopoly on self-righteousness. More next week on the fight for free software's moral high ground. If you have the time, do a little prep work and read this essay before then.
Are the licensing roads diverging, or can the community come together for the good of all? Let me know in the TalkBack below.
