decoration decoration
Stories

GROKLAW
When you want to know more... 		decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.

You won't find me on Facebook

Donate

Donate Paypal

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.

What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments

Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Another Request to Pick Your Brains - Re Interoperability
Friday, September 15 2006 @ 04:48 PM EDT

We have another request to pick your brains. We're getting so many requests, I guess I need to make a new Pick Groklaw's Brains category.

Struan Robertson, the editor of OUT-LAW.com, a legal news site in the UK provided by the law firm of Pinsent Masons, is looking for experiences you may have had at companies you work for or own. He's particularly looking for experiences of software firms that have been affected by a lack of interoperability. They are working on a feature story on the topic, and he'd like to get comments from you for that purpose.

He mentioned to me the following: "Competition laws are slow and difficult to apply; reverse engineering may not always work and there are limits on when it is lawful. So should it be possible to force companies to license interface information on commercially-reasonable terms to allow interoperability? You might be a software firm that was refused interface information by another company. Or, conversely, you might have designed an innovative interface and feel it is your right to keep rivals out." Either way, he'd be interested in your experience and point of view.

Of course, the first thing that came to my mind is Samba's struggles, Andrew Tridgell's testimony about it in the EU antitrust matter, referenced in FSFE's Sean Daly's interview with George Greve. And the farce about getting Microsoft Office to interoperate smoothly with ODF and the worry going forward about possible proprietary blobs and incomplete disclosure, as explained by CCIA in an older paper. This is the same question the French examined with respect to iTunes. But you may have other examples that weren't in the news. If so, if you'd share them, he'd appreciate it.

But I'll let him tell you what he's looking for in his own words. Here's his official request to pick your brains.

***********************

Should interoperability become a legal right in the US and EU?

I'm the editor of , a legal news site based in the UK. We're exploring the possible need for a new law that could be used to force companies to license interface information on commercially reasonable terms to allow interoperability.

Do you have a view? We're particularly keen to hear from Groklaw readers who know of cases where, e.g., a firm was refused interface information for a proprietary platform. (The only examples I know are Apple's - which doesn't want iTunes purchases playing on rivals to the iPod; Microsoft's recent antitrust battle; and IBM's antitrust case from the early 1980s.)

See: http://www.out-law.com/page-7292

Thanks,

Struan


  


Another Request to Pick Your Brains - Re Interoperability | 244 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Another Request to Pick Your Brains - Re Interoperability
Authored by: iraskygazer on Friday, September 15 2006 @ 04:54 PM EDT
I'd suggest that Struan review the legal documentation at
<a href="http://www.oasis-open.org/home/index.php">Oasis Open
Standards</a>

The Oasis consortium is attempting to address the type of questions Struan is
asking.

