Syringe.Net.Nz - Non GPL Implementation of ODF Not Very Feasible At All

Thursday, February 28, 2008

Non GPL Implementation of ODF Not Very Feasible At All

Feel free to take a look at the comments to the last post as this is a followup. You may want to ignore the snipey content devoid comments from our friend in the NZOSS community.

Herewith a follow up post that hopefully addresses the substantive questions that were actually raised (thanks Stu)

Sorry for the delay. I've been busy trying to get a high quality specification progressed through the ISO standards process. Oh and I've also managed to get outside to do some skiing in the Montana backcountry.

The issue is that the GPL aims to enforce the distribution of any derived work under the GPL also.

I do not want to release my applications under the GPL and inparticular I do not want to release any Open Source code I write under the GPL as I do not believe in the 'Copyleft' philosophy to which it subscribes.

Now that's fine. As a general rule I avoid GPL code like the plague (we do use LGPL code in some of our products). In fact our contracts at Kognition included a clause requireing neither party to the agreement to provide GPL code to the other.

So the question then comes to can I implement ODF without having to derive my work from any GPL based code.
My feeling is that even looking at the code for say OpenOffice will get me into trouble.
Likewise decompiling the code will be problematic.

I am actually comfortable reverse engineering by observation for features like 'blink', I do not believe that is going to breach copyright in the work.

But the question is, will reverse engineering by observation be sufficient. And to be honest I just don't know the answer to that question. I don't really see myself spending that much time working with ODF as I tend to agree with The Burton Report as to its likely levels of adoption and indeed the likely market segments to adopt it- selling software to people who are philosophically opposed to paying for software is unlikely to be a sustainable business. That said I did find a very interesting bit of commentary on the web about just this problem quite recently.

http://www.gnome.org/projects/gnumeric/announcements/1.8/gnumeric-1.8.shtml

"The Gnumeric team does not envision using the OpenDocument Format as its native format.

The spreadsheet part of ODF, in its current form, is ill defined and has many, many problems. For example: (1) there is no meaningful discussion of what functions a spreadsheet should support and what they should do. Without that, there is little point in trying to move a spreadsheet from one program to another; (2) there is no provision for sharing formulas between cells; (3) there is no implementation -- writing an ODF exporter consists of reverse-engineering OpenOffice to see what parts of the standard it can handle. (Note: the preceding comments relate to the spreadsheet part of ODF only; we do not have an informed opinion on ODF for word processing documents, for example.)

We may revisit this decision in the future, should the situation improve. In the meantime, we will strive to maintain a reasonable importer and exporter."

Those guys look to have actually broached the problem and to be honest that kinda answers my question. If I can't realisitically use ODF without reverse-engineering OpenOffice then I'm pretty much stuffed in terms of writing a GPL free implementation.

Friday, February 29, 2008 2:25:54 AM UTC

What's your thoughts on the recent Microsoft Open Protocols Specification initiative?

Looking through that there's some really interesting (i.e. helpful and practical) stuff in there, but for truely open source projects it would seem that there are still quite difficult licensing and patent hurdles to navigate through. The patent licensing fees that end users or commerical users would have to pay at some stage I've seen are a $10,000 USD base fee + a per unit royality of between $0.40 - $1.20 USD among other things, with sales reporting required etc (see http://download.microsoft.com/download/9/5/c/95c40a2a-b2a5-4417-b6ae-e77a695060aa/MCPP_License_Agreement.pdf). That would be quite difficult for most open source projects to manage.

Any time you try to pull together two items with different licensing models there is going to be difficulity and possible restrictions that come about. The example I raise above is just one example of it going in the other direction as well.

I am not well versed on the ODF file format etc, but how different is your argument from the equivalent argument that could be made about Microsoft's standard? Both standards include undefined or implementation specific behaviour, as do most published ones.

It seems your argument is based around looking at GPL covered source code in order to implement the ODF standard. I am sure if you looked at the Microsoft Office source code that you would be covered under an equally (if not even more) restrictive licensing agreement/NDA.

Removing looking at source code to implement either standard seems to put you in a more even (but not too much fun) situation. That of trying to observe the implementation defined behaviour by trail and error by manually using each product.

I think the real argument is around standards which can not easily be implemented without looking at an existing implementation. I'm not skilled up enough in either of the competing office document formats to make an informed decision, but think the argument becomes less emotive and "us vs them" when you take the licensing terms out of the equation.

Christopher Fairbairn

Sunday, March 02, 2008 2:27:30 AM UTC

Hiya Christopher,

I'll respond in depth to the OPSI stuff later, but, to answer some of the other bits:

"I am not well versed on the ODF file format etc, but how different is your argument from the equivalent argument that could be made about Microsoft's standard? Both standards include undefined or implementation specific behaviour, as do most published ones."

Microsoft doesn't have a standard. ECMA has an existing international standard (ECMA 376)and ISO/IEC has a proposed standard DIS29500.
As an example, we're a large way through an implementation of ECMA 376 and we've not had to look at any Microsoft (or other 3rd party) source code. One of the reasons that the ECMA 376 spec is so large (>6000pgs) is that it includes a really large amount of behavioural specification.
I'm VERY confident that it's posible to do an OOXML implementation looking only at the spec. My question was really can the same be said for ODF and the more digging I do the less confident I am that it can.

Per your final line. There are really a couple of areas of IPR that we need to think about.
1. The licensing and rights associated with the actual ODF and OOXML specifications. These are both provided under broad licensing terms that are approaved by ISO/IEC (JTC1 actually) and as such as long as you stick with looking at an implementing the spec there is no difficulty in creating an implementation of either ODF or OOXML to be released under the GPL or any other open source license that I am aware of.
2. The licensing or availability of application source code for an example implementation of the standard. NOw in the case of ODF a good exemplar is OpenOffice, the source cod eof which IS avaialable but only under the GPL. IN the case of OOXML a good exemplar might be Microsoft Office- good luck trying to get the source code to this :-) I don't even think it's available under the Source COde Licensing Program from Microsoft and even if it is the terms are going to be unsutiable for any sort of development, particularly an open source development.

So, to conclude it's REALLY important that one is able to implement these formats based only on the spec itself. As sson as you ahve to spelunk the source code to an example application you're either not going to be able to get your hands on the code or you'll not get it under suitable licensing terms.

Chris Auld

Monday, March 03, 2008 11:39:18 PM UTC

Hi Chris,

<blockquote cite="chris">Microsoft doesn't have a standard. ECMA has an existing international standard (ECMA 376)and ISO/IEC has a proposed standard DIS29500</blockquote>

Well perhaps I was unclear there. All I meant was the standard typically associated with (and supported by) Microsoft in this debate. I wasn't attempting to suggest that it didn't have other supporters or backers.

<blockquote cite="chris">we're a large way through an implementation of ECMA 376</blockquote>

That would be something interesting to hear more about, as I am sure many are looking into similiar tasks and wondering about difficulty and potential problem areas etc.

How did your implementation efforts go and who is "we"? (if you're able to talk about it).

<blockquote cite="chris">So, to conclude it's REALLY important that one is able to implement these formats based only on the spec itself.</blockquote>

Totally agreed there.

Christopher Fairbairn

Comments are closed.