Matthew Benjamin
writes:
The following appeared this afternoon on the Appraising
Microsoft mailing list.
I include it in response to a
story a few weeks ago which implied that CPT/Ralph Nader/James
Love–who recently hosted an academic conference in Washinton, DC,
to discuss possible remedies in the MS antitrust trial–were biased
against Open Source software licensing or viewpoints.
The text of Mr. Love’s remarks–with its point-by-point summary
of Richard Stallmann’s proposed remedies–suggests otherwise:
------------------- TEXT FOLLOWS --------------------------
I'm going to have transcripts of the event on the
web page soon. This was my opening statement.
Jamie
WORKSHOP
WHICH REMEDIES?
APPRAISING MICROSOFT II
CARNEGIE INSTITUTE
1530 P STREET, NORTHWEST
WASHINGTON, D.C.
FRIDAY, APRIL 30, 1999
8:30 AM.
Transcript by:
Federal News Service
Washington, D.C.
From the Third Panel on Interoperability remedies
MR. LOVE: My name is Jamie Love, I work in this building.
I spoke a little bit this morning when people first came in. I
run a consumer group called the Consumer Project on Technology.
I'm going to be speaking today about three issues about
interoperability remedies. One has to do with data formats, one
has to do with the 1984 undertaking between IBM and the European
Commission. And a third are issues relating to interoperability
remedies which have been advocated by Richard Stallman, who is
one of the early founders of the free software movement.
First, just in terms of what we mean by interoperability,
and why I think it's so important. The software market, more so
than say the market for apples or a lot of other things, is
really based on the idea that people want to have programs work
together, or they want to exchange data. It's the
interrelatedness of products, it's the interrelatedness and
interdependencies of data and the ability to share it and use it
which makes it useful, which creates all these problems that an
result in anti-competitive problems.
I have a friend who works at the United States Trade
Representative. He's worked there for 23 years on standards. He
says, in every single case in the United States he's worked on
standards, companies had used standards as a weapon in an anti-
competitive way. So I think we just have to assume this is not
unique to the software sector, this is kind of a generic problem.
And you have to be, you know, sort of recognize this is going to
kind of happen. And in software it's really standards squared
kind of problems, because things just really are useless if they
don't work together.
There's a lot of different ideas about how you get
interoperability. Some people say, if everyone just buys
Microsoft products, that's one way to do it. Other people want
to sort of see standards or access to technical information like
has been talked about here. Even if you buy just Microsoft's
products and that's all you use, you will still have noticed
that, say, for example, if you have Microsoft Word '95, and
somebody sends you a file that's called Microsoft Word '97
format, you can't read it, because they're not really compatible
file formats. And it's because in a way Microsoft actually uses
tough business tactics on its installed base of users, because
they're actually its biggest competitor, people that haven't
bought more frequently or recently. So it's not even a problem
that's solved if you have a monopoly.
Now, I'm going to try and move right along. There's a book
that people have that has this cream color, called Which
Remedies, Appraising Microsoft. I make reference I here to some
papers, because the papers I thought were pretty good, and I
don't really want to replicate everything. The first paper I
make reference to is called Let My Data Go, by Simpson Garfinkel
in January of 1998 in Hot Wired. And in this article he
advocates that better documentation of data formats is, he
thinks, a real big issue in terms of competition. The idea
being, if somebody wants to enter the market for word processors,
they want to exchange mail, if they want to get into the
multimedia game, or develop players or things like that, the
actual ability to understand the format the data is stored in is
really quite important.
Now, he actually goes through and he makes a case in this
particular article. When he wrote this he was talking mostly
about programs like Microsoft Word, Microsoft Excel, or Intuit's
Quicken, which has its own sort of compatibility issues about its
data formats. But, I think that more recently there's a lot of
interest in multimedia data formats, and things like that. And
so this is his proposal, and he elaborates in his paper. I won't
really make the case for it, but I want to draw your attention to
it.
Number two, I'd like to talk about the 1984 undertaking in
Europe with IBM, and the European Commission. Now, I guess
undertaking sounds like you bury somebody or something in this
country. But, I think it's what we think of as a consent
agreement, or something that IBM agreed to do in order to avoid
being found guilty by some antitrust proceeding in Europe. I
really found out about this when I was in Brussels a year and a
half ago, and I was meeting with DG-4, which is what they called
the antitrust guys there. And Fin Lumholt, who was the head
of the unit that worked on the IBM -- that was responsible for a
lot of the computer things, gave me a copy of the agreement and
asked me if I would read it. And I was, at that point,
unfamiliar with it. And I was surprised at how relevant and
contemporary it seemed to me to be to the current Microsoft case.
Now, there is a paper in your packet called the 1984 IBM
Undertaking by Fin Lumholt. And he wrote in October of 1998
these are quotes from his paper, and he starts off -- these
are -- these paragraphs, by the way, were actually not in the
same place in the paper, but I wanted to fit them on one page
here. He said first of all let me sort of explain the basics of
what the IBM undertaking did. It required IBM to document the
types of the program that you needed to be able to make hardware
or software inter-react with the IBM mainframe family of
computers, the VM-370 computers. And the complaints in Europe
were based primarily with American companies that went to Europe
and complained about the fact that IBM was engaged in a lot of
the same unfair business tactics that Microsoft is accused of
more recently.
And well, as the Reagan administration basically ended the
case, in Europe they did not end the case, and they moved
forward. And the focus of the agreement was to get IBM to
provide timely notification to their competitors of changes in
the way that their software and hardware specification worked, so
their competitors could sell disk drives, or software, or backup
devices, or things like that, that were value added parts of the
IBM network.
And what IBM did is they set up a series of mechanisms to
force IBM to provide the information, but also to do things, as
we'll see, to provide affirmative technical assistance if a
compatibility problem existed. It provided some technical
definitions, which were kind of interesting, because it's a tried
and true agreement, and it provided a supervisory role for the
European Commission, which would meet I think about once a year
with IBM to review the progress and to see what complaints --
requests companies had made for technical information and how
they're resolved. And the understanding was that if IBM did not
live up to the spirit of the agreement, and this was a word that
was brought up immediately to me in Brussels, the spirit of the
agreement, that the consequences to IBM would be that they would
go beyond the initial consent order into a different level of
detail, a different level of obligations.
And so IBM had an incentive to make the commission happy.
And, in fact, IBM did make the commission happy, and I think a
lot of people in the industry understood that what happened in
Europe actually benefited the United States because the same
disclosures were made in Europe were actually disclosures that
benefited their competitors worldwide.
And he said in this paper, I guess you maybe had time to
read these things in your paper, this is some detail about it.
I'd like to just go into some of the particular provisions about
the agreement which is, by the way, the next document in your
packet is, in fact, a copy of the 1994 undertaking by IBM. And
these documents, by the way, the IBM document itself is on the
web. We put it there.
Now, I wanted to draw attention, first of all, to paragraph
four in the undertaking. In paragraph four it says that if IBM
announces a new product outside the European Commission, for
which it will be seeking orders within, that they will consider
that basically the same date. So, in other words, IBM could not
have gotten out of its obligations under this consent order by
basically delaying the announcements within the European
commission, and starting to market off the United States. So it
was an attempt to kind of make it a global mechanism, to kind of
make the announcements kind of have a global effect. In effect,
if they announced any product anywhere in the world that would
ever be sold in Europe, they had to consider that effective date
of when they'd have to make disclosures. I guess that's actually
paragraph number one here.
Paragraph number four made a distinction between the amount
of time that they had to give advance information to their
competitors, whether it was a software product or a hardware
product. And within the hardware product they used this 120 day
standard. But, within the software standard they referred more
to when the interface became reasonably stable, in any event, no
later than general availability. But, there sort of was this
issue about when IBM had to actually make the information
available to its competitors, which they had to deal with. Not
necessarily what everybody wanted, this is, in fact, what was
negotiated.
On paragraph six, if they made a change to an existing
interface in such a way that it made the product no longer
operable, IBM had to disclose the change in a way that would
permit people to make the changes with enough time so they could
fix things. And they had to provide assistance, sufficient
assistance to make sure that the people's products could be
fixed, and they would work.
Another thing I found interesting, and I'm just sort of
picking out a couple of parts, because it's a long agreement.
And I don't have five hours to read the whole thing. So I
thought I'd do this. On appendix A, section 14(b), this was an
obligation where IBM was required to actively support open system
interconnection protocols for the network, as a standard way of
connecting with their networks, in addition to whatever
proprietary things they had. So that they had to support an open
protocol. So like IBM could be required to support particular
several subset of category, they could be required to support
certain open protocols.
IBM reserved the right to make reasonable non-discriminatory
charges about --you know, if they had the license information and
it gets into this in the way of patents and intellectual property
and things like that, IBM could charge for certain parts of this
intellectual property, but there had to be a non-discriminatory
deal to it. It was a fair dealing kind of a situation. They
couldn't punish somebody because somebody wasn't playing ball, or
was a particularly effective competitor they wanted to punish.
So they had a non-discriminatory aspect to things. They defined
what they considered to be general availability, go to appendix
B, the next thing, no waiver of patent rights. They had a way of
saying, for example, that IBM could not require people to give up
patent rights in order to get access to information, and this
should have come up, I believe, in the Intel case, in the
Intergraph case.
And in the area of source code it was interesting to me that
it was said that if IBM had to provide its source code, it said
that IBM could also inspect the source code of the person who
received the code so they could see, if in fact, the person who
had received their source code had stolen it. So there was kind
of a, you show me, you show yours kind of a dynamic in this other
agreement.
I'm going to move on now to Richard Stallman who actually
wanted to be here. He's in Australia right now. And I talked to
him about remedies. He's very interested in -- he's one of the
few people I've talked to that actually writes up remedies, most
people they're just for remedies, period, or you're against them,
like Stan.
I'm just kidding, Stan.
Not that many people do the heavy lifting, you know, like
Steve did this morning, to actually come out and sort of explain
them. So these are his, and since he's not here I wanted to read
them. Now, by the way, this is from Richard Stallman's paper
which is also included in the conference book. So you can read
the more complete version.
Number one, he wanted to require Microsoft to publish
documentation of all interfaces between software components,
communications and protocols and file formats, saying this would
block one of their he called favorite tactics, secret and
incompatible interfaces. And then he said they should not be
allowed to use non-disclosure agreements with other organizations
to excuse implementing the secret interface. The rule must be,
if they cannot publish the interface, they cannot release an
implementation of it. This is his remedy.
Number two, he said he would require Microsoft to use its
patents for defense only, which in fact in some areas that's
exactly how Microsoft has actually used its patents in some
areas, in the field of software. This would block -- in the
past, by the way, Microsoft at one point in their history was
quite hostile to some of the software patenting issues. I think
maybe they've kind of changed their -- as they've acquired, like
IBM did, their portfolio, you know, the interests change. But,
Microsoft has already announced in this document, which either
they leaked or it was published from kingdom come, the Halloween
documents about Linux.
And in there they describe the fact that they can use patent
claims to stop these free programmers from doing stuff by just
making it illegal, even if they're not getting paid a wage, even
if they're doing it in their free time, they can actually stop
people from developing products which compete against Microsoft
by saying that they have a patent on it. And I think anyone who
has looked at software patent and actually read a lot of software
patents, and is not appalled it would amaze me, because it's like
the biggest scandal I can think of what's happening in software
patents right now. They seem to give them out for just about
anything.
But, in any event, he says one remedy would be making it
defensive only, and then -- or mutual defense, kind of a pooling
where the other party would have to then agree to the same terms
as Microsoft. In other words, to use it as a jujitsu to sort of
force the other firms to kind of give up, essentially, their
predatory nature to software patents.
And then the last one here, he also wanted Microsoft not to
certify any hardware as being compatible unless the complete
specifications have been published, so any programmer can
implement the specification. And he points out that this one
typo in this, the last word here says regulation, that's not
actually the word on the slide, and it's not the word in the
article. It should be negotiation, which is what Richard
Stallman said, but the typist [of my slides] made a mistake here.
So I want to just correct that.
Now, Richard represents a community of people that are
developing these software that don't get paid for it, and their
concerned that certain fees that are placed in terms of
licensing, certain kinds of proprietary interface type things
present a real problem for them down the road, because just the
way that particular group -- now I'm kind of short on time.
This is all I have right now for my presentation. I wanted
to be focused on very concrete and specific proposals that people
have made in different environments. I haven't really told you
our own sort of take on everything I've presented. But, this is
kind of the beginning of a process for us to be more systematic
about remedies.
--
James Love, Director, Consumer Project on Technology
I can be reached at love@cptech.org, by telephone 202.387.8030,
by fax at 202.234.5176. CPT web page is http://www.cptech.org