Subject: Re: FSBs and client-server
From: Ian Lance Taylor <ian@airs.com>
Date: 25 May 2000 14:26:58 -0700

   From: kmself@ix.netcom.com
   Date: Thu, 25 May 2000 13:49:28 -0700

   Brian and I were debating (mildly) benefits of various licensing models
   recently.  He made a point I'm still mulling over WRT the BSD/MIT
   license -- it's a very strong vehicle for promoting adoption of an open
   standard.  Because these licenses allow both free and proprietary
   modifications to the codebase, a standard can be proposed, implemented
   in a free solution, while still being available for proprietary
   implementation from the same code base.

I expect this would work best if the free implementations dominate.
Otherwise it's hard to resist the impulse to embrace and extend.


As a historical note, I invented a couple of UUCP transport protocols,
and I also extended the UUCP communication protocol in some ways.  I
wrote an implementation, which was (and is) available under the GPL.
I wrote specs for the new protocols.

Although my implementation did not permit a proprietary fork, there
were a couple of independent proprietary implementations based on the
specs I wrote.  (These were DOS/Windows UUCP programs--my code only
ran on Unix).  (I also carefully documented the existing UUCP
protocols in what I believe was the first comprehensive documentation
of the existing proprietary code; that too was useful for new,
independent, proprietary implementations).

This doesn't prove all that much, since a UUCP transport protocol is
not a complex thing.  On the other hand, a complete UUCP
implementation is not all that trivial, and I wrote one without
relying on any proprietary code.

There is something to be said for independent implementations of a
standard.


   I made specific reference to the ongoing issue of proprietary
   incompatible Kerberos extensions by Microsoft as throwing a bit of a
   wrench into this concept, though IMO the problem is one not of software
   implementations but of protecting the integrity of the protocol itself.
   I've since read that the Kerberos spec is being reworked to address (and
   exclude) the extensions Microsoft has made to it.  Ian Taylor may have
   some more information on this as I believe he was involved with
   Kerberos.  This makes the Kerberos problem slightly different from what
   Brian had been discussing -- integrity rather than adoption.

I wasn't involved with Kerberos at the protocol level.  While at
Cygnus, I wrote a testsuite, I managed a release, and I fixed a bunch
of cross-Unix portability problems.


Having a MIT-license Kerberos implementation made it easier for
Microsoft to embrace and extend the standard.  On the other hand,
without an MIT-license implementation, Microsoft probably wouldn't
have used Kerberos at all.

Ian