Thread Subject: more on the "closed" issue

Return to this mailing list's archives

From: Jim Tobias
Date: Thu, Apr 26 2007 8:25 AM
Subject: more on the "closed" issue

I apoligize for the long delay in replying. I'm going to try to streamline
some of this
content; I hope Peter thinks I've done it fairly.

I also want to make it clear that we are using the iPod only as an example
of a product, and that
neither the iPod nor Apple is being criticized in any way.

On the issue of loading a different OS and screen reader onto an iPod, Peter
wrote:
> Fundamentally a "Windows PC" that has a screen reader added is still a
Windows PC. The screen reader
> uses the OS services of Windows; it isn't talking directly to the bare
metal."

I think iPod Linux isn't talking to the bare metal either. The problem is,
when one entity
makes both the "OS" and the "app", and holds the technical details close,
defining the boundary
between the OS and the app can be tricky. Do we want to get into those
definitions?

Let's remember that one original impetus for defining a product as "closed"
was that it
was a public device (e.g. ATM) to which no hardware could be attached or
software loaded
for security reasons. That is, even if the ATM was running a conventional
OS, 508 was not going
to require that a user could come along and install AT onto it.

But in this case, we are talking about a personal use device. Should we
want to limit what
a user can do to something that they own, and are perhaps the sole user of?
As the folks at
MAKE magazine say, "If you can't open it, you don't own it". I recognize
that there may be
support and warranty issues, but those can be addressed without eliminating
the heretofore
essential efforts of AT explorers and entrepreneurs to improve the
accessibility of
mainstream products.

Peter wrote:
> And the iPod isn't trying to be a general purpose handheld
> device - the only thing you are expected (and warranted) to
> load onto it is data - songs, notes, etc. Not software of
> any sort, let alone a replacement OS.

What you're saying is true, until the manufacturer decides to do something
else
with the product. The first iPods couldn't do video; now they can.
Companies have made,
and will continue to make, decisions about the "arc" of their products based
on their
own strategies. Those strategies will address accessibility somewhat, but
rarely will
it be a major driver; at least, that's been the experience up till now. We
have been
able to rely on AT only when the product has been more or less open, and
when the company
has shared information about its technologies with developers.

Peter wrote:
> I really don't think "ease of replacement/restoration" makes
> any sense as a measure here.

I agree that Gregg's suggestion is a better measure -- is the basic
functionality
still there. In this case, is the modified iPod still a portable audio
player? We're talking
about third-party efforts to improve the interface. As an example, the
native iPod
mode for recording voice messages is 8K sampling, pretty low quality. Linux
iPod
runs up to 96K. It could be argued that for hard of hearing people, 8K is
unacceptable.
Which is the "better" solution, to require Apple to change the feature, or
to allow users to
install Linux iPod? From the perspective of a federal procurement, either
or both
could be required. It's up to us to provide guidance on that.

As an aside, I have learned that it is easy to toggle between Pixo and
Linux:
http://www.macworld.com/2005/05/secrets/julygeekfactor/; scroll to the
bottom.

Peter wrote:
> Also, you note that Pixo is the OS (today) underlying the
> iPod, and ask
> whether anything changes if someone writes a screen reader for Pixo.
> But unlike the "iPAQ with Windows Mobile", Pixo isn't a defining
> characteristic of the iPod - anymore than a BMW being defined
> by VANOS
> (the BMW engine management system; you don't know or care about the
> engine management software, and if BMW were to change that, the car
> would remain a BMW; if someone were to replace the engine with a Ford
> engine, it would stop being a BMW).

I'm sure there are people who think that users shouldn't know or care
about the underlying technology of the products they own. It's just not
the case, however. A certain small segment of users are interested, and
they have made the preponderance of contributions to accessible ICT, both
AT and mainstream. It could even be argued that these user/developers have
driven much of the current ICT development in totality, not just regarding
accessibility. Do we want to create policy that, by ratifying Company A's
rights to define products as closed, limits Company B's ability to innovate?

