MS Office for Linux?
John Chambers
jc at trillian.mit.edu
Mon Apr 3 13:53:33 EDT 2000
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01BF9D8C.EF927B80
Content-Type: text/plain;
charset="iso-8859-1"
> I can't belive the government can force a software company to
> deliver a product to a "random" platform.
I have trouble believing it, as well ... I'm not a lawyer, but this kind of
remedy just doesn't pass my smell test.
Heh. Maybe you should ask a few lawyers. The is a great deal of legal
precedent for governments doing this sort of regulation. For example,
if I buy a package of light bulbs with the usual sorts of screw base
that you find here in the USA, I can screw it into an outlet in my
house and, aside from an occasional "sample defect", it will work.
This requires all sorts of standardization that is (legally) enforced
by the gummint. This includes the fact that the wiring in my house is
AC within a narrow voltage range. The power company is legally
obligated to supply this voltage; the light-bulb manufacturers are
legally obligated to make bulbs that work with this voltage. GE, for
instance, can't claim that I'm misusing my bulbs by scrwing them into
a socket connected to a power company that they don't own.
(Brief pause for the usual jokes about programmers and light bulbs.)
Similarly, you can go into an electronics store and buy a phone, take
it home and plug it it, and it will work, even if your wiring and
phone service was provided by a competitor of the phone manufacturer.
I have a Southern Bell phone that works just fine on a Bell Atlantic
outlet. This didn't happen because of the magnanimity of these phone
companies; it happened because the US goverment enforces regulations
that require this sort of compatibility.
Power plugs are an important example: Nearly every country has very
strict laws on power plugs, so that you can't accidentally plug some
gadget into the wrong voltage. A product sold in the USA with a plug
that fits the 120V outlets had better accept 120V, or some serious
fines may be in order. A manufacturer can't claim that it is using
its own "standard" for such things.
For another example, this and many other countries have all sorts of
laws concerning making things child-safe. If I buy toys or clothes or
a car seat, and they injure a child, the manufacturer can't say that
it's because the child is the wrong race or ethnic group. Products
intended for children have to be compatible with all children, not
just the children of the products' manufacturers.
Another instructive case is the jumble of incompatible track sizes in
use by the railroads in their early years. Standardization didn't
come about because of the love of the railroads for each other; it
came about because many governments imposed standards and forced the
railroads and manufacturers to make their equipment compatible.
As for telling customers what's in a product, well, look at the long
(and growing) list of laws concerning labelling of food and medicine.
Manufacturers haven't ever provided lists of ingredients voluntarily.
It only happens when governments force it. Extending this sort of
revelation of "proprietary contents" laws to software is trivial, and
all the same sort of consumer-protection arguments apply directly. In
fact, this is a precedent that could result in all software being
Open Source. Do you like the idea of eating food that contains secret
ingredients? Do you like the idea of running software whose internal
workings are secret?
And we might note that the Internet arose through 99% US government
funding. They've taken somewhat of a stand-off attitude so far, and
let the Net develop as its users wished. But it would be easy for
them to say "Hey, wait a minute; we paid for the development of this;
we can damned well force standards on anyone selling products that
use it." And this could very easily extent to any software that has
any sort of inter-machine communication. This clearly includes all
extant office-automation packages. Legal control here is no stranger
than things like standardized paper and envelope sizes, or standards
for any sort of packaging.
It takes only a little knowledge of technological history to come up
with hundreds of such examples. There's no legal problem at all
extending this to software.
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).
More information about the Discuss
mailing list