Irregular Injection of Opinion
RSS 2.0|Atom 1.0|CDF

 Thursday, 28 February 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.

"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.

.NET | Adventure Sports | PoliTechLaw|Thursday, 28 February 2008 22:56:12 UTC|Comments [3]|