I don't understand your examples. Gearheads do fiddle with automobile OS's,
usually to install performance-enhancing software features. Moreover, doing

this does not always void all parts of the warranty, especially when the
feature
in question is found in the manufacturer's OS in another country. And
people
do swap out all kinds of auto components; a lively aftermarket in
carburetors,
for example, could be credited not only with some outrageous street rods,
but
also with driving innovation.

I think the real potential problem here is if BWM decides to begin marketing
gasoline, first suggesting that "for best results, use only BMW fuels", and
then requiring it as a condition of the warranty. We know that such
vertical
integration is great for the company that pulls it off, but terrible for
other
companies, the economy, and consumers.

Peter wrote:
> Finally, you suggest that "a difficult and irreversible
> change would not
> alter the fact that the *hardware* product would have to be
> described as
> "open", compared to a typical calculator, for which such a
> change would
> be technically infeasible." The trouble with that logic is
> the notion
> that one might sell such hardware devoid of an OS, or that the vendor
> might design the product to not be open (you have to go through a
> number of warranty-voiding steps to run Linux on the iPod).

We are dealing here with a large customer, the federal government, and what
the policy of that customer should be. I would argue that the federal
government
could require maximal "openness" such that if the accessibility features of
the product as delivered were deemed insufficiently effective at allowing
comparable access, that the product be able to load and run additional
accessibility utilities or features, with exclusions as necessary to protect
the mainstream company from non-standard AT approaches, and an exclusion for
simple products like a basic (not HP-41c!) calculators.


> Finally, to your two numbered concerns:
>
> "1. That we not abuse the concept of an OS. If one company makes the
> hardware, the OS,
> and the application software, and constrains all changes to
> the latter
> two such that the company itself is the only party legally
> permitted to
> alter them, is that an OS?"
>
> I believe in this example, the product is a closed product -
> closed by
> design (vs. by policy). That it has a formal OS inside, application
> software, etc., doesn't change the fact that it is closed.
> It makes no
> sense to me to apply accessibility regulations to an OS that may be
> embedded within it - so I agree with you here on not abusing
> the term "OS".

"Closed by design" is not necessarily distinct from "closed by policy",
or "closed by strategy".

But I think the problem here is more than just a definition. "Closed"
products
are proliferating, and not only because of technological change. Companies
are, as always, trying to maximize their portion of the value of a product.
One way they do this is by excluding other value adders except as partners.
This is a
hotly debated trend. We see it in the debate over net neutrality; we also
see it in the dispute over what software can be loaded on a mobile phone.
In
both cases an "incumbent" company wants to have gatekeeper rights.

Imagine a nightmare scenario: all ICT products are single function products,
and they are all "closed". There are no general purpose computers. There
are no third party developers, except under contractual arrangement with the
dominating manufacturers.

What are the implications for accessibility? Manufacturers will install
certain
accessibility features, or arrange relationships with selected AT vendors so
that those aftermarket products can be installed. I don't think it's
possible
to argue that such a scenario would provide as much accessibility as the
current
environment does.

Peter wrote:
> Without question, we need to keep in mind a distinction between being
> closed from the manufacturer and closed by policy. But by policy, I
> mean by policy of those deploying the product (e.g. in a
> library, where
> by policy making any modification is a violation of library policy).

I agree that agencies should not automatically be allowed to limit
accessibility on behalf of other motivating factors like network
security. In the same spirit, I think the 508 regulations should
make it clear that vendors should not limit accessibility either.

Peter wrote:
> "technical infeasibility" is a new term to accessibility regulatory
> discussion, and I don't think we should try to use it. Virtually
> anything can be done with technology given enough money and
> time. But
> that doesn't make it "readily achievable" - a term that does
> have a long
> history in accessibility regulation, and moreover the term
> that I think
> it is appropriate for us to use here.

"Readily achievable" is the 255 standard; "undue burden" is 508. "Undue
burden" is more stringent; it doesn't matter that 508 applies to the agency
while 255 applies to industry because both are supposed to provide guidance
about the
degree of effort and expense to be used in achieving accessibility. They
both take into account limits in "money and time".

