Subject: Re: Office converters
From: Paul Rohr (paul@abisource.com)
Date: Mon Nov 05 2001 - 12:02:31 CST
Dom's quite right. There are two orthogonal policy issues here:
- which of these options are desirable, and
- if so, are any of them legal?
I've never investigated the technical quality of .cnv converters --
presumably they're better than whatever crippled stuff gets used in WordPad,
right? -- so I'll stick to big picture questions.
1. is .cnv support (of any kind) desirable?
-------------------------------------------
Awesome interoperability has been an explicit goal for AbiWord since day
one:
http://www.abisource.com/mailinglists/abiword-dev/00/January/0486.html
I don't think that anyone would argue that the "right" solution over the
long term is to make sure that our Word (.doc) exporter is every bit as good
as our importer. However, in the interim, it's sometimes hard to decide
which approach is the best to take.
http://www.abisource.com/mailinglists/abiword-dev/00/March/0054.html
http://www.abisource.com/mailinglists/abiword-dev/00/March/0061.html
When I put my "devious marketroid" hat on, I usually ask questions like:
which behaviors do we want to encourage?
- Do we want people to use *documents* in the AbiWord file format,
or do we want them to use AbiWord itself?
- Do we want to save some highly-paid developer in Redmond the effort
of understanding our file format (without being tainted by our GPL
sources) or do we want to encourage our developers to focus on
increasing AbiWord's cross-platform (XP) ability to import/export
various file formats?
In both cases, I personally tend to favor work which improves the quality of
*our* product.
Thus, the idea of leveraging existing .cnvs on only one platform leaves me
lukewarm (because I don't see how it helps our other platforms), and I'd
definitely prefer to *not* create a new .cnv which understands our .abw
format. But that's just my vote, and I wouldn't be doing the work.
2. if so, is it legal?
----------------------
IANAL, and I'm not RMS or Eben Moglen, but I agree with Dom that licensing
problems may make the whole discussion moot.
First off, I'm not familiar with the license(s) on existing .cnv filters
shipped by MSFT and/or others. Can they be redistributed for use by other
word processors? Often the fine print on licenses like this explicitly
*disallows* the use of DLLs like this in competing products. Likewise, is
it OK to use them on other platforms, or are they *legally* Windows-only?
(I assume that with enough WINE-like effort, any technical obstacles could
eventually be overcome.) For that matter, what's the license on the API
used to communicate with such plugins? Is there source available that we
can use, or would the API itself have to be reverse-engineered to be safe?
More to the point though, there are definitely GPL issues on our end.
Specifically, I see *no* way to legally use GPL-licensed source code from
AbiWord to create a .cnv plugin and distribute it for use in proprietary
products like Word. Unless you could track down all the contributors to the
relevant portions of wv and AbiWord, that code is off-limits. This means
that any new .abw-format .cnv plugins would have to be written from scratch
and kept in sync with our .abw improvements over time. That maintenance
problem sounds like a losing battle, and I'd hate to have Word users think
badly of our product because they were using a stale plugin that we
distributed.
On the other hand, it *might* be possible to find a GPL-compatible way to
write an importer and exporter which uses the .cnv API to invoke those
plugins on Windows by arguing that they represent base functionality of the
underlying platform (kind of like making Win32 calls.)
Finally, if those DLLs were usable on other platforms, it *might* also be
possible to follow the Linux precedent and explicitly allow dynamic linkage
to binary-only plugins. However, to do so would again require the explicit
consent of all the relevant copyright holders.
bottom line
-----------
Please keep working towards consensus on whether either approach (using
existing .cnvs or creating a new .cnv) is desirable. However, before
spending too much time on implementations, definitely look into the
licensing issues. ;-)
Hope that helps.
Paul,
old-timer
This archive was generated by hypermail 2b25 : Mon Nov 05 2001 - 11:53:49 CST