[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

on the dangers of open Interfaces ..

Erik Stevenson

From: Brad Silverberg
To: paulma
Subject: FW: DMTF and what to do with it
Date: Friday, January 28, 1994 5:36 PM

what a fucking mess

From: John Ludwig
To: Brad Silverberg
Subject: FW: DMTF and what to do with it
Date: Thursday, January 27, 1994 3:55 PM

I thought you should see this. All I can say is "simply amazing" . Below Dan is 
answering my questions to him on this mess.

If you have thoughts, I could use your help.


From: Dan Shelly
To: Jim Allchin; Jonathan Roberts; Richard Tong
Cc: Bob Muglia; David Thompson (NT)
Subject:  RE: DMTF and what to do with it
Date: Monday, Jaauary 24, 1994 5:52 PM

Answers embedded below. I was supposed to meet with IBM this Friday to discuss 
our distribution of source code to the DMTF. I backed out based on the fact our 
lawyers are still looking this over and it could take a *LONG* time for them to 

What a fucking mess.

>> A clear analysis of the situation

0. Is ther anything in writing?

>> The DMTF bylaws upon which this is based are not clear. The original intent 
of the DMTF was to deliver object level implimentation. Nowhere have we 
committed in *writing* to deliver source code, however, if we don't Intel has 
already stated that they will. Evidentally the verbal agreement for the last 
1.5 years has been that all work done by DMTF will be shared.

1. What protocol is being used to gather up the Novell stuff?

>> The idea of the spec is that it is protocol independent, runs on top of 
whatever you use. In Novell's case that could be either IPX/SPX or TCP/IP.

Having the DMI client interfaces might even be good on OS/2, etc
>> OS/2 clients with DMI interfaces would be easily managable from Netware.

2. Are *we* getting any source code from anyone? I don't see people lining up 
to give us code. And you can guess how I feel about giving them source code.

>> We would get the OS/2 service layer code without encumbrance (per Ken 
edwards, IBM). Hardly a stellar trade for providing access to our install base 
of clients. SunNet will also provide a UNIX implimentation only after DMI is 
adopted as a COSE standard (supposedly very soon).

The implimentation of the DMI layer will pick up information from random places 
and it could change with new versions of the system so I'm not interested in 
getting into some support problems with Novell and IBM shipping some DMI code 
that doesn't work on the next release. This is a rat hole.

>> It gets worse. It's obvious that what IBM and Novell want to do is "add 
functionality" hence their request for unencumbered source code. Based on what 
I was hearing and past performance of these 2, their implimentation would work 
with our OS's but then add extra functionality for OS/2, AIX, Dr-DOS, etc. My 
analysis is that we would shortly be positioned as "less manageable" and 
IBM/Novell could legally charge a license fee for their implimentation.


4. What pisses me off the most is that they didn't define the protocol - the 
most key thing in my opinion .. given the path we're on, it's Novell's protocol 
that will become tha standard.

>> Should IBM and Novell settle on a single supported implimentation for which 
we then have no further source code rights .. What this does is raise the 
prioroty for us to figure out what the pan for this protocol really should be 

>> Suggestions for how to proceed


2. The "cooperation option. We provide a license for our implimentation to all 
8 members of DMTF with the source *BUT* Microsoft retains rights to all future 
development based on this code, and royalty rights for any secondary license 
agreements ..


Of these optins I would suggest that we opt for #2. It will forestall 
IBM/Novell the longest to allow us time to adopt and evengleize a consistent 
protocol-based solution across all our clients ..


With no sense of irony or insight, he's just ascribed to IBM/Novell 
Microsofts' own strategy. Co-opt a standard, refuse access to the source, 
accuse the other fella of being "less manageable" and then charge him a license 
fee for their own interfaces. There's also a sense of reality denial where he 
see a paranoid projection of his own fears and intentions. The spec is protocol 
independent. The protocol is only important if you are planning on locking the 
others in and then charging them money for the 'open' protocols. 
court documents in the case of Comes v. Microsoft. 

[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index