> By demonstration, adding a screen reader to Windows (or Macintosh or
> Solaris) is readily achievable. Likewise adding a screen reader to a
> number of Windows Mobile devices. That is not the case with
> a myriad of
> consumer electronics devices today.

This is somewhat circular reasoning. The more open and publicly available
the necessary developer information is, the less expensive is the effort in
developing an accessibility solution. That is, a universal or
easy-to-port-to
OS or platform means more, better, faster, cheaper accessibility from third
parties.

From: Robinson, Norman B - Washington, DC
Date: Thu, Apr 26 2007 10:30 AM
Subject: Re: more on the "closed" issue

Jim,

After reading your post from Thursday, April 26th, I couldn't
help but comment.

Based on my own experiences, considering the goal of
accessibility includes considering social impact on the technical and
legal standards, I'd say we would do well to ensure fair use and reverse
engineering are clearly allowed for accessibility. Can we do that?

I've pulled a few of your talking points:
1. Jim wrote "The problem is, when one entity makes both the
"OS" and the "app", and holds the technical details close, defining the
boundary between the OS and the app can be tricky. Do we want to get
into those definitions?"
I'd say, no, we don't want to determine this as it would never
be absolute and always subject to interpretation. However if you
eliminate your labels, and simply agree that "OS" is composed of
software and "apps" are composed of software, then I would hope our
Section 508 standards for software would apply equally.

2. Jim wrote "..one original impetus for defining a product as
"closed" was that it was a public device (e.g. ATM) to which no hardware
could be attached or software loaded for security reasons...508 was not
going to require that a user could come along and install AT onto it."
I've stated before, having a specific class or label for
"closed" is useless for us or at the least weakens the technical
standards. There is nothing in the generic sections for "software (web
being a specific type software in my book)" or "hardware (255 or
Telecomm and desktop hardware and what is today self-contained hardware
standards)" that are can't be applied. Call it closed (by design,
policy, strategy), personal use, impersonal, back office, etc,; it
doesn't matter as they all should have the technical standards (for
software and hardware) apply.

3. Jim wrote "We have been able to rely on AT only when the
product has been more or less open, and when the company has shared
information about its technologies with developers."
Well, I'd have to change that "and" to an "or" but think we may
disagree. Certainly as an open source advocate I would say it is easier
for more people to gain access and increase the chances assistive
technology will be developed and work on "open" products. But there are
plenty of closed products that work fine because the assistive
technology vendor was able to gain inside developer knowledge or reverse
engineer another vendor's product.

4. Jim wrote "..accessibility. Do we want to create policy that,
by ratifying Company A's rights to define products as closed, limits
Company B's ability to innovate?".
No, I don't think that we would want that. But I also don't
think Section 508 can do anything about trademark and copyright or
digital rights management (DRM) issues directly. I'd certainly support
that no matter what mechanism a vendor uses for DRM it should be legal
to eliminate that DRM if there is no free way to gain access. I think
companies have a right to produce a product and be ignorant and selfish
and demand their rights are more important than their users - bad
business and I wouldn't want to do business with them, but they should
be free to do so. What I don't want is that _for the government_ to
purchase a product for purposes that the end-users have to accept and
the companies still try to establish their rights are more important
that the basic right to gain access. In a more perfect world, the
end-user would have the right to gain access and use no matter what the
legal hurdles, including if that put the vendor's desires at risk. I am
talking about basic requirement for access, not ignoring licensing or
negotiated pricing the same as would be expected of any use of their
product.

5. Jim wrote "..this does not always void all parts of the
warranty, especially when the.."
Well, certainly I don't expect Section 508 to address the legal
issues over what the vendor will cover by warranty. I don't think
Section 508 would be the place to state that 3rd party add-ons or
modifications by an external vendor wouldn't void your warranty. Any
vendor to accept that would be foolish. A smart vendor would define an
interface and the consumer would purchase their product expecting
third-party vendors (or the users themselves) can interface without fear
of the underlying software failing. Of course a public, open interface
would be most beneficial to society and the end-users.

