This page permanently redirects to gemini://gemini.techrights.org/wiki/The_dangers_of_open_Interfaces/.
Date: January 1994
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.
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
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.
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.
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.
..
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
..
..
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://boycottnovell.com/wp-content/uploads/2009/01/px02003.pdf
=> ↺ http://boycottnovell.com/wp-content/uploads/2009/01/px02003.pdf
=> Techrights
➮ Sharing is caring. Content is available under CC-BY-SA.
text/gemini;lang=en-GB
This content has been proxied by September (3851b).