[ Reply to This | # ]

Corrections here
Authored by: MathFox on Friday, September 15 2006 @ 04:59 PM EDT
Just in case someone made a small mistake

---
If an axiomatic system can be proven to be consistent and complete from within
itself, then it is inconsistent.

[ Reply to This | # ]

Off topic
Authored by: MathFox on Friday, September 15 2006 @ 05:05 PM EDT
There allways are Open Source and/or legal issues that don't fit the article but
are important enough to mention. Well, this is the place. Make links if you know
how to type an URI.

---
If an axiomatic system can be proven to be consistent and complete from within
itself, then it is inconsistent.

[ Reply to This | # ]

Another Request to Pick Your Brains - Re Interoperability
Authored by: Anonymous on Friday, September 15 2006 @ 05:38 PM EDT
> We're exploring the possible need for a new law that could be used to force
companies to license interface information on commercially reasonable terms to
allow interoperability.

I think it would be insane.

Who defines what interoperability is?

Who defines what features and interfaces must be interoperable? It's not
uncommon to not know until long after a product is released, what interfaces
might be useful to a third party? It's not even uncommon for supposedly open
products, not to be sufficiently open for user's requirements in the first run,
and for new and improved interface options to be added over time.

What happens if somebody modifies their product to drop an old API, or no longer
support an old file format? Do they get sued or prosecuted for breaking
interoperability?

If some little guy releases a bit of software, does he need to be afraid of
being sued or prosecuted because his documentation isn't up to somebody else's
standard for the required level of interoperability.

Quatermass
IANAL IMHO etc

[ Reply to This | # ]

Another Request to Pick Your Brains - Re Interoperability
Authored by: Anonymous on Friday, September 15 2006 @ 05:42 PM EDT
The first problem that I see with requiring interoperability is that you're
forcing companies to absorb the overhead required for developing some kind of
interface and then maintaining it.

I have some expamples of what kind of overhead I mean, but bear in mind my views
are filtered through my experience doing interface conformance and
interoperability testing for a large US-based telecom provider.

Let's say you have an interface and a published spec that describes it. Someone
will want to ask questions about the spec, and then you have to burn staff time
to answer those questions. If you want to support your spec properly, you will
want to do this, but it's a cost nonetheless.

What if I develop a product that is going to interface with your product
according to your published spec, only later I find out that there's a
discrepancy between the spec and the way your product actually works? Are you
liable?

What if the spec is unclear and you don't answer my questions in a timely
fashion? Or maybe you decide to change your interface to exclude a key feature
that I need. What's your liability in those cases?

I've been involved in litigation over these kinds of problems in the past.

Also, what happens when you change your interface? What's the allowable lag time
between when you change it and when you notify everyone it's changed? Do you
have to notify the world every time you make a change? Does this obviate the
competitive advantage of developing new features in secret?

These are just a few concerns I can think of, off the top of my head. I know
that they reflect my own weird point of view, and YMMV, etc. and so forth. Let
the discussion begin!

[ Reply to This | # ]

Data Files
Authored by: capt.Hij on Friday, September 15 2006 @ 06:03 PM EDT
We used to have all kinds of problems, but they really amounted to issues of
data formats. The problem was about taking data from computer calculations and
interfacing with graphics packages. We tried piecing together commercial
packages, but large companies did not want to waste their time with small
timers. After lots of frustration we ended up basing purchasing decisions on how
much we could tweak the software.

For example, for a while we used NAG's IRIS Explorer because it allowed us to
write our own software to interface with other products, and once the data was
in the system we could use their built in stuff.

We have slowly gotten away from the propietary stuff all together. The open
source tools are beginning to get good enough that we are able to do most
anything we want. It can be frustrating at times, but not having your scripts
and data locked in to someone elses product goes a long way for making up for
it.

The thing is we now can claim ownership of our own scripts and data, rather than
pay someone else to make use of our own stuff. At the same time we realize that
it is in everybody's best interest to share (i.e. give back to the community)
which in some ways is a fun paradox for us. (Not so fun for the big software
companies that tried to lock us in.)

[ Reply to This | # ]

Another Request to Pick Your Brains - Re Interoperability
Authored by: Anonymous on Friday, September 15 2006 @ 06:17 PM EDT
Well - you only have to go to this discussion back awhile on Groklaw for a detail of problems what Microsoft has wrought as it moves toward it's own world of a larger monopoly in the world of software....  This is related to interoperablity (for sure)!

Search Groklaw for this in the comments:      MS standards Dirty Tricks

See:

MS standards Dirty Tricks - Authored by: Winter on Saturday, December 10 2005 @ 02:04 PM EST

Now FYI - there were alot of posts that updated this list of interoperability issues that MS has a history of being involved in - and because of the length of the comments/posts, there was some instruction by others as to how to make the post better - just so it didn't take up too much of the main thread in OT (or wherever it was posted).

So - there i guess that there is a Wiki on this as well...   The Wiki is very good....
I think this came about due to some Boston paper that is owned by the NY times writing something about someone in Mass?

Check this out:

http://tiki.vadi m.ws/tiki-index.php?page=MicroSoftTricks

You can search Groklaw for other related posts regarding this subject line.

Good luck... - MS has been building one way data flows to their own formats for years.   Only to go back to anyone else's format was a horse of a different color.   How did Microsoft grow into a monopoly... the old fashioned way (they used their money to program code changes faster than anyone else could even think of keeping up by reverse engineering - at one time MS participated in standards groups, or was spying, a point of debate).

[ Reply to This | # ]

NTFS
Authored by: tiger99 on Friday, September 15 2006 @ 06:32 PM EDT
It is not just Samba, there is a long-standing difficulty with NTFS as the disk file system is not documented fully, if at all, and what we have in Linux is as a result of reverse engineering by some very talented and persistent people, just like the Samba team.

But, until very recently, there have been persistent problems with writing to NTFS file systems, which have resulted in serious data loss. Depending who you choose to believe, NTFS write support still only works in certain circumstances, but does no damage, works all the time and is perfect, works all the time but occasionally indicates spurious errors, or is still positively dangerous. Now without full disclosure of the necessary information it is fundamentally impossible to know that writing to NTFS partitions is truly safe. But that implies no disrespect whatsoever to the developers, they have done a great job in the circumstances, just like Samba.

As it happens, I really need NTFS write support to be working, but dare not yet try it. Maybe another few months, when more evidence of success has been accumulated.....

This has basically wasted a lot of time, both for people who need to use it, and also by occupying talented developers who could be doing something else. What is more, the NTFS format seems to be subject to periodic change, sometimes as a result of installing service packs, which is probably a deliberate attempt to frustrate compatability.

Actually, M$ have done themselves no favours by this, as it makes it more likely that someone with an NTFS formatted disk will dump Windoze completely and reformat the thing, rather than going for dual boot. It also shows how limited the functionality of M$ products really is, as Windoze is the only modern mainstream OS (I count every BSD, Solaris, HP/UX, AIX, SCO Open Sewer, MAC OS-X, even older things like Atari and Amiga, Acorn, SGI....) that has no capability whatsoever of reading and/or writing "foreign" file systems. Every other system can do it, in varying combinations, but not Windoze.

Having said that, I may well boot up the disgusting XtraPathetic OS for the first time in months, format a spare disk, copy lots of data to it, and move it over to the good Linux box to see what happens. But I will not know for many months if it is truly reliable.

[ Reply to This | # ]

Out-law.com, "Perry Mason"
Authored by: tiger99 on Friday, September 15 2006 @ 06:40 PM EDT
I expect they will be nicknamed Perry Mason.....

Very useful site though, webmasters probably ought to bookmark it as there is stuff that you will need to know if your site is targetted at, or hosted in the UK.

[ Reply to This | # ]

Talk to Libraries about document formats.
Authored by: Brian S. on Friday, September 15 2006 @ 08:40 PM EDT

They've had to deal with the problems since computerisation.

They know quite a bit about it.

I expect their pretty hot on image and video, although it's some time since my involvement.

Brian S.

[ Reply to This | # ]

Another Request to Pick Your Brains - Re Interoperability
Authored by: Crocodile_Dundee on Friday, September 15 2006 @ 08:53 PM EDT
> We're particularly keen to hear from Groklaw readers who
> know of cases where, e.g., a firm was refused interface
> information for a proprietary platform.

I worked for a multinational company that is headquartered in the EU. This
company tends to grow by aquisition and the corporate structure is one of many
independently managed groups overseen my the mothership.

The company has "rules" which dictate how parts of the company must
deal with each other -- basically this entails providing services at close to
cost, and having a (kinda) internal open source policy. Oh, and the various
parts were not supposed to compete against one another to win contracts.

Unfortunately, these were never enforced (other than the non-compete clause).
It's a fact that each individual company was marked on it's return on
investment. Even though making money from another part of the business didn't
effect the total performance of the company, it *did* have an effect on the
management of each part. In short, it was ignored because there were stronger
rewards for ignoring it than for enforcing it.

Our company was contracted to provide a particular service (not related to
software at all) and we bidded on the basis that another group company had
software that was claimed to do just what was needed to support this project.
An internal cost was figured out and used to prepare our tender -- which we
won.

Along came our collegues from another country (who were quite friendly chaps)
but it turned out that they had almost no experience with the software. In
addition they were doing development on it to try to make it work. *and* they
were under strict instructions not to release the source to us. Later on they
were not allowed to do any work for us because other projects were "more
profitable".

They sent us lots of CDROMs with source and other things on them (however the
source either wasn't there or was horribly old, or incomplete. We said we
wouldn't sign off until they could simply demonstrate that the system could be
built from the sorce they sent us (it never happened).

It turned out that the software was pretty much hard coded for a previous
contract, that is was not complete, and that it was now obsolete.

We were also committed to it and had no source.

They refused to send us documentation on the interfaces and forced us to
(secretly) reverse engineer the database (which was designed by a non-IT
person).

Rather than developing a system that could be deployed on similar projects (and
the company as a whole did a lot of these type of projects) we ended up with a
secret system that cost us and our client a lot more than we expected. Whilst
it now works, it is still hampered by being cobbled on to the bits of the old
system that worked, and the rest of the company still uses spreadsheets and
paperwork.

A lose-lose situation for all.

And we were all one big happy family. Imagine if we had been competitors in the
market?

---
---
That's not a law suit. *THIS* is a law suit!

[ Reply to This | # ]

Interop in medical software
Authored by: Anonymous on Friday, September 15 2006 @ 11:13 PM EDT
I work in medical software. My company makes EHR (electronic health record)
software; our software records and stores details of a patient's encounter with
a physician, but does not do scheduling -- as scheduling ("practice
management") software is already a saturated market. One of our major
hurdles is reading scheduling information out of users' practice management
systems.

There have been multiple times when software to allow interoperability has been
available only as a plugin offered by the practice management system vendor --
at a price point which is a very large multiple of the cost of our complete
system! This is, obviously, a substantial inducement for a customer to purchase
the vendor's own EHR tool rather than trying to buy a 3rd-party tool and
interoperate; however, said EHR tools typically have a user interface which is
vastly inferior to what our system offers.

Consequently, we are obligated to spend a great many man-hours developing
"hostile integrations" -- cases where we either interact directly with
the other system's database; operate its software through the same mechanisms a
user would; etc., because otherwise the added cost of purchasing this plugin
would completely prohibit potential customers from buying our product. Customers
suffer from this, because the hostile integrations are in many cases technically
inferior to what could be offered through a supported interface -- certainly,
they also are developed later and take longer to fix bugs (and have more obscure
issues waiting to be found).

[ Reply to This | # ]

Look back at history
Authored by: ausage on Saturday, September 16 2006 @ 12:15 AM EDT

Once upon a time, back in the days of the very first computing devices (unit record, tabulating machines) everything was proprietary and you had to purchase your consumable supplies (paper, punched cards, etc) from the same sources as your equipment. Then came some anti-trust and unfair competition laws suits, consent decrees and specifications were published, competition flourished, prices dropped and the market grew and the equipment manufactures made even more money.

A few years later we had maimframe computers, with bundled software, proprietary languages and unique character sets. Another consent decree forced the separation of hardware and software. A manditory government standard required a common character set and a common programming language. Again competition increased, prices dropped and everyone made more money.

A few years later along came Unix, a common operating system for many computers. Almost everyone had access to the source code, either officially or unofficially (wink, wink, nudge, nudge). Since the creator, AT&T was banned from selling computers, they licensed it to everyone. Competition flourished, prices dropped and everyone made more money.

A few years later IBM, in a startling departure from their standard practices, introduced the PC, with open interface specifications and published BIOS code. The market grew exponentially, competition flourished, and everyone made much more money.

Well defined interface standards, hardward or software, promote the growth and innovation of our industry. It took some work for the orginal COBOL, FIPS, and ANSI standards to be supported by everyone. However, once the US government said you MUST support these standards or we will not purchase your systems, every supplier rushed to comply, and it benefited everyone.

It seems that whenever we have several companies competing for the same business equally, they all support the development of a common standard because it makes good business sense to them. However, whenever one company gains a major portion of a market, they insist on closed technologies to try and lock in their customer, preferring the short term gains to long term growth.

If we want to see open interfaces, then we need not new laws, but rather tender documents from governments and major corporations that say suppliers must provide open specifications without intellectual property restrictions, no exceptions.

If one major government told Microsoft published the complete spec from NTFS or we will not purchase or renew one license for Windows and make ODF the default document format or we will not purchase or renew one license for MS Office, Microsoft might scream and yell and lobby, but they would comply because if they didn't they would lose their market position in just a few years. No legislation, no law suits, just good old capitalistic purchasing power.

My humble opinion and experience for what its worth

[ Reply to This | # ]

Interoperability involving Safety
Authored by: Anonymous on Saturday, September 16 2006 @ 12:50 AM EDT
I work with industrial machines, often CNC lathes and mills. Often these
machines are big and expensive, and have life spans much longer than typical
office computer equipment. The interoperability issue revolves around three key
factors:
1. The desire to expand machine function.
2. Safety and Product Liability
3. DMCA / Copyright Law and IP Protection.
4. The effects of integrating the above in one machine.

Expanding Machine Function

Most people want to expand the operations of the machine. Usually, over 20+
years, some function comes up that wasn't envisioned in the original
implementation. It could be something computer related, like better diagnostics
or machine status monitoring. It could also be something strategic, like
robotic cell integration. Either way, usually a good profit case can be made
for the change, if it can be implemented at a reasonable cost (less than the
cost of buying a new machine.)

Safety

The safety issue comes up in many ways. Sometimes, the customer wants to
upgrade the machine for enhanced safety compliance. Other times, the vendor
does not want any changes in the safety system, because they can be sued if
anyone gets hurt. This can get really complicated, as the vendor may have
incorrectly implemented the safety system in the first place. Additionally, the
vendor may threaten you with DMCA and/or lawsuits for examining the safety
system to closely. This has happened to me.

DMCA / Copyright Law and IP Protection

Often the vendors of these machines want to "lock up" the software to
prevent copying. This becomes really complicated over 20+ years of machine
operation. For instance, the vendor can go bankrupt. The copy protection
technology can go obsolete. The computer hardware and software can become so
obsolete that it is effectively irreparable. In this circumstance, it is very
difficult to make new software with new hardware to retrofit onto the old
machine. If the vendor has locked up the software and hardware in a
copy-protected package, then it is very difficult to reverse engineer what they
did 10 or 20 years later.

Effect of Integration of Safety, Hardware and Software

Some machine suppliers have taken to routing safety circuits through custom
designed computer I/O boards specifically designed for their machines. They
view these boards as important proprietary IP. They don't want to easily
release the documentation on them. These boards are also quite effective in
copy protecting the software, as it is trivial to write software that only works
if the custom designed circuit boards are connected to the computer.

Effectively, you wind up with all of the possible safety and interoperability
issues tied up in one software / hardware / machine. For instance, the vendor
will generally argue these points:
a) Some safety interlocks are machine oriented and require minimal electrical
support. Nevertheless, the vendor implemented them through custom designed
circuit boards to reduce costs.
b) Other safety interlocks are implemented in software, which is copy protected
through the same electrical hardware used for key safety interlocks.
c) The vendor does not want any safety circuits to be modified for fear of
product liability.
d) The vendor does not want software to be reverse engineered or source code
released.
e) The vendors often threaten DMCA, other lawsuits, or general "safety
problems", if you intervene too invasively in their machines.

The customer has the following legal and practical problems:
a) Long-Term Support: What if the vendor goes bankrupt or charges excessive
fees for machine upgrades?
b) In Canada, the company owner is legally responsible for safety. As such
obtaining accurate safety information is critical to minimize risks.
c) As a Professional Engineer (P.Eng.), I am also responsible for giving
opinions on machine safety, and ensuring that machines are properly integrated
into cells. How do I do this if the vendor is withholding information, like
electrical schematics and software source code?
d) Both the P.Eng. and the Company Owner, are supposed to ensure safety, but how
are we supposed to do that if the vendor makes all useful safety information
proprietary???
e) What if the high-level control system is either running proprietary software
(like Microsoft Windows or Windows CE), or on a network that could effectively
be running almost any software? Are the low-level interlocks sufficient to
protect the operator? Or would a proper safety analysis require the analysis of
the high-level software?

This debate is starting to take on serious overtones here in Canada.
Increasingly, machines are on larger scale computer networks. I have both seen
and heard reports of serious malfunctions, likely software related, that have
triggered potentially dangerous (sometimes life threatening) machine operations.
In theory, software shouldn't be able to threaten the operator. In practice, I
wonder about "leak through". The ability of interoperable network
enabled interfaces to affect shop floor behaviour of machine tools.

I fear that it is only a matter of time before someone is involved in a fatal or
serious bodily harm level injury involving networked software. It just seems
that too much integration is present between the network level interfaces (for
company wide uses), and the critical functions of machines.

Recent Life-Threatening Incidents Involving Networked Software

If you consider that sometimes operators can get trained to always do what the
computer says (as opposed to using their senses and following manual
procedures), then fatalities have already happened. In the last few years,
hydroelectric damn operation was brought under remote computer control
(involving operators). The result was a serious damn accident causing multiple
deaths. The company was been charged with (I think) “criminal negligence
causing death.” The operators where also charged.

In the U.S., there was a case where a bot-net operator attacked a hospital, and
closed an intensive care unit. This did not cause any fatalities.

In my own experience, I have seen some questionable engineering leading to
adverse situations. (No fatalities yet.)

Goals for Law

As an engineer, I would like blanket access to all source code and electrical
schematics that can be implicated in any machine motion potentially threatening
a machine operator with bodily harm. On some of the networked machines that I
have seen, this exemption would effectively give me access to large amounts of
source code, as the user interface on many machines is implemented with
Microsoft Windows or Microsoft Windows CE.

From a practical point of view, especially looking at how U.S. IP law is
evolving, I cannot envision a broad “safety” exemption being implemented.
Further, as a point of multi-national law, it can be difficult as a Canadian to
compel a foreign (U.S.) company to release trade secrets. The trend to
increased interoperability, integration and network aware machine tools
continues. Ultimately, safety and software will have to come into conflict,
with potentially fatal consequences.

Conclusion

The entire area of interoperability involving safety critical equipment is
complex.
a) Vendors don't want to give proprietary information.
b) Customers that require the proprietary information, sometimes for legal
reasons.
c) Long-term maintenance and upgrade problems are present.
d) As a customer and an engineer, I would like many more rights to compel a
company to release key information, particularly all information involving
safety.
e) Interoperability, network aware applications, and user safety are conflicting
goals requiring a level of engineering that is not being widely implemented
yet.

