[sldev] [PROTOCOL] Protocol Documentation
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
> 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:
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
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