[sldev] [PROTOCOL] Protocol Documentation

Argent Stonecutter secret.argent at gmail.com
Wed Oct 3 08:08:39 PDT 2007

On 03-Oct-2007, at 08:40, dirk husemann wrote:
> hmm...i think by opening up the discussion about the future  
> architecture
> and by starting an architecture working group, LL is showing a
> substantial amount of openess --- and i trust them that they are dead
> serious about this. so, in the long run we will have public specs that
> were developed in the open.

My point is that these comments (below), if they've been accurately  
reported by John, indicate that LL doesn't have any intention of  
conforming to any public specs or notifying anyone of changes that  
effect the public specs. Now, I'm not saying that they have to...  
there is nothing that says an Open Source project actually has to  
produce an Open Systems product. I'm just pointing out that these two  
kinds of openness aren't the same, and it's important to be aware of  
the distinction between them.

I'm not knocking Linden Labs here. Open Sourcing the client was an  
amazingly cool thing, it was really courageous of them to do that,  
and I'm not criticizing them where they haven't gone further by any  
means. I'm just trying to promote another kind of openness... one  
that's as old a part of the software industry as Open Source and just  
as important... and arguing that it needs some kind of commitment  
from LL that they don't seem to have made:

* LL: we can't log every change, it would be cluttered and irrelevant
* LL: the source code is very clear on how all of this works
* LL: it [the code] is very clear documentation
* LL: so this whole discussion about documenting the capability API  
is just so people can steal code?

Again, I'm not saying they have to make that commitment, I'm just  
asking them to.

To illustrate where I'm coming from, let me use an example that's  
been brought up many times from all sides...

Microsoft isn't constrained to remain compatible with Samba. They are  
constrained to remain compatible with legacy installations, and to a  
lesser extent to remain compatible with the architecture that they  
have published for third parties to implement:

IETF standard 19:
  RFC 1001
  RFC 1002

IETF drafts:

Storage Networking Industry Association specs on www.snia.org.

Related Microsoft standards such as MS-CHAP.

These are not published as code, they're published as actual specs  
that Microsoft has promised to follow. In as far as they actually  
follow them, CIFS is an "open system". Now... they've extended the  
hell out of it in practice, used licensing tricks to target open  
Source implementations, and the actual implementation in Windows NT  
is a moving target that Andrew Tridgell has been chasing for years,  
but there are parts of it they hold to that provide a useful (if nopt  
complete) level of interoperability, and so a five year old copy of  
Samba can still be used to access files on Windows Vista if the right  
settings are made on the Windows side.

There are also standards and specs that don't satisfy either Open  
Source or Open Systems requirements. For example, Microsoft's  
official page on CIFS at http://msdn2.microsoft.com/en-us/library/ 
aa302240.aspx - this documentation can't be used by Open Source  
implementations because the license restricts redistribution... in  
particular you can distribute source code based on this document but  
that right is not transferred to the recipient unless they sign a  
similar license.

There are some additional Microsoft documents I can't read because  
they're wrapped up in an "EXE" file. :)

And, finally, Microsoft has attempted to use the "code as spec"  
argument with CIFS, both in sample implementations with restrictive  
licenses and by arguing that they can't release the spec without  
revealing proprietary code.

CIFS is a great example, because over the years it has spawned  
implementations that are both open and closed source, and it's a mix  
of  open and proprietary standards... you can find examples of just  
about everything in its history.

More information about the SLDev mailing list