||
|
| | Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|
| 27 | 28 | 29 | 30 | 31 | 1 | 2 | | 3 | 4 | 5 | 6 | 7 | 8 | 9 | | 10 | 11 | 12 | 13 | 14 | 15 | 16 | | 17 | 18 | 19 | 20 | 21 | 22 | 23 | | 24 | 25 | 26 | 27 | 28 | 29 | 1 | | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
|
|
|
|
|
|
 |
 |
Sign In
|
|
 Monday, February 18, 2008
How Feasible Is a Non-GPL ODF Implementation
We had reason to delve into the ODF spec recently. Speficially we were looking at the Blinking Text feature in ODF (no comparable feature in OOXML so well discussed in our OOXML vs ODF shit fight here in New Zealand).
The ODF spec certainly provides details that this feature exists, it doesn't however tell us what it actually does. Sure it makes text blink, but there isn't a whole lot more detail beyond that. We specifically wanted to know how long to blink for. In the end we used a stop watch to time it... we think it's 2.5 seconds on and 1 second off.... at least in OpenOffice it is. But without looking at the OpenOffice source code we can't be sure. And of course, strictly, reverse engineering OpenOffice doesn't make one standards complaint.
But it got me thinking about how easy (or hard) it would actually be to build a good, interoperable, implementation of ODF. If I had to resort to my stopwatch for blinking text what else might I have to reverse engineer? Brian Jones provides a start to the list of application defined bits here. Now I'm guessing that OpenOffice interoperability is sort of the thing to measure ones self against in the ODF space (i.e. the presumption being that just implementing the ODF spec without any of the application specific extensions is not sufficient).
So reverse engineering by observation of behaviour isn't too risky from a legal view point. I can watch how long the text blinks on and off for pretty easily and I'm not likely to find myself encumbered by licences. But, what if there is application defined functionality that cannot be reverse engineered through observation? The obvious solution would be to dive into the source code- but, at that point we might find ourselves caught by the GPL license.
So what's one to do?
I haven't really thought about this situation in a lot of detail so consider this post a starter for discussion rather than a conclusion that you can't do a good interoperable implementation of ODF without being caught by the GPL.
What do others think?
|Monday, February 18, 2008 12:06:04 AM UTC||
|
|
|