Is the GPL really 'user hostile'?

Lastweek's column certainly got some folks' attention. My analysis of theway that Microsoft tried to hijack the Kerberos protocol generated morethan its share of comment.

In trying to make some sense of the feedback, I realized that many peoplethought that I had confused the Kerberos code with the The Internet Engineering Task Forcespecificationbased on Kerberos.

Indeed, it's the Kerberos reference code that isthe source of my complaint, and specifically that its BSD-based license makes it all-too-easy forpeople to make proprietary extensions. It's also quite truethat even if the Kerberos code was covered by the GNU GeneralPublic License (GPL), any would-be hijacker could still not becompletely thwarted -- they could simply rewrite the wholething from scratch, avoiding the copylefted code completely, and stillmangle the standard. My point is just that it would have been more difficult to subvertKerberos, 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 talkbackarea, were thoughtful. A few people pointed out that the best way toreally prevent such standards from being subverted is by theprotection of the Kerberos name by trademark. The point is to letdevelopers make anything they want, but if the finished product subvertsKerberos and isn't interoperable, it can't call itself Kerberosanymore.

This may not sound like much, but I think it's important. A companywanting to mangle Kerberos would be free to do so, but would not have theluxury of even paying lip service to a protocol with which it's nottotally compatible. Now, while I haven'tusually been in favor of using trademarks to impose an open source namingconvention, perhaps it would be worthwhile for an open standard likeKerberos that could be hurt by subtle changes in proprietaryimplementations.

Meanwhile, the lingering effects of last week's column include a number ofparallel 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 interestingexperience, as I was dealing almost simultaneously with people from opposite campswho had no patience with the other point of view. (I'm not going to namemost of them since they haven't given me permission, but you know who youare.)

Free for who?
The BSD fans of the group were (perhaps naturally) the more upset, but whatsurprised 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 infiltratebusinesses. The common wisdomhere was that if Kerberos had been GPL'd it would be languishing inobscurity because nobody would be using it. The claim was that commercialimplementors simply stay away from GPL'd code because they don't want togive up the right to make proprietary extensions -- and besides, most ofthem send back their extensions to the freeware pool anyway.

There's some validity to those claims. I've certainly come across genuinecorporate fear of the GPL -- execs at one Unix company I knew that waslooking at free software referred to the copyleft as a virus. Certainly,this is exactly what the Free SoftwareFoundation would like -- a company's bringing in some free softwarethat would later "infect" other products and cause them to be opened up aswell. This politically-driven prospect naturally scares the daylights outof the free-enterprisers in the BSD camp.

Point is, both approaches have their merits -- neither the GPL nor themore wide-open BSD licenseis the best -- or the worst -- in every situation.

Simply put, if your goal is to get your code into the most possibleinstallations, 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 aproprietary manner, even if the result is less widespread use, you use theGPL. And if you want something partway in the middle, have a look atlicensing approaches such as IBM's orwhat Netscape did forMozilla. 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 moreobjectionable (to some) elements of the GPL. Yet they're both consistentwith the commonly accepted open source definition, andit appears to me that they still keep most of the GPL's principlesin tact.

Freedom -- of choice
Last week I suggested that the GPL might be a better idea for one specifickind of software: reference code for interoperability standards. I stillbelieve that, despite the vitriol. But this is a far cry from saying theGPL is universally superior to BSD, and I don't believe that at all.Neither is universally better, and neither is innately friendlier or morehostile to authors than the other. It all depends on what the authorwants, and the best part of it is that the author has the choice. If youthink a license is hostile, just don't use it, OK?

What was more disturbing than the specifics of the GPL-versus-BSD flamesthat I'd clearly been unable to avoid, were the sweeping insults anduncompromising dislike each side had for the other's approach. Ratherthan cheer the software author's choices, the diversity of licensingmodels, and the realization that there might be more than one way to getthere from here, some folks out there exhibit an intolerance that'sdownright chilling. And the BSD camp certainly has no monopoly onself-righteousness. More next week on the fight for free software's moralhigh ground. If you have the time, do a little prep work and read this essaybefore then.

Are the licensing roads diverging, or can the community come together forthe good of all? Let me know in the TalkBack below.