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.
thanks,
jim
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
approve.
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 ..
http://edge-op.org/iowa/www.iowaconsumercase.org/011607/2000/PX02003.pdf
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.
|