|
|
| How to Contact Massachusetts about Open Format Proposal |
 |
|
Monday, March 28 2005 @ 10:59 PM EST
|
I have gotten a lot of email from readers, asking me where to send comments about the new Massachusetts Open Format proposal, so I contacted Linda Hamel, who tells me this:“Please forward comments by April 1, 2005 to Standards@state.ma.us . Your readers are a valuable source of input and we welcome their comments. Their emails will be reviewed by our policy person, primarily Claudia Boldman, and our CIO Peter Quinn for consideration of any potential changes. I will take a look at any legal issues raised.
"Groklaw readers who want to enter into a dialogue with me as ITD’s general counsel can use my email address, Linda.hamel at state.ma.us."
Please be aware that her time is limited, so the first email is the one most of you should use. Let's save the latter for attorneys who wish to contact her. And your time is limited too, as April 1 is the deadline.
|
|
|
|
| Authored by: fudisbad on Monday, March 28 2005 @ 11:08 PM EST |
For current events, legal filings, 10-Ks and 10-Qs.
Please make links clickable.
Example: <a href="http://example.com">Click here</a>
---
See my bio for copyright details re: this post.
Darl McBride, file your 10-K and your 10-Q![ Reply to This | # ]
|
| |
| Authored by: rm6990 on Monday, March 28 2005 @ 11:45 PM EST |
Lol, just had to post this, despite the fact that there isn't likely to be any
corrections needed.[ Reply to This | # ]
|
| |
| Authored by: rsi on Monday, March 28 2005 @ 11:48 PM EST |
Thank you PJ!
This was exactly what we were looking for.
Rick
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, March 29 2005 @ 02:48 AM EST |
Am I the only one who tried to fill out the GNOME survey and gave up because the
survey itself has "usability problems"? It made my head spin!
Craig[ Reply to This | # ]
|
| |
| Authored by: cmc on Tuesday, March 29 2005 @ 03:56 AM EST |
First, I just want to say that when you send in your email, don't expect a
response. I've sent two and haven't received even an automated message saying
they received my messages. I'm sure they're getting lots of messages, which is
why they aren't responding.
Now, I was thinking about this in more
detail, and since we're dealing with a convicted monopolist who we know likes to
play games with the law and create EULAs only a lawyer can understand, we need
definitive clarifications on their patent license. We need to know what their
definitions are of every word and phrase used in the patent license. For those
interested, the patent license referred to is on Microsoft's website here.
Now let's examine the following two paragraphs:
Paragraph 1 of the
patent license:
"Microsoft may have patents and/or patent applications that
are necessary for you to license in order to make, sell, or distribute software
programs that read or write files that comply with the Microsoft specifications
for the Office Schemas."
Paragraph 7 of the patent license:
"By way
of clarification of the foregoing, given the unique role of government
institutions, end users will not violate this license by merely reading
government documents that constitute files that comply with the Microsoft
specifications for the Office Schemas, or by using (solely for the purpose of
reading such files) any software that enables them to do so. The term
"government documents" includes public records."
First of all, "may
have patents"? They don't even know? If they don't have patents, what do I
need to license from them? But other than that, it all looks normal, right? It
could have been innocently crafted, or it could be that that's exactly what they
want us to believe (yes, dealing with an unethical convicted monopolist WILL
make you paranoid about all of their endeavors). Here are some things I
question:
1. Paragraph 1 mentions reading and writing files, while
paragraph 7 mentions reading documents. As was stated in a previous comment in
one of the previous articles, this can be troublesome. What does Microsoft mean
by "documents"? Technically, the document is the content of the file (like a
letter is the content of an envelope). It doesn't matter if we can read the
file if we can't read the content of the file, just like it doesn't matter if
you can read (or open) an envelope if the letter inside is
unreadable.
2. Assuming that "document" refers to the file as a whole,
and that the end user is given the right to read the file and it's contents,
what is meant by "read"? It seems like a silly question, doesn't it? Any
logical person would think "To read it! There's no way to misinterpret that!"
Oh, but there is, and it gets trickier the further down the technological layers
we go.
I think the generally accepted definition of reading a document
would be to read and display the content of the file. But, in order to do that,
the file must be read from the media (probably a hard drive or a CD) and written
to memory, then read from memory and written to the display adapter so that it
is shown on your monitor.
Now we'll go a little bit further. The file
needs to be read from disk and written to memory, then read from memory and
written to the display adapter. Oops! You don't have enough memory, so your
operating system just "swapped to disk", and wrote the section of memory which
was holding the document to the hard drive. Now we've written the document at
least twice.
OK, one more step. The hard drive's read/write heads read
the requested information from the hard drive (or, if reading from a CD, the
laser decodes the data from the CD) and writes that information into the
device's built-in buffer. Then the information is written to the computer's
memory. The information may be swapped to disk and re-read from disk. The
information may be written to various caches. The information must then be
written to the display adapter. If you wish to print the document (which most
people would think is acceptable if given the rights to read the document), then
that involves writing the information to the printer.
As you can see,
the document is written at least a couple of times just in the process of
"reading" it. Are these types of writing allowed, or (since the patent license
specifically does not grant you the right to write the document) are these types
of writes not allowed? Also mentioned in that previous paragraph is printing.
Is printing allowed under the "merely reading" clause? After all, what good is
receiving a public document from the state if you can only view it on your
monitor? It's pretty useless for most documents.
Lastly, paragraph 8
of the patent license states:
"Microsoft reserves the right to
terminate this license grant if you sue Microsoft or any of Microsoft's
affiliates for patent infringement over claims relating to reading or writing of
files that comply with the Office Schemas. This license is perpetual subject to
this reservation."
If Microsoft infringed on someone's patent (or
someone had a good-faith basis for that belief), and that person sued Microsoft,
then Microsoft can terminate that person's rights to this license. So let's
say, hypothetically, that ACME Corporation, a contractor who regularly bids for
government contracts in Massachusetts, thought Microsoft infringed one of their
patents in creating the Office 2003 Schemas. Wanting to defend their
intellectual property (as all corporations do), ACME sues Microsoft on that
belief, but a judge determines that there's not enough evidence to support the
claim. Microsoft terminates ACME's license to use the Office 2003 Schemas. Now
what's ACME supposed to do? Will the state provide the document in a different
format for them?
In my opinion, there are too many open-ended questions
that cannot be definitively resolved. Even if we get all the clarifications we
want, who says we won't miss something that will later come back to bite us? My
position is that no public document, and no documents governments use to
communicate with third parties, should be any non-open format. And any format
which may be encumbered by patents is not an open format, no matter what anyone
says. Any format that requires a license is not open.
cmc
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, March 29 2005 @ 07:20 AM EST |
1. Microsoft, the convicted monopolist, have provided a not-quite-license for
their patent ONLY covers the READING of government XML documents. It does NOT
give you leave to write, sell, provide or obtain a reader for them, and it does
NOT cover the act of creating XML documents, government or otherwise, using
tools not created by Microsoft, the convicted monopolist.
2. Microsoft, the convicted monopolist, does not have a good track record in
this area. The onus is on Microsoft, the convicted monopolist, to show good
faith by providing explicit and irrevocable licensing for this patent for both
reading AND creation of (government) XML documents, AND for the creation of
tools to do that. Microsoft, the convicted monopolist, have very carefully
avoided doing this. What does this say about the intent of Microsoft, the
convicted monopolist?[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, March 29 2005 @ 08:28 AM EST |
I spoke to Peter Quinn and Eric Kriss yesterday when I ran into them at a
meeting. They have both spent time reading the comments here on Groklaw.
Please, don't send them comments that are just new ways of saying the same
things already posted (e.g., "Microsoft is a monopolist you can't trust",
"Writing AND reading", etc.). It is not the number of comments that matter. This
is only one of many, many quite different and important things they need to do,
so don't needlessly take up their time or they'll miss the wheat for the
chaff.
What they are looking for are patent lawyers who know patent
law (or others with experience in the area) who have new observations, or people
involved in policy decisions at other governmental bodies with examples of what
worked for them.
Make sure you've read the material carefully, like
PJ did.
Make sure you understand the difference between a patent application and
a granted patent.
Remember, this is just one format. This allows a
citizen to send things in MS XML format, or for state workers to use the same
software most other people do today (and for which they are already trained).
This does not mean that they will require you to use MS XML -- the guidelines on
their site do not say that. They say that "Agencies should use the RTF document
format wherever possible for ease of interoperability among different systems,"
and "Agencies should evaluate office applications that support the OpenDocument
specification to migrate from applications that use proprietary document
formats." For MS XML it says "The Schemas provide developers and representatives
of business and government a standard way to store and exchange data stored in
documents." I read that to mean they will accept documents in the format from
businesses to be responsive to the businesses that don't want to
switch.
This is Massachusetts -- they know Microsoft has been declared
a monopoly. They know Microsoft plays a tough game.
Perhaps someone
should summarize the comments rather than them needing to read them all. The
amount is overwhelming for people for whom it is difficult to get one hour of
their time (and Groklaw has already gotten that and
more).
Thanks!
-Dan Bricklin
[Speaking for myself,
not in any official capacity...][ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, March 29 2005 @ 08:52 AM EST |
Then it would seem to me that the only sensible conclusion that a government
agency can come to is that that agency cannot create government documents in
Microsoft's format.
The government department can perhaps bend to accept documents created by other
parties in Microsofts XAML - the government agency would still be able to read
said documents.
This "read only" restriction (that Microsoft seem to be imposing on
themselves) means that since Microsoft products cannot create documents in a
fully open format such as OASIS, then the government department would be forced
to avoid using Microsoft Office for creation of the department's own documents.
If this is so, would it then not make sense for the Government department to
drop Microsoft Office entirely?
Do others have the same take on this, or have I got a wrong impression
somewhere?[ Reply to This | # ]
|
| |
| Authored by: dwheeler on Tuesday, March 29 2005 @ 12:54 PM EST |
For your amusement, here's what I sent.
No doubt everyone here will notice the 10 mistakes I've
made, now that I sent it :-). But perhaps this
message will be of use to others.
===============================
Dear Commonwealth of Massachusetts:
Thanks for the opportunity to comment on the Commonwealth's
Enterprise Technical Reference Model (ETRM) v 3.0 at
http://www.mass.gov/itd/etrmversion3/techrefmodelv3.htm.
I have several comments:
(1) you should fix the definition of "open format" by appending
the following: "To be an open format, it must be possible
to implement the format in proprietary programs from any vendor,
and in software released using the most popular open source
software licenses. This maximizes the possibility of competition."
(2) you should drop the MS XML Reference Schemas as an
"open format" -- they fail to fulfill your purpose, and
are risky for other reasons as well.
(3) Fix the "Pending final approval by OASIS expected in 2005";
it misleads the reader into thinking MS XML Reference
Schemas have been approved by someone (they have not).
Add similar statements to MS XML Reference Schemas, or
drop the footnotes for both, as described below.
Below I explain and justify these comments further.
I wish you well.
========================================================
1. Open Format Definition Needs Clarification
Fundamentally, I think you have an excellent approach by
working for "open formats". However, your current definition
has a huge loophole that at least one vendor appears to be
exploiting. Something should only be considered
an open format if there can be unfettered competition
between implementations by common development approaches,
but your current definition permits "open" formats that in
fact cannot be implemented by many of a vendor's competitors.
The definition should require that it be possible
to implement the format in not only proprietary implementations,
but also by open source software implementations, and
in particular it must be implementable under the most
common licensing situations for open source software.
Thus, in the "Information Domain" section, in the
definition starting "The Commonwealth defines open formats as..."
Append the following: "To be an open format, it must be possible
to implement the format in proprietary programs from any vendor,
and in software released using the most popular open source
software licenses. This maximizes the possibility of competition."
Open source software/ Free Software (OSS/FS)
is increasingly being used and sold in today's
commercial software industry (for more evidence of this,
see http://www.dwheeler.com/oss_fs_why.html).
The GNU General Public Licenses (GPL) is by far the
most common OSS/FS license
(http://www.dwheeler.com/essays/gpl-compatible.html).
Thus, any specification that discriminates against GPL implementations
is automatically discriminatory against OSS/FS.
It's much better if governments demand the use of formats
that everyone can implement and use, so that they can
choose between competitors. If governments set policies
(through standards) that unintentionally forbid the
use of OSS/FS, they will end up paying far more than necessary
due to the lack of competition.
Without this clarification, vendors may attempt to deceive
Massachusetts by creating legal clauses that meet the
criteria given here, yet prevent legitimate competition.
Indeed, that's exactly what has happened in this case.
2. Drop the MS XML Reference Schemas
Massachusetts should remove the "MS XML Reference Schemas"
from the "open formats" list. These specifications do not
really meet the requirements of "open formats" and there's no
evidence that they would ever do so. There are also many
technical problems and weaknesses with the format.
These particular specifications are proposed by a vendor,
but the license conditions created by that vendor are carefully
crafted to prevent competing implementations. The vendor
claims the license conditions aren't restrictive, but
competitors (the ones who matter) HAVE demonstrated that
they are still too restrictive.
If Massachusetts permits this format, that means that
Massachusetts is selecting one vendor OVER another,
without a fair and open competition.
In this case, the vendor is claiming that the license
to their format is available to open source developers,
and is compatible with open source licenses.
But this is not really true.
The vendor says that all users who want a license for
the Office 2003 XML Reference Schemas must obtain the license
by downloading the xsdref.msi file from Microsoft's website,
and no one is allowed to sublicense the file.
OSI's open source definition (point 7) requires that all
derivative works must be automatically sublicensed.
The most common license, the GPL,
grants you the right to modify the code, which means you
could remove the Microsoft-required attribution notice,
and it specifically requires you to automatically sublicense
all derivative works.
That means that Microsoft's Office 2003 XML Reference Schema
patent license is not compatible with the GPL or with any
OSI-approved license. In other words, it's not compatible with open
source. Given the large penetration of open source software
in general, and of open source office suites like OpenOffice.org,
KOffice, and GNOME Office in particular, these are not
reasonable restrictions. Governments should be
enabling, not forbidding, fair and open competition.
Far more detail than given here can be found in these discussions:
http://www.groklaw.net/article.php?story=20050322102754351
http://www.groklaw.net/article.php?story=20050324233749913
One of many reporters who noticed this is at:
http://www.betanews.com/article/Analyst_MS_Office_Formats_Not_Open/1107211516
The vendor's recent "concessions" do not resolve the problem.
They added "a provision to the license stating that users
could use ANY software (that would include GPL licensed
open source desktop software) to read government records
created using the MS XML reference schema."
But note that this implies that the government is granting
a monopoly to a vendor to CREATE data in the format. And citizens
must be able to reply to the government as well; are they
forbidden from using competing products that are OSS/FS?
And if only reading is permitted, formats such as PDF and HTML
are better formats anyway, because they are much more
widely supported for read-only documents, today.
This phrase also suggests that they can only read government
documents, but OSS/FS program licenses don't work that way; they
cannot restrict usage, so they can't implement even
the reading at all. Thus, we have another license trick
that APPEARS to grant use, but in fact doesn't allow
use by all competitors at all.
Note that the MS XML specification is NOT developed
nor controlled by a group of vendors; it's simply a single
proprietary vendor's specification, without outside
review. What's more, its license permits no changes at
all to the specification by others, yielding complete control
of the specification to a single vendor in perpetuity.
In contrast, the OpenDocument specification was developed
by many vendors, including Sun (StarOffice/OpenOffice)
KDE (KOffice), and Corel (Word Perfect), as well as users,
and it permits future extensions (as is necessary for
a workable standard).
There are other problems as well with the MS XML specification.
The OpenDocument format covers presentations
(Powerpoint), while as far as I can tell Microsoft's
format does not. I suspect that the government will
occasionally wish to share presentations with citizens.
Thus, MS XML is inferior in terms of the data it can represent;
if the government wishes to share editable presentations,
it needs OpenDocument anyway.
The MS XML format is far less often used and is less mature.
The OpenDocument format is a nonproprietary standard based
on the OpenOffice/StarOffice XML format. Since this is
the primary format these programs use for data transfer,
there has been a tremendous amount of experience and maturing
in ensuring that all data can be captured with this format.
There has also been work from multiple products to implement
this standard; the surest sign of a working standard is
multiple implementations, and in fact the Internet standards
body (the IETF) uses that as one of its requirements for
a full standard. OpenDocument is implemented by many
products; the MS XML format is rarely used, and is not
widely implemented by many products.
Technically, MS XML format is essentially a "data dump" of
the internal structures of Microsoft's products, and thus
is an unnecessarily complicated structure to work with.
Many have reported that its actual design is inferior
to OpenDocument (which makes sense, because OpenDocument
had to survive widespread review by many organizations).
At least one group started to use it, and has since
abandoned MS XML to switch to using OpenDocument instead.
MS XML is not a mature format ready for inclusion in
this document. What's more, you state that you intend to
move to specifications that are blessed by a standards body,
and there's no reason to believe this will happen to
MS XML -- risking abandonment by those organizations
who choose to use it.
3. Fix the "Pending final approval by OASIS expected in 2005"
footnote.
In many places in the document the text says
"* Pending final approval by OASIS expected in 2005".
This text is true but misleading. It misleads the reader into
thinking MS XML Reference Schemas have already been approved
by some standards body, since they don't have a footnote.
Indeed, the opposite is true: there's no evidence that
the MS XML Reference Schemas will be submitted to any
body, and instead, it appears that the vendor intends to
permanently control them.
Thus, if this text is included, the following footnote should
be added to equivalent references to MS XML Reference Schemas:
"* Vendor-proprietary specification with no promise of
standardization".
Or, drop the footnotes.
It's fine to leave the text as it is in the description.
However, I would add the equivalent text above to the description
of MS XML Reference Schemas; it's important to note that this
is NOT a specification created by a standards body; indeed,
it can only be modified by a single company (giving them
control over data) and no one else is allowed to implement
enhancements of it (according to its patent license).
This is different from, for example, PDF, which is a vendor
specification but others can implement extensions to it.
Again, I wish Massachusetts the best, and I thank you
for the opportunity to comment.
--- David A. Wheeler
[ Reply to This | # ]
|
| |
| Authored by: dwheeler on Tuesday, March 29 2005 @ 12:59 PM EST |
For your amusement, here's what I sent.
No doubt everyone here will notice the 10 mistakes I've
made, now that I sent it :-). But perhaps this
message will be of use to others.
===============================
Dear Commonwealth of Massachusetts:
Thanks for the opportunity to comment on the Commonwealth's
Enterprise Technical Reference Model (ETRM) v 3.0 at
http://www.mass.gov/itd/etrmversion3/techrefmodelv3.htm.
I have several comments:
(1) you should fix the definition of "open format" by appending
the following: "To be an open format, it must be possible
to implement the format in proprietary programs from any vendor,
and in software released using the most popular open source
software licenses. This maximizes the possibility of competition."
(2) you should drop the MS XML Reference Schemas as an
"open format" -- they fail to fulfill your purpose, and
are risky for other reasons as well.
(3) Fix the "Pending final approval by OASIS expected in 2005";
it misleads the reader into thinking MS XML Reference
Schemas have been approved by someone (they have not).
Add similar statements to MS XML Reference Schemas, or
drop the footnotes for both, as described below.
Below I explain and justify these comments further.
I wish you well.
========================================================
1. Open Format Definition Needs Clarification
Fundamentally, I think you have an excellent approach by
working for "open formats". However, your current definition
has a huge loophole that at least one vendor appears to be
exploiting. Something should only be considered
an open format if there can be unfettered competition
between implementations by common development approaches,
but your current definition permits "open" formats that in
fact cannot be implemented by many of a vendor's competitors.
The definition should require that it be possible
to implement the format in not only proprietary implementations,
but also by open source software implementations, and
in particular it must be implementable under the most
common licensing situations for open source software.
Thus, in the "Information Domain" section, in the
definition starting "The Commonwealth defines open formats as..."
Append the following: "To be an open format, it must be possible
to implement the format in proprietary programs from any vendor,
and in software released using the most popular open source
software licenses. This maximizes the possibility of competition."
Open source software/ Free Software (OSS/FS)
is increasingly being used and sold in today's
commercial software industry (for more evidence of this,
see http://www.dwheeler.com/oss_fs_why.html).
The GNU General Public Licenses (GPL) is by far the
most common OSS/FS license
(http://www.dwheeler.com/essays/gpl-compatible.html).
Thus, any specification that discriminates against GPL implementations
is automatically discriminatory against OSS/FS.
It's much better if governments demand the use of formats
that everyone can implement and use, so that they can
choose between competitors. If governments set policies
(through standards) that unintentionally forbid the
use of OSS/FS, they will end up paying far more than necessary
due to the lack of competition.
Without this clarification, vendors may attempt to deceive
Massachusetts by creating legal clauses that meet the
criteria given here, yet prevent legitimate competition.
Indeed, that's exactly what has happened in this case.
2. Drop the MS XML Reference Schemas
Massachusetts should remove the "MS XML Reference Schemas"
from the "open formats" list. These specifications do not
really meet the requirements of "open formats" and there's no
evidence that they would ever do so. There are also many
technical problems and weaknesses with the format.
These particular specifications are proposed by a vendor,
but the license conditions created by that vendor are carefully
crafted to prevent competing implementations. The vendor
claims the license conditions aren't restrictive, but
competitors (the ones who matter) HAVE demonstrated that
they are still too restrictive.
If Massachusetts permits this format, that means that
Massachusetts is selecting one vendor OVER another,
without a fair and open competition.
In this case, the vendor is claiming that the license
to their format is available to open source developers,
and is compatible with open source licenses.
But this is not really true.
The vendor says that all users who want a license for
the Office 2003 XML Reference Schemas must obtain the license
by downloading the xsdref.msi file from Microsoft's website,
and no one is allowed to sublicense the file.
OSI's open source definition (point 7) requires that all
derivative works must be automatically sublicensed.
The most common license, the GPL,
grants you the right to modify the code, which means you
could remove the Microsoft-required attribution notice,
and it specifically requires you to automatically sublicense
all derivative works.
That means that Microsoft's Office 2003 XML Reference Schema
patent license is not compatible with the GPL or with any
OSI-approved license. In other words, it's not compatible with open
source. Given the large penetration of open source software
in general, and of open source office suites like OpenOffice.org,
KOffice, and GNOME Office in particular, these are not
reasonable restrictions. Governments should be
enabling, not forbidding, fair and open competition.
Far more detail than given here can be found in these discussions:
http://www.groklaw.net/article.php?story=20050322102754351
http://www.groklaw.net/article.php?story=20050324233749913
One of many reporters who noticed this is at:
http://www.betanews.com/article/Analyst_MS_Office_Formats_Not_Open/1107211516
The vendor's recent "concessions" do not resolve the problem.
They added "a provision to the license stating that users
could use ANY software (that would include GPL licensed
open source desktop software) to read government records
created using the MS XML reference schema."
But note that this implies that the government is granting
a monopoly to a vendor to CREATE data in the format. And citizens
must be able to reply to the government as well; are they
forbidden from using competing products that are OSS/FS?
And if only reading is permitted, formats such as PDF and HTML
are better formats anyway, because they are much more
widely supported for read-only documents, today.
This phrase also suggests that they can only read government
documents, but OSS/FS program licenses don't work that way; they
cannot restrict usage, so they can't implement even
the reading at all. Thus, we have another license trick
that APPEARS to grant use, but in fact doesn't allow
use by all competitors at all.
Note that the MS XML specification is NOT developed
nor controlled by a group of vendors; it's simply a single
proprietary vendor's specification, without outside
review. What's more, its license permits no changes at
all to the specification by others, yielding complete control
of the specification to a single vendor in perpetuity.
In contrast, the OpenDocument specification was developed
by many vendors, including Sun (StarOffice/OpenOffice)
KDE (KOffice), and Corel (Word Perfect), as well as users,
and it permits future extensions (as is necessary for
a workable standard).
There are other problems as well with the MS XML specification.
The OpenDocument format covers presentations
(Powerpoint), while as far as I can tell Microsoft's
format does not. I suspect that the government will
occasionally wish to share presentations with citizens.
Thus, MS XML is inferior in terms of the data it can represent;
if the government wishes to share editable presentations,
it needs OpenDocument anyway.
The MS XML format is far less often used and is less mature.
The OpenDocument format is a nonproprietary standard based
on the OpenOffice/StarOffice XML format. Since this is
the primary format these programs use for data transfer,
there has been a tremendous amount of experience and maturing
in ensuring that all data can be captured with this format.
There has also been work from multiple products to implement
this standard; the surest sign of a working standard is
multiple implementations, and in fact the Internet standards
body (the IETF) uses that as one of its requirements for
a full standard. OpenDocument is implemented by many
products; the MS XML format is rarely used, and is not
widely implemented by many products.
Technically, MS XML format is essentially a "data dump" of
the internal structures of Microsoft's products, and thus
is an unnecessarily complicated structure to work with.
Many have reported that its actual design is inferior
to OpenDocument (which makes sense, because OpenDocument
had to survive widespread review by many organizations).
At least one group started to use it, and has since
abandoned MS XML to switch to using OpenDocument instead.
MS XML is not a mature format ready for inclusion in
this document. What's more, you state that you intend to
move to specifications that are blessed by a standards body,
and there's no reason to believe this will happen to
MS XML -- risking abandonment by those organizations
who choose to use it.
3. Fix the "Pending final approval by OASIS expected in 2005"
footnote.
In many places in the document the text says
"* Pending final approval by OASIS expected in 2005".
This text is true but misleading. It misleads the reader into
thinking MS XML Reference Schemas have already been approved
by some standards body, since they don't have a footnote.
Indeed, the opposite is true: there's no evidence that
the MS XML Reference Schemas will be submitted to any
body, and instead, it appears that the vendor intends to
permanently control them.
Thus, if this text is included, the following footnote should
be added to equivalent references to MS XML Reference Schemas:
"* Vendor-proprietary specification with no promise of
standardization".
Or, drop the footnotes.
It's fine to leave the text as it is in the description.
However, I would add the equivalent text above to the description
of MS XML Reference Schemas; it's important to note that this
is NOT a specification created by a standards body; indeed,
it can only be modified by a single company (giving them
control over data) and no one else is allowed to implement
enhancements of it (according to its patent license).
This is different from, for example, PDF, which is a vendor
specification but others can implement extensions to it.
Again, I wish Massachusetts the best, and I thank you
for the opportunity to comment.
--- David A. Wheeler
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Wednesday, March 30 2005 @ 07:23 PM EST |
Here is the letter I sent:
Dear Linda Hamel, Claudia Boldman and Peter Quinn,
I am writing because Massachusetts is making itself a leader in the area of
government compliant documents. While not a resident of Massachusetts, your
actions will influence many states, and presumably my state of Michigan.
The terms of the Microsoft License are unacceptable. A very well presented
review of the license and the implications can be found at www.groklaw.net, an
article titled "Evaluating Massachusetts' Open Formats Proposal".
In this article a writer posted as Marbux. The author is retired and no
longer practices law. He went to the trouble of analyzing the Microsoft license
in depth.
He made some very important points which I find most troubling.
1. The terms of the license are indeterminate. To quote from the article,
which in turn quotes from the license:
"If you distribute, license or sell a Licensed Implementation, this license
is conditioned upon you requiring that the following notice be prominently
displayed in all copies and derivative works of your source code and in copies
of the documentation and licenses associated with your Licensed Implementation:
"This product may incorporate intellectual property owned by Microsoft
Corporation. The terms and conditions upon which Microsoft is licensing such
intellectual property may be found at
http://msdn.microsoft.com/library/en-us/odcXMLRef/html/odcXMLRefLegalNotice.asp.
"
The problem is the terms and conditions are posted on a web site, which
is under sole control of Microsoft Corporation, and be changed at any time by
Microsoft Corporation. An activity that may not infringe to day, may well
become infringing tomorrow. Thus the terms of the license are indeterminant.
2. It is not possible to develop a product that will read and write files
that comply with the Microsoft specifcations for the Office Schemas that you
allow another to use.
Again from the license:
"Except as provided below, Microsoft hereby grants you a royalty-free
license under Microsoft's Necessary Claims to make, use, sell, offer to sell,
import, and otherwise distribute Licensed Implementations solely for the purpose
of reading and writing files that comply with the Microsoft specifications for
the Office Schemas."
As Marbux points out, it is the exception that makes the license
unacceptable:
"You are not licensed to sublicense or transfer your
rights."
As a programmer I could write code that read the Microsoft Office Schemas,
but in accordance with the conditions of this license, I would not be permitted
to let anyone else use this code.
3. Finally there is Microsoft's clarification:
"By way of clarification of the foregoing, given the unique role of
government institutions, end users will not violate this license by merely
reading government documents that constitute files that comply with the
Microsoft specifications for the Office Schemas, or by using (solely for the
purpose of reading such files) any software that enables them to do so. The term
'government documents' includes public records."
This clarification is even more restrictive, because it does not allow
for third party open source software to write Microsoft Office Schemas. If a
contractor is required by Massachusetts law to submit a proposal or bid in
electronic format, then that contractor is required by law to use the Microsoft
product.
For these reasons I sincerly hope you will reject the Microsoft license
as written.
As the author Marbux points out in the article, Microsoft is capable of
providing a license that will permit third party programs to read and write
Microsoft Office Schemas and convert those documents to and from other formats.
However Microsoft has not done so, and so the Office Schemas must be barred
until they do provide an acceptable license.
Respectfully,
(Name witheld)[ Reply to This | # ]
|
|
|
|
|