[ Reply to This | # ]

Due Diligence
Authored by: Peter Baker on Saturday, September 16 2006 @ 03:12 AM EDT
I used to be a Management Consultant (who, incidentally, has once reviewed
Masons :-) and I've been involved in quite a few Due Diligence processes
supporting investment advice (I look at the IT side of things with a couple of
analysts, which is often neglected in a finance inspired acquisition plan - I
did this so often my record is now 3 companies in 2 weeks :-). Integration was
one of the most important things to review (as is IT platform age).

A pre-merger review has to look at how easy it is to integrate, but if you're a
company planning to go on an acquisition tour you have your own work to do as
well. There are strategies possible that can cut to over 50% of your IT
downtime (due to integration) post acquisition. If you've implemented such
strategies it actually changes the due diligence process slightly because you
have more control over the variables that could introduce risks in the process.

This also goes for security management and audit functions - if you're prepared
for a merger strategy you can prevent a considerable amount of downtime, costs
and risk exposure.

Q: are you guys in the Masons building itself in the City? If so I may be able
to visit on Monday - I happen to be in London that day for meetings :-).

---

= PB =

"Only a man can suffer ignorance and smile" - Sting
(Englishman in New York)

[ Reply to This | # ]

Relevant cases
Authored by: marbux on Saturday, September 16 2006 @ 03:27 AM EDT
On the Groklaw Micros oft Litigation page, see the links regarding the following cases that raise issues of the type you discuss:

  • Microsoft v. Commission of the European Communities

  • European Commission anti-trust case

  • Novell v. Microsoft (antitrust)

  • Real Networks v. Microsoft

  • Sun Microsystems v. Microsoft (2002 antitrust case)

On the same page, see also:

  • Microsoft patents ASF media file format, stops reverse engineering

  • Microsoft Patents Web Standards

  • List of patents threatening open source

---
Retired lawyer

[ Reply to This | # ]

Requiring documentation
Authored by: Anonymous on Saturday, September 16 2006 @ 05:43 AM EDT

Forcing authors to provide document after the fact is a waste of time because:

  • There may never have been any documentation.
  • Even if there was, there is no reason to assume the software worked as documented.
  • Even if it did, the is no reason to assume the next version will do the same thing.
  • Next, some people consider £250,000 is a reasonable fee for documentation.
  • Some people think that a royalty is reasonable.
  • Who is going to check that the documentation is accurate.
  • What are you going to do about it if it isn't.

If you are going to pay money for software, you should make sure that you only pay if the software passes an agreed site acceptance test, and that you have the right to get the software fixed elsewhere if it subsequently proves to be broken.

[ Reply to This | # ]

Another Request to Pick Your Brains - Re Interoperability
Authored by: PeteS on Saturday, September 16 2006 @ 06:50 AM EDT
The [small] company where I work makes a number of things for the commercial
vehicle market, including an XDA, and one of our sales channels is VARs.

We licence the API to them so they can integrate their own applications into it,
but they have to have their own licence for the base OS (WinCE in this case
[1]).

Our sales to VARs is quite lucrative; I believe we sell more units to them than
we sell to our direct customers and my view is non-discriminatory API licencing
is a plus.

As we provide the API which wraps up the hardware interface in a simple manner,
we do not release information about the specifics of the hardware implementation
which includes quite a lot of HDL code in a FPGA; we do release information
about the functionality provided, however.

My view is it's not not an eay question to answer as to how to encourage
interoperability (note I say encourage, not require). If we suddenly got an
order for 100k (hey, let's be optimistic and say 1MM!) units with special
hardware / software features I doubt we would release the details of those to
any except the actual customer, and then under an NDA.

Taking the view of the hardware designer [me], I can see utility in licencing
the functionality provided, but I can also see very good reasons not to release
schematic / layout information. One of the reasons our customers like our unit
is it does things in certain areas very well, where our competition struggles,
apparently. Much of that is in the base hardware design [2] and as such is a
major competitive advantage that we desire to keep to ourselves. So here, I can
see the advantage of keeping specific implementation details secret.

As this is a closed box with limited (and specific) interfaces, there is little
need to disclose the internal details unless someone wished to put a different
OS on the unit. In that case, we would probably ask how many they wanted to buy.


Mercenary? perhaps; but there is a large investment in a finished product (at
the hardware as well as the software levels) that needs to be recouped and that
has to be kept in mind.

So the law needs to encourage interoperability; that's where the difficulty
lies, imo.

[1]The OS decision was a commercial one based on certain third party
applications were already available which happened to lead us to WinCE in this
particular case.

[2]The hardware layer is more than a matter of choosing components, as any
experienced designer will tell you. There's system functionality, power
management, layout techniques, regulatory requirements and a host of other
things involved to get a product to market. My company pays me because I know
how to navigate those things. They are hardly going to give away results that
they have paid me to implement for them. Apparently simple differences between
different hardware can yield astonishing differences in operational results.

PeteS


---
Only the truly mediocre are always at their best

[ Reply to This | # ]

Some standard interoperability failings
Authored by: Anonymous on Saturday, September 16 2006 @ 08:00 AM EDT
Standard ones:

Microsoft exchange only works with outlook for managing distribution lists. The
data about who is in the distribution list can't be cut and paste; it can't be
exported in text format. There is no standard interface for extracting it.
This makes it very difficult to move over to another platform which might, for
example, support automatic list management with them.

Powerpoint fails to export graphics in full resolution in any format other than
it's internal .ppt format. This makes it very difficult to use powerpoint
slides as the basis for other work.

There is no real standard file system format which is supported by many
operating systems.

[ Reply to This | # ]

Web Standards
Authored by: berf on Saturday, September 16 2006 @ 09:53 AM EDT

Consider web standards: HTML, XHTML, and CSS. Firefox, Konqueror, Safari, and Opera implement them very well. Microsoft Internet Explorer is very bad at them. Microsoft promises to do better, but we will have to see. Current beta versions of IE7 do not come close to competing browsers in standards compliance.

Every good book on web design tells you (1) how to do it right (valid HTML and CSS) and (2) how to junk up your web pages with workarounds for IE lossage. Microsoft makes web design an enormous pain.

An old army saying, there's three ways to do anything: the right way, the wrong way, and the Army way. In computing, there's three ways to do anything: the right way, the wrong way, and the Microsoft way.

Microsoft's business model seems to be to cause pain to anyone who isn't paying them money. If there is an existing standard, they break it or invent a competing standard and use their desktop monopoly to force the rest of the world to deal with their lossage.

  • Java. First they try to break it. Sun sues them. They have to stop. So they invent an inferior competitor: C# and .Net.
  • ODF. They go straight to inferior competitor.
  • HTML + CSS. They are broken. It remains to be seen what they will do.
  • NetBIOS, SMB, etc., the protocols underlying Microsoft networking, which Samba tries to reverse engineer. Originally developed by other companies, Microsoft broke them and refuses to document them, even under extreme legal pressure in the EU.

Microsoft. Your pain is their gain.

Can they be forced to divulge? So far, no.

[ Reply to This | # ]

Wrong approach. Learn from history.
Authored by: hopethishelps on Saturday, September 16 2006 @ 10:13 AM EDT

license interface information on commercially reasonable terms to allow interoperability.

This is completely the wrong approach. It is the monopolist's dream.

IBM held a near-monopoly in the 1970s on computer hardware. And the interfaces to its computers were proprietary. It would have loved to charge license fees on the details of its interfaces, for example the interfaces of its 3270 cluster controller (these interfaces are still in use, and a brief introduction to what they do can be found here). However, the courts ruled that a company which reverse-engineered the interface could legally ship compatible products without paying license fees to IBM.

It is completely unreasonable to award a company "license revenue" on an interface which is based purely on arbitrary choices. For example, if you have to send an 8-bit character one bit at a time, the interface protocol has to specify what order you send them in. There's no "invention" here. You just pick an order. Then everything that uses your interface has to use the same order. Having to pay a license fee to do that is absurd.

The parts of the computer industry which innovated fastest are the parts which were based on open standards. The Internet is the best-known example. All the Internet's many interfaces are fully described in documents known (for historical reasons) as "RFCs" (a complete list can be found here - and in many other places).

The tradition of open standards has been effectively attacked by Microsoft, which has partly succeeded in establishing closed, proprietary data formats and communications protocols as de facto standards. Examples are: the format of Microsoft Word files, Microsoft Excel files, and Microsoft Powerpoint files; the format of an NTFS file system; and the communications protocols used within Microsoft network domains. All of these have been, to varying extents, reverse-engineered at the cost of great effort by very able people, but this is a losing strategy for us, because Microsoft, owning these interfaces, can change them at any time without telling anybody. And it does so. Consequently, someone who really regards Microsoft file formats as "standards" must use Microsoft software. OpenOffice's implementation of .doc and .xls file formats will fail whenever Microsoft chooses to change them, and will stay "broken" until OO makes the needed changes. It's like running a race, where one competitor (Microsoft) can move the finishing-post in any direction at any time it wants. Anyone competing against Microsoft on these terms must lose. Similar comments apply to Samba, brilliant work though it is.

An ideal solution would be for a large government, and today that means either the US government or the EU, to decree that all government agencies must specify data formats and communication protocols to which all purchased software must conform. If a new application which requires a new kind of data format is developed, it must be supplied with complete, open, royalty-free specifications of its file format.

At one time, all software was like this. I even have an old (1986) Microsoft MS-DOS Programmer's Reference Manual. It documents, in detail, the format of the FAT file system; the format of an MS-DOS executable (.EXE) file; the format of Intel relocatable object files, with Microsoft's extensions (you need this information to write a compiler for MS-DOS), and much, much more. Of course the free availability of this information enabled many small companies to write software for MS-DOS, contributing to its success.

But now that Microsoft has a monopoly, it doesn't need all those other companies writing software. More third-party software won't help it to get much more market share for the operating system, because it already has 90% market share. Charging "license fees" for interoperability information would be a win-win scheme for Microsoft - effectively, its competitors would have to pay it money for the privilege of competing! How can anyone outside Microsoft fall for an idea like that?

[ Reply to This | # ]

Another Request to Pick Your Brains - Re Interoperability
Authored by: Nick_UK on Saturday, September 16 2006 @ 10:25 AM EDT
Being an unfortunate indigenous Englishman, I ask how
anybody can get the law 'changed' unless you are a member
of government that has a full backing of those in power
and breaks the rules to get it pushed through.

The question is totally irrelevant as law cannot be
changed by the hoi polloi.

Nick

[ Reply to This | # ]

Microsoft Front Page Extensions... limits web sites to MS only stuff!
Authored by: Anonymous on Saturday, September 16 2006 @ 11:10 AM EDT
3 Web stories.

1st example:

I know of a small business that had a version of MS office that had MS Publisher
2000. They used it to do an easy WYSIWYG web page that grew into a 17 page
site, and one of the things that their web site host had to do... was to set up
the site on the host to support Front Page Extensions.

Ok - that was done... then later on they wanted to add some other web page
enhancements, that were not Microsoft product based, and were told that they
could not add this new and cool stuff, as the stuff that they put up could only
be Microsoft stuff using ONLY the Front Page extension tech. They were told
that they could not load stuff onto their site by FTP. OUch.

So - because they wanted the new stuff up so bad (that was not Microsoft
software generated), they weighed their options and concluded that they had to
totally redo their site using a tool that did not use MS Front Page extensions
AND THEY ARE MUCH happier now. They actually changed web hosts, kept the old
site running, built the new site and then migrated the domain to the new
location. BUT, they were not happy to discover that they were Microsoft
"locked into" to a work product investment, that they had invested in
simply because they were using a Microsoft Web page building product to begin
with. They were dependent on Microsoft totally for their web presense it seemed
and Microsoft it seemed did not have as good a product for them as others did.
SO - in the end, it cost them a lot of Labor cost and redirected employee
efforts from other more important projects, in order to get this web site redone
and migrated (all done by in house staff as outside folks really did not get
their message that they wanted on the site at all, so they had to resort to
inhouse who knew the message and had to learn new tools to translate the message
into a web site presense that they could move forward with) and now they can
pretty much go any direction they want (and they are not dependent on Microsoft
anymore to do it)... but, they have learned a lesson, and they found out that
Microsoft is not supporting future upgrades to MS Publisher, so their investment
in any other documents they had with that application are short lived as
well...! So, they are looking into using the Open Source OpenOffice.org,
Scribus (runs on Windows, Apple and Linux), and NVU web tools and other FOSS
tools as "long term value solutions" that seems to give them a high
value due to lack of lock-in, and lower cost investment in upgrades to software
versions that they have a "choice to more to if they want". They are
also looking at Novell SuSE, and some other supportable FOSS tools that don't
have "lock-in" as part of their feature list ( so that if the original
FOSS developers/vendor does not support the application anymore that the
application can still live on with others able to pick it up and move forward
with development and/or support).

2nd Web Story:

I know of another small business where almost all the vendors that this business
depends on for product (they must use each vendor's custom in-house built online
order/data history system to conduct business with these vendors), most of the
vendors in this industry that the small business is in, if not all the vendors,
today REQUIRE THE USE of MS Internet Explorer and a version of Windows Operating
system of a certain minimum version (that will also support a mininum IE
version)! And different vendors sometimes require a newer version of IE while
other vendors are still stuck on an older version of IE as their minimum. The
vendor(s), actually more than one in this case, are using MS ActiveX parts as
part of their online processing front end, and it seems from discussions that
have been had with the vendors, that the vendors have a sizable investment in
this proprietary software web trap, along with a big investment in labor
training costs to use the Microsoft tools. So - they are hesitant to more away
because of the investment they have now in Microsoft (both software and trained
labor investment that know how to use and support Microsoft proprietary based
offerings and tools)! Of course they are victims of the MS trap, and they know
it, but budgets will not allow for migration very easily as managers way up
don't sometimes understand the issue enough to support a full migration away
from the Microsoft trap.

Some of them know (the actual tech side) that they would be better off to use
non-Microsoft tools, and in the future a few might change, but right now,
everything in their eyes is working (and they got their jobs and the managers
who don't have a clue, don't suspect that they might be better off if not in the
MS trap), but, at the user end there is often sometimes problems because the
different setting of Internet Explorer that required for DIFFERENT VENDOR sites
(this means that the user sometimes has problems with different online apps that
they must use, and in some cases are having to constantly go into the IE setup
and make changes to accomodate different IE settings on occasion to get things
to work (that that different vendors seem to require IE to be setup as)?

The vendors that are using JAVA it seems are better adjusted to handle a wider
range of customer computer OS and browswer installs and setups, and the web site
interation with their customer's systems seems to be better, and allows for a
wider range of browswers to be used.

3rd example:

I know of a different small business that has vendors that allow finished order
printing of various documents, order copies, and receipts after one completes
their web forms. These local printed document require local .PDF printing (and
again some require ActiveX for this printing to happen).

They require different versions of Adobe PDF software to be installed on the
computer. This is a problem as some require the newest version, and some
require an much older version of the Reader (I think because they have not
wanted to pay for the cost make site changes and to upgrade), and this has
caused problems with newer version of Adobe not liking some stuff that came from
the older vendor versions. And support for those vendors are trained only to
say you must be using the older version of the software for everything to work
correctly. Not all of their problems are directly related to .pdf pringing
issues alone as some of the interoperability seems to be related to MS IE
settings that are different again per online vendor as well.

[ Reply to This | # ]

Customer lock in
Authored by: Anonymous on Saturday, September 16 2006 @ 12:34 PM EDT
I can think of a number of cases where important information has been tied up in
a proprietary database. EG I worked for an accountancy firm where all the Work
In Progress system used a proprietary format. Eventually they dumped the system,
which required a large amount of retyping. Another example of an accounting
system that locked you out if you didn´t pay the license fee. Which meant that
even after replacing it the company kept paying license fees so they could query
the debtors list and other reoprts.

Would this be covered by "interoperability"?

[ Reply to This | # ]

  • Customer lock in - Authored by: Anonymous on Monday, September 18 2006 @ 04:35 PM EDT
A big problem
Authored by: Alan(UK) on Saturday, September 16 2006 @ 12:46 PM EDT
A big problem can arise when a single company provides the hardware/software for
BOTH sides of an interface. Suppose one side of the interface (A) is an already
existing system with a well specified interface. Now the designer of the system
on the other side (B) makes his system work with the existing system. He does a
quick cut-and-paste job on the interface specification and the documentation is
done. Later, someone else re-engineers system (A) using the system (B) interface
specification. Someone else then re-engineers system (B), plugs it in to the
original system (A) and all the lights go out.

Example:
Original(A) pin 34 - 100 volts DC out (for future expansion)
Original(B) skt 34 - no connection
Revised (A) pin 34 - 12 volts DC out (for future expansion)
Revised (B) skt 34 - 12 volts DC in

This looks rather obvious, but suppose that there was an intermediate version of
(A) where pin 34 was - no connection?

Take another example - the good old RS232 interface. All the pin functions are
defined but most of them are usually not implemented. Trying to fool two
different pieces of equipment to work together used to be a nightmare -
break-out boxes and all sorts were needed to fathom it.

When I last tried it, Koffice could not correctly read an OO.org document
(multiple errors) and ODF is an ISO standard.

[ Reply to This | # ]

What a bad idea, except in the case of monolopy
Authored by: Anonymous on Saturday, September 16 2006 @ 01:03 PM EDT
Companies should be able to do business on whatever basis they choose. Any
business that does business should, at this stage of widespread computer
adoption, should be savvy enough to decide for themselves whether and what sort
of interoperability they want and at what price.

The only execption should be when there's a monolopy. In that case the
purchaser has, by definition, no choice and interoperability should be a
requirement.

Karl O. Pinc kop aaa-t meme d-ooot com

[ Reply to This | # ]

Right question, wrong answer IMO
Authored by: jbb on Saturday, September 16 2006 @ 02:55 PM EDT
IMO, open standards are even more important than free and open source-code. But laws and litigation are not the only tools available for solving problems like this. If they were, it would lead us to a condition similar to that found in T. H. White's ant colony where "EVERYTHING NOT FORBIDDEN IS COMPULSORY."

I'm reminded of the irony of the economic justification for advertising given in Econ 101, that the purpose of advertising is to educate customers thus allowing them to make better informed purchasing decisions. Of course, the real purpose of 98% of advertising is to do exactly the opposite. It gets people to buy things they don't want and don't need.

Closed standards are an incredibly bad deal for customers. If they knew the reality of the situation, they would not buy products that used and relied on closed standards unless there was an overwhelming reason forcing them to (such as already being locked into closed standards).

If there were to be a law to try to make standards more open, perhaps it should be more in the direction of truly informing customers. I'm not at all certain that a law is going to help, but maybe it would be useful to have a law (or maybe just a voluntary standard) that requires manufacturers to list the non-open standards in the products they sell and/or distribute, similar to the warning labels on bedding supplies and furniture.

Maybe somebody else has an even better idea. I've seen several posts above suggesting a large government use its purchasing power to promote open standards. Does anyone have a suggestion for what we can do to help educate consumers and thus harness their purchasing power to the support of open standards?

---
Anyone who has the power to make you believe absurdities has the power to make you commit injustices.

[ Reply to This | # ]

IInteroperability should not be required by law
Authored by: Anonymous on Saturday, September 16 2006 @ 03:41 PM EDT

"Should interoperability become a legal right in the US and EU?"

No. The current situation is fine where customers can choose to buy either closed systems or interoperable systems and vendors can chose to sell either closed systems or interoperable systems. There is a problem with monopolies selling closed systems and the law can intervene in these cases. The fact that the law is often ineffective in dealing with monopolies is an area where new laws might be considered.

Interoperability is very desirable from a user's standpoint. Users should vote with their pocketbook in favor of interoperability. Users should not use their political votes to vote in legally required interoperability. This would cause more problems than it would solve.

---------------------
Steve Stites

[ Reply to This | # ]

Hardware interoperability.
Authored by: katayamma on Saturday, September 16 2006 @ 04:55 PM EDT
Ok, I'm going to be called silly for this (probably) but here's my complaint
about the lack of documentation for interoperability.

In the ancient anals of history, when you bought a product such as a printer,
the manufacturer gave you all the documentation you could possibly want on how
to talk to that printer: Interface pin-outs, signaling, protocols, etc.
EVERYTHING!

Now, if I buy a printer, the only documentation I get says "Plug the cable
in and install our bloated software that wants to consume system resources when
you're not doing any printing." They've completely cut off any potential
development software to communicate with their printer from non-supported
systems.

I have an Amiga 3000 tower (oh hush up you!) and am using a USB device to allow
it to talk to basic USB devices such as a Wacom Tablet, mouse, etc. I have an HP
Officejet 5610 printer/scanner/fax machine. I'd love to be able to write code to
scan images into my Amiga and print them back out on the same printer. I could
do that with my old HP scanner and printers from the 80's, but not with the new
stuff.

It really bugs me. I hate having to conform to what a hardware manufacturer
decides is best for me. It would be like buying a car only to find out that I
had to hire their driver otherwise the car would be useless.

Blech.

---
Never underestimate the power of human stupidity.

[ Reply to This | # ]

Roblimo had an article that was pretty good about this same thing!
Authored by: Anonymous on Saturday, September 16 2006 @ 05:37 PM EDT
Here is a good article that covers the same waterfront with comments from readers that followed.

Why proprietary software is dangerous for business-critical applications Monday August 28, 2006 (05:00 PM GMT) By: Robin 'Roblimo' Miller

"A friend of mine is the IT manager for a medium-sized wholesale distribution business. One afternoon in early August, a hard disk drive in one of his employer's servers started to show signs that it was dying. That hard drive contained the company's (proprietary) credit card processing software, which was chosen specifically to integrate with the company's (proprietary) inventory control and accounting software package. My friend -- we'll call him Stan -- didn't think the problem was a big deal. He'd just reinstall the card-processing software on another hard drive, move the customer data he'd wisely backed up onto the new drive, and go home for the day. That was before he called the software company that had sold his employer the card-processing program -- a call that left Stan and his boss angry and confused...", (for more read the link to the url in the title above)!

AND READ THE COMMENTS THAT FOLLOWED THE ARTICLE ON NEWSFORGE!

THIS is the kind of story you need... (but, you might need to talk to Robin to be able to republish it)!


[ Reply to This | # ]

The Law is too Slow
Authored by: urzumph on Saturday, September 16 2006 @ 05:37 PM EDT
On Principals, I think it's a nice idea.

In practice, it is going to be totally worthless.
The law is far too slow to be anything but a hinderance to IT.
Look at SCO vs IBM, look at US vs MS, EU vs MS, etc.

If a court case takes anything more than about a year to rule that
interoperability is required, chances are it will be reverse engineered before
the company creates the required interoperability anyway and we are back to
square one.

The law just moves too slow to be of any use.

[ Reply to This | # ]

Let the Free Market do its Thing
Authored by: mlaiosa on Saturday, September 16 2006 @ 06:06 PM EDT
If the consumers of software genuinely want interface information, let them say
so with their wallet. Software exists in a competitive marketplace. If
interface information is important, consumers will buy products from vendors who
provide it. If vendors recognize that interface information provides more value
to their products than it costs, then they will make it available. If software
consumers don't want to pay for the interface information, we certainly don't
need a law to force them to pay for it.

Interface information comes at a cost. Most software interfaces are not well
documented. Knowledge about the interfaces is partly stored in the minds of the
developers, and partly stored in the source code. Extracting knowledge from
someone's mind is slow and error prone. My grandmother used to make an
excellent fruit cake [1]. Your grandmother probably makes the best something
that you've ever had too, be it fruitcake, shortbread cookies or yorkshire
pudding. Have you ever tried asking her for the recipe? She wont be able to
tell you how much flower or butter or sugar to use, or how long to cook it for.
She might even forget to tell you about the baking soda. She gets all this
right when making her fruitcake, but its different to use knowledge than to
regurgitate it. The point, in terms of software interfaces, is that it is
insufficient to just ask the developers to document what they know about an
interface, but one must also test and review that documentation, which adds more
time and expense.

Extracting knowledge from source code is just as challenging. Interface
information in source code is intertwined with information that should not be
disclosed [2]. Extracting it requires a developer to read the source code.
They must separate the interface information from the rest of the information
conveyed by the source code. They must understand the context in which the
interface information exists, and they must reproduce that context in English.

All of this requires a developers time, and in particular, a developer who is
familiar with the interface. Having developers spend time to do this is more
expensive than just the salaries of the developers, technical writers and
reviewers; the real expense is in opportunity cost. These developers are the
same developers that could be writing new features and fixing bugs. The cost to
a company of pushing back a release can be immense. Its well known[3] that you
cannot simply hire new developers to keep your release on schedule. Consider
all the software on consumer devices and games that are going to be released
between now and Christmas. Think of what it would cost a company if their
product didn't get released in time for the Christmas shopping boom.

One might argue that these costs can be eschewed if interface documentation is
produced contemporaneously with the interface itself. But, in fact, producing
documentation as you go doesn't avoid the costs but merely amortizes them. The
cost of producing the documentation still exists, developers must still take
knowledge of the interface and articulate it in English, it must still be
separated from proprietary knowledge, it must still be reviewed and tested.
There are some benefits to the developers of having this interface documentation
available to them while developing, but they hardly mitigate the cost of
producing the documentation. The software knows the interface, and it is rarely
necessary for the developer to know it too. Consider the Windows BMP file
format. The file contains exactly what is needed to call the Windows API
function to display it on the screen.[4] Nobody writing Windows software needs
to know the format, but only that it is the same as what Windows expects.
Windows isn't alone. The binary interface between a Linux application and glibc
shared libraries is not documented. A developer doesn't care though. The
compiler will generate an application that correctly interfaces with their
particular glibc.[5]

The free market is a powerful force. Software companies will spend what is
necessary to create and provide interface information if their customers really
want it. The product I'm employed to work on has not, historically, come with
interface information. Enough of our customers have told us that they want it,
so we're spending the time it takes to make this available to them at a
reasonable price. To do this, we needed to create a fixed interface. Most
software interfaces are in a constant state of flux. They change daily as the
software changes. Developers don't mind, because the software still works with
itself, and more importantly it allows the interface to adapt easily to changing
requirements. For the product I work on, our fixed interface has taken close to
a year to develop. Before it was even finished even there were features in the
dynamic interface that didn't exist in the fixed interface. We accepted the
cost of creating, maintaining, updating and supporting the fixed interface
because we believe our customers will pay us a premium for the ability to use
it. If it turns out customers don't want to pay a premium for it, we'll stop
maintaining it and have our energies work on things customers do want, such as
making our product faster. If there were a law requiring us to have interface
information but customers didn't want it, we couldn't spend time making our
product faster instead.

Monopolies are well known to be able to break the free market control loop.
Microsoft is probably the largest software monopoly.[10] The state of
Massachusetts (MA) recently decided that it didn't want to buy office software
that didn't come with interface information[6]. Microsoft tried to talk them
out of it. But in the end, MA is a large and important customer of Microsoft's,
so Microsoft decided to open up interface information for Microsoft Office.
Even Microsoft is subject to the free market. PJ brought up Samba, but I think
Samba is a great example of my point. Where are the hordes of Microsoft
customers saying that they won't buy Windows without SMB/CIFS interface
information? Where are the many customers that buy Windows but choose an
open[7] network[8] file[9] system? I don't think there are very many Microsoft
customers who care. Windows works with Windows, and thats good enough for
them.

No law says that car makers need to make a sedan that gets decent gas mileage,
can go from 0-60mph in 6 seconds, has side and curtain air bags, or will
automatically turn your headlights on at night. Yet, I have all these features
in my car. Why? Because they are valuable to me. Automakers recognized that
many people value these features, and as a result, there are a number of sedans
on the market with all these features. People said they wanted these features
by paying more for cars that have them. Just like car companies, software
companies exist because they make products that people want to buy. If people
really didn't want to buy software that doesn't come with interface information,
they wouldn't. Lets not force everyone to pay for interface information.


[1] I'm serious. It wasn't until my sister-in-law sent me a fruit cake for
Christmas last year that I understood why most people hate the things. And my
sister-in-law is an excellent cook.

[2] Some people when they hear the word proprietary immediately say, "No
problem, just open source the whole thing!" But every piece of software
I've ever been paid to work on couldn't be open sourced, even if the company
that wrote it wanted to do so. Usually this is because the source code contains
information that was obtained under an NDA, but its been as exotic as the DoD
not liking you to open source the software that runs on an F-16.

[3] Frederick P. Brooks, Jr. The Mythical Man-Month. Addison Wesley, 1978.

[4] A BMP file roughly consists of a header followed by a bit-for-bit copy of of
the BITMAPINFO structure that is passed to the API function CreateDIBSection,
and then followed by the image data itself, which is in the same format as is
expected by the SetDIBits APU function.

[5] Because glibc is open source, and because the interface is generated in a
deterministic way (parts of which are well documented), the determined engineer
can figure it out. This is all related to why one cannot necessarily take a
binary from one Linux distribution and run it on another, but instead must
recompile it.

[6] The Massachusetts (MA) law requires MA itself uses software that has
interface information. It is a law that controls MA's own behavior, it doesn't
require any software company to do anything. It is no different from than a
corporation deciding to use only software with interface information. It is
critically different from a law requiring software makers to provide interface
information.

[7] http://en.wikipedia.org/wiki/Network_File_System
[8] http://www.coda.cs.cmu.edu/
[9] http://wwww.openafs.org

[10] The characterization of Microsoft as monopoly always seemed questionable to
me. I'm composing this article on a Mac using TextMate. When formatting is
important, I use LaTeX. At work, I use Linux and OpenOffice.org. Microsoft has
always had competitors: CP/M, DR-DOS, NetWare, OS/2, WordPerfect, Lotus 1-2-3,
BeOS, NeXTSTEP, ClarisWorks, DBASE. Thats not to say that Microsoft isn't a
dominant player. And its certainly not to say that they didn't gain and don't
maintain their dominance through anti-competitive practices.

[ Reply to This | # ]

Questions
Authored by: Savannah on Saturday, September 16 2006 @ 06:38 PM EDT

Interface information is usually set as some standard, whether that standard is
published or not. Is this article considering defacto standards (greatest
market share) differently than other standards such as 'open' standards, or
government set standards?

Is the article going to discuss how 'interoperability' is defined?

In many cases a standard allows for interoperability, but there are often
'implementation options' that are different enough that two products that claim
to meet the same standard may have different options enabled such that they
aren't necessarily fully 'interoperable'. Will this be allowed or
"policed" to ensure that there aren't any incompatible options?

Does the term interoperability also mean 'backward compatible' to a previous
version?

Many companies offer 'partnerships' where you get the inside info to ensure
interoperability. In some cases you pay money, in other cases you submit your
product for some testing.

Since many companies now already offer a scheme that allows others to
'interoperate', how would creating a law make it different? Is the assumption
here that the law would force ALL interface info of every product to be
available than currently exists?

What are the possible side-effects of this law? Would there now need to be a
government agency that sets the price of interface licenses?

-Savannah

[ Reply to This | # ]

Another Request to Pick Your Brains - Re Interoperability
Authored by: Anonymous on Saturday, September 16 2006 @ 08:27 PM EDT
What a stupid idea -- trying to force people to be interoperable.

(1) It will not work.
(2) Any attempt will cause major harm to small developers.

This is an idea that could only please Microsoft. They have enough lawyers and
money to falsely accuse any small outfit of "non-interoperability",
while at the same time generating mounds of paper for their own products giving
the appearance of interoperability, while actually not providing it.

In general such a law would act only as a tool for busybodies to harrass those
who are trying to create something new and useful.

Interoperability is a quality that cannot be precisely defined, nor can it be
readily ascertained by examining a product. Some interoperability is good and
easy to do. Other interoperability is extremely difficult and of no benfit and
possibly even harmful. There are intense disagreements on open source project
mailing lists about such choices. It seems impossible that government
regulators could add anything useful or even technically relevant.

Any legal definition could only be based on superficial characteristics, which
would very quickly become obsolete with respect to changing technology.

In general we all agree that honesty is good. But we do not have laws trying to
force people to be honest.

As a small businessman, I spend way too much time already filling out government
forms. I can just imagine (with dread) a new form to fill out to evaluate and
report my project's interoperability with 1000's of other software products.
The time needed for evaluation would be astronomical. Technical errors would be
inevitable. And since my project is open source, I would be subject to second
guessing by Microsoft robot generated complaints.

Interoperability costs money. When you are just starting a new product you want
to be able to release it as soon as it does something useful. Imagine I develop
a useful new product. I want to release it. But I can't get permission because
it is not interoperable. This could kill the product.

My message to the government is to not try to help me. Just leave me alone.

Bert Douglas

[ Reply to This | # ]

Why legislation might be a bad idea.
Authored by: kh on Saturday, September 16 2006 @ 10:41 PM EDT
Many years ago there were many different networking systems. There were
different link layers with their networking interfaces, different linking
hardware, different protocols. Almost all were proprietary and expensive. I
certainly only dealt with a few. Ethernet and IP were open formats.

As ethernet/IP got more popular it overtook everything else. Gradually we put in
gateways between proprietary networks and IP and the proprietary died out.

They all died out because they were encumbered and closed formats. TCP won that
battle because it was open and unencumbered and because lots of people worked at
making everything interoperate. They still do.

Did this need legislation? No. Would legislation have helped? I don't know.
I think it may have hindered as much as helped. It was a process where the
market and lots of other things decided the best solution. The result was not
as obvious then as it is now in hindsight.

[ Reply to This | # ]

It's a moot point in part - the legislation already exists
Authored by: Anonymous on Sunday, September 17 2006 @ 04:36 AM EDT
Reverse engineering may not always work and there are limits on when it is lawful.

This is not true in Europe. (the latter bit)

European law (applicable in the UK) already explicitly allows reverse engineering (within certain, IMHO reasonable, limits) for interoperability purposes.

Specifically: Council Directive 91/250/EEC, article 6.

Your right to do this cannot be restricted by an copyright license, and any EULA clause stating otherwise is void in the EU.
(I've noted that at least some software companies have wisened to this fact and remove such things from the European versions of their EULAs. Or added a clause stating that that clause is "void where prohibited" or similar.)

This directive is implemented in the national legislation of all EU member states.

As for interop in general, I don't think there's real reason for legislation. In a diverse marketplace the vendors aren't big enough to turn something into a de facto standard without letting others in on the specifications. At worst, they could form a cartel, but existing competition laws deal with that scenario already.

The exception that proves the rule is of course Microsoft. Their monopoly position allows them to create de facto standards without any outside participation. But the existing anti-trust laws seem to be working in Microsoft's case. At least in the EU.

[ Reply to This | # ]

Who gains?
Authored by: MindShaper on Sunday, September 17 2006 @ 09:05 AM EDT
The only purpose in preventing interoperability is to prevent competition. When
is this a benefit? When the company doing so wants to make money from their own
hard work. The question is, how much money is too much? When does old-fashion
"make a product, make a profit" become unreasonably monopolistic?
When someone tries to use the fact that they invented something to stop other
people from doing what would otherwise be legal.
By definition, the interface is on the "outside" of the product, the
way windows are on the outside of a house. It's not illegal to look into an
open window, it should not be illegal to make a product that can use an
interface.
Should a company be allowed to make others pay to know about or use a window on
a house? No, never - and a company should never be allowed to censor information
about the outside of their products.
Should a company be allowed to charge money for publishing information about an
interface? Just like any other book or add-on product, yes.
Should a company be allowed to censor information about the interface? No,
that's like putting a window into a secret laboratory and then suing anyone who
sees your secrets.
If a company can not profits on the merits of the product itself, they will try
to extend their profits by locking in customers and locking out competitors.
The *only* reasons this is even an issue are:
1> Courts and lawmakers have trouble seeing past the technology to the issue
as it really is;
2> Companies have used 1> to get decisions that allow them to create the
false impression that interfaces are secrets.

---
There's a difference between being free and being unnoticed.

[ Reply to This | # ]

Interoperability is not the real issue
Authored by: yscydion on Sunday, September 17 2006 @ 10:28 AM EDT

As far as I am concerned, it is not interoperability itself that is the issue, the issue is holding hostage data owned by someone else.

I think that the significant examples all really come down to cases where the owner of data stored in some proprietary file format or proprietary processing system is denied access to their own data unless they pay extra to whoever has managed to insert themselves as gatekeeper. Proprietary formats and protocols are not necessarily wrong in themselves but it is wrong to use them as part of what is really a kind of low grade protection racket. Seen from this point of view the so called "commercially reasonable terms" look more like paying off the racketeers so that they don't interfere with your business.

I think that if the principle were established that you may not deny people (or companies) free (in both senses probably) access to their own data then this would imply a sufficient degree of interoperability. This approach does not compel companies to reveal their proprietary formats or protocols provided that they offer a sufficiently functional alternative.

[ Reply to This | # ]

SlashDot - A better place for requests
Authored by: jcjodoin on Monday, September 18 2006 @ 06:32 PM EDT
Is it just me, or are these requests for information better
server at SlashDot.org?

It seems to me that SlashDot always has a feed a few times
of various people asking various technology styled questions.

I'd be less miffed, but the last article that was written
did not mention ANYWHERE that the information came from a
bunch of Groklaw readers / posters / members.

Just my two cents,

jeffrey

[ Reply to This | # ]

Interoperability *already* is a legal right
Authored by: Anonymous on Tuesday, September 19 2006 @ 03:23 AM EDT
I would see it as an extension of Common Carriage. Common Carriage is firmly established in telecommunictations and, since this is ICT we are talking about and the C stands for Communication, it applies here, too.

So continuing to call it Common Carriage gives us a few hundred years of precedents and established practices to work with. Letting opponents reframe the discussion as 'net neutrality' or some other rot means in contrast that it's somehow new and therefore unproven.

It didn't matter so much when there were many small players, like in the 1980's and the first half of the 1990's. However, now all the small software firms and small ISPs have been gobbeled up. These remaining Really Large ones now seek to remove Common Carriage, or at least the parts that prevent them from fighting it out to the end with the remaining competitors until there is only one left.

Look back to the mid-1990's and see how much effort and resources were expended by these same interests to use Common Carriage to protect themselves from being responsible for the content they were transmitting or hosting. Taking that metaphor a decade forward, we can look at most of the commercial software and see that it's getting more and more like a company hosting our data on our machines. It might be possible to work from the starting fact that it is already established that Common Carriage applies to hosting. So it would be obvious that it should apply to the hosted services that are getting hyped so much nowadays. However, even basic productivity packages (such as the much hyped and yet undelivered MSO 2007) are starting to get tied to various servers and remote services. That, too, seems obviously well across the line and under the category of hosted communication.

[ Reply to This | # ]

What are reasonable terms? -- Another Request to Pick Your Brains - Re Interoperability
Authored by: Anonymous on Wednesday, September 20 2006 @ 06:40 AM EDT
"commercially-reasonable terms"

Microsoft has agreed to license it's stuff on "commercially-reasonable
terms", and the judge accepts the terms MS proposes, but the terms are
still totally useless for GPL licensed code because you can not assign the
license to a successor. So even if you pay to use whatever it is, everyone has
to come back to you to get whatever it is you are using. As a result, no one
can innovate on your design.

[ Reply to This | # ]
Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details ) 		Site layout based on Woodlands theme by Bryan Bell.
Groklaw logo by John Crowley.
News Picks logo by Ted Thompson.
Powered By GeekLog
Created this page in 0.05 seconds