There is a good post by Mathias Bauer on Sun Hamburg’s GullFOSS blog. He deals with the practical importance of OASIS’s “Feedback License” that governs any public feedback OASIS receives from non-TC members.
The ODF TC receives ideas for new features from many places. Many of the ideas come from our TC members themselves, where we have representation from most of the major ODF vendors, from open source projects, interest groups, as well as from individual contributors.
Other ideas come from other vendors or open source projects, from organizations that the TC has a liaison relationship with (like ISO/IEC JTC1/SC34), or individual members of the public.
Contributions from OASIS TC members are already covered by the OASIS IPR Policy. The TC member who contributes written proposals to the TC is obliged from the time of contribution. And other TC members are obliged if they have been TC members for at least 60 days and remain a member 7 days after approval of any Committee Draft. You can see the participation status of TC members here.
For everyone else, those who are not members of the ODF TC, the rules require that proposals, feedback, comments, ideas, etc., come through our comment mailing list. But before you can post to the comment list you must first accept the terms of the Feedback License.
Is this extra step annoying? Yes, it is. But this pain is what is necessary to keep our IP pedigree clean and protect the rights of everyone to implement and use ODF. It is part of the price we pay for open standards. Free does not mean free from vigilance.
One of my responsibilities on the ODF TC is to monitor and process the public comments we receive. Regretfully this is a duty which I’ve neglected for too long. So I spent some time this week getting caught up on the comments, entering them all into a tracking spreadsheet. We have a total of 180 public comments since ODF 1.0 was approved by OASIS, covering everything from new feature proposals to reports of typographical errors.
The largest single source of comments is from the Japanese JTC1/SC34 mirror committee, where they have been translating the ODF 1.0 standard into Japanese. As you know, you will get no closer reading of a text than when attempting translation, so we’re glad to receive this scrutiny. I’ll look forward to adding the Japanese translation of ODF along side the existing Russian and Chinese translations soon.
For comments that are in the nature of a defect report, i.e., reporting an editorial or technical error in the standard, we will include a fix in the ODF 1.0 errata document we are preparing. For comments that are in the nature of a new feature proposal, we will discuss on a TC call, and decide whether or not to include it in ODF 1.2.
A sample of some of the feature proposals from the comment list are:
- A request to support embedded fonts in ODF documents
- A request to support multiple versions of the same document in the same file
- A request to allow vertical text justification
- A proposal for enhanced string processing spreadsheet functions
- A proposal for spreadsheet values to allow units, which would help prevent calculation errors due to mixing units, i.e., adding mm to kg would be flagged as an error.
- A proposal for allowing spreadsheet named ranges to have namespaces, with each sheet in a workbook having its own namespace.
- A proposal to allow a document to have a “portable” flag to allow it to self-identify that it contains only portable ODF content with no proprietary extensions.
- Proposal for adding FFT support to spreadsheet
- Proposal for adding overline text attribute
If you have any other ideas for ODF enhancements, or thoughts on the above proposals, please don’t post a response to this blog! Remember, you need to use the comment list for your feedback to be considered by the OASIS ODF TC.
Of course, general comments are always welcome on this blog.
Re: the “accept the terms of the feedback license” – I’m not sure subscribing to an e-mail list indicates your acceptance of anything other that willingness to accept mail from that list, particularly since other places (e.g., http://wiki.oasis-open.org/office/New_Member_Orientation) make no mention of the terms.
I’m not sure how that keeps your IP particularly clean.
Proposal for adding overline text attribute
Interesting how slowly some things move. This one has been languishing as an enhancement request (originally started by another standards group!) for OO.o since six years ago (Issue 5991). Apparently nobody there looked at it until recently to realize that it would require a format addition.
Seems strange, given that overline is a common text markup in several fields, but there you are.
You are not able to sign up to post to the comment list without agreeing to the feedback license.
When you sign up you’ll get an email like this:
—–
Thank you for offering to provide input to the
OASIS Open Document Format for Office Applications (OpenDocument) TC.
Please take a moment to confirm your request to add
xxx.yyy.com
to the office-comment mailing list.
Confirmation is necessary to verify your email address, to assert your acceptance of the list’s submission terms, and to protect the list against spam.
By confirming your subscription request, you:
a) acknowledge that your postings to the list will be publicly archived;
b) agree to the terms of the OASIS Feedback License as printed below and located at:
http://www.oasis-open.org/who/ipr/feedback_license.pdf
——
So is it perfect? No. It is as secure as SMTP email is, which isn’t that great. But this is OASIS, not ISO. We don’t need to post guards at our doors when we have meetings. We just try to do good work carefully.
The ‘feedback licence’ is probably intended to express the proposition that if you give feedback, OASIS (and everybody on the planet) can use your feedback with no obligation to you.
So if you have the manuscript for the next Harry Potter, and you want to make money from selling books, then don’t post it to the mailing list. You’d do a lot better to go see someone like Scholastic Publishing .
We make gramaphone players here. We understand that other businesses think that phonograph records are where the value is, but we make gramaphone players. And it’s just as well if all the gramaphone players work to open standards, otherwise you’d never get your phonograph records to play on them.
Or the 21st-century equivalent.
If I worked at a company that controlled IP rights I would forbid people particpating under such a license.
If someone working for Google were to propose a feature under this feedback license they might be compromising Googles IP rights.
This is a very strange licensing agreement which is actually potentially damaging to participation by employees of companies interested in ODF.
I’m a supporter of ODF, the process it went through, and the applications that use it (I run KOffice), but…
How come ODF 1.2 has been pushed back so far and the TC is now considering new things to add to it? I thought they were just finishing up the spreadsheet formulae before releasing 1.2.
Why not release 1.2 as originally planned and push everything else back to 1.3? How can you be sure that you won’t push it back again to get in “just one more feature” when the new 1.2 deadline approaches?
Release early, release often.
Applied to standards, “release often” probably means no more often than once per year. Certainly a standards body should be careful to spend as much time as necessary to get a set of features right. Pushing back release dates in order to ensure that would definitely be the correct thing to do.
But adding more features into a given release cycle? Why? What does that accomplish?
Well, obviously Google disagrees, since they are members of the ODF TC, and as such have agreed to IPR terms that encompass wider obligations than are in the Feedback License.
Companies that participate in standardization, specifically of an open standard, typically have done the math and figure that they have more to gain from selling goods and services to a widely adopted technology than they would by selling the same to a much less adopted proprietary technology.
As for schedules, “release early and often” is applicable to drafts of standards. We should release drafts early and often, in order to get feedback. We just released a draft 7 of ODF 1.2.
But you will not see formal standards released at a fast pace. Consider: If I wrote the phrase “hello world” on a piece of paper and tried to get it approved as an ISO standard, it would take at least 4 months in OASIS (Public Review period, Committee Specification ballot plus OASIS Standard ballot). Then it would require an additional 9 months for it to be approved and published as an ISO/IEC standard (6 month PAS ballot plus publication). So we’re talking at least a year, even for something that has zero technical content and zero editing.
That’s why you will not see newly approved ODF standards every year. A more natural pace, considering the process overhead, is a new version every three years or so.
Hmmm….yes. I was imagining that the review periods and ballots would take proportionally more time for larger revisions to the spec than smaller ones. But if there is a minimum review period then it does makes sense for each revision to do at least as much as can reasonably be reviewed in the minimum review period.
I imagine that the review period can be longer so that if, e.g. a 6,000 page revision was submitted, the review period would be extended so that the review could be properly executed.
So if the original 1.2 revision was fairly small (relatively speaking), then adding more to it would make better use of the review/voting time than pushing those things back to 1.3.
Makes sense. Thanks for the explanation.
Why did Oasis not submitt ODF 1.1 to ISO?
Some comments from Alexander Brown on Andy Updegroves blog seem to indicate that he puts an aweful lot of importance to this when he reasons about the merits of ODF and OOXML as ISO standards.
Our logic at the time (January 2007) was that ODF 1.1 was a minor update, and our agreement with JTC1 was to provide them major updates.
Also, we anticipated that ODF 1.2 would be finished by October, 2007. It would not make sense for us to be submitting ODF 1.1, and then submitting ODF 1.2 only 9 months later. That would have potentially resulted in two ODF versions being processed by JTC1 at the same time, while they were also processing the 6,000+ page OOXML. Would that have been a good idea? I don’t think so. Of course, we were wrong about the ODF 1.2 dates, but that was our thinking at the time.
Finally, JTC1 Directives allow the initial version of a PAS submission to be in the format of the submitting organization, OASIS in our case. But subsequent revisions must be in proper ISO format. ODF 1.1 was not in proper ISO format. We’re doing that work for ODF 1.2.
But in retrospect, if I had to do it over again, I would have done the ODF 1.1 items as ODF 1.0 errata. That would have made everyone happy.