The dangers of open Interfaces
Date: January 1994
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 ..
Synopsis
With no sense of irony or insight, he's just ascribed to IBM/Novell Microsoft's 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.Snippet
Erik StevensonFrom: 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 ..