So if we can't consider this in the Section 508 technical
standards themselves (because it *may* not belong in the _technical_
standards) then these ideas should be captured and remembered for
updates or other related laws to support this kind of thinking.

Thanks for a lively post,


Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246

From: Robinson, Norman B - Washington, DC
Date: Thu, Apr 26 2007 10:35 AM
Subject: Re: more on the "closed" issue

Jim,

After reading your post from Thursday, April 26th, I couldn't
help but comment.

Based on my own experiences, considering the goal of
accessibility includes considering social impact on the technical and
legal standards, I'd say we would do well to ensure fair use and reverse
engineering are clearly allowed for accessibility. Can we do that?

I've pulled a few of your talking points:
1. Jim wrote "The problem is, when one entity makes both the
"OS" and the "app", and holds the technical details close, defining the
boundary between the OS and the app can be tricky. Do we want to get
into those definitions?"
I'd say, no, we don't want to determine this as it would never
be absolute and always subject to interpretation. However if you
eliminate your labels, and simply agree that "OS" is composed of
software and "apps" are composed of software, then I would hope our
Section 508 standards for software would apply equally.

2. Jim wrote "..one original impetus for defining a product as
"closed" was that it was a public device (e.g. ATM) to which no hardware
could be attached or software loaded for security reasons...508 was not
going to require that a user could come along and install AT onto it."
I've stated before, having a specific class or label for
"closed" is useless for us or at the least weakens the technical
standards. There is nothing in the generic sections for "software (web
being a specific type software in my book)" or "hardware (255 or
Telecomm and desktop hardware and what is today self-contained hardware
standards)" that are can't be applied. Call it closed (by design,
policy, strategy), personal use, impersonal, back office, etc,; it
doesn't matter as they all should have the technical standards (for
software and hardware) apply.

3. Jim wrote "We have been able to rely on AT only when the
product has been more or less open, and when the company has shared
information about its technologies with developers."
Well, I'd have to change that "and" to an "or" but think we may
disagree. Certainly as an open source advocate I would say it is easier
for more people to gain access and increase the chances assistive
technology will be developed and work on "open" products. But there are
plenty of closed products that work fine because the assistive
technology vendor was able to gain inside developer knowledge or reverse
engineer another vendor's product.

4. Jim wrote "..accessibility. Do we want to create policy that,
by ratifying Company A's rights to define products as closed, limits
Company B's ability to innovate?".
No, I don't think that we would want that. But I also don't
think Section 508 can do anything about trademark and copyright or
digital rights management (DRM) issues directly. I'd certainly support
that no matter what mechanism a vendor uses for DRM it should be legal
to eliminate that DRM if there is no free way to gain access. I think
companies have a right to produce a product and be ignorant and selfish
and demand their rights are more important than their users - bad
business and I wouldn't want to do business with them, but they should
be free to do so. What I don't want is that _for the government_ to
purchase a product for purposes that the end-users have to accept and
the companies still try to establish their rights are more important
that the basic right to gain access. In a more perfect world, the
end-user would have the right to gain access and use no matter what the
legal hurdles, including if that put the vendor's desires at risk. I am
talking about basic requirement for access, not ignoring licensing or
negotiated pricing the same as would be expected of any use of their
product.

5. Jim wrote "..this does not always void all parts of the
warranty, especially when the.."
Well, certainly I don't expect Section 508 to address the legal
issues over what the vendor will cover by warranty. I don't think
Section 508 would be the place to state that 3rd party add-ons or
modifications by an external vendor wouldn't void your warranty. Any
vendor to accept that would be foolish. A smart vendor would define an
interface and the consumer would purchase their product expecting
third-party vendors (or the users themselves) can interface without fear
of the underlying software failing. Of course a public, open interface
would be most beneficial to society and the end-users.

So if we can't consider this in the Section 508 technical
standards themselves (because it *may* not belong in the _technical_
standards) then these ideas should be captured and remembered for
updates or other related laws to support this kind of thinking.

Thanks for a lively post,


Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246