Hi
Mark the title, this is not the editor, but a framework so an editor can be
made.
Some people use their energy to tell others what cannot be done. I took a
different route,
I tasked myself to find a way where we legally (in ASF terms) could use Qt.
In order to
accomplish that task, I have had a couple of discussions with people
involved in legal, and
who for sure know more about licensing than I do.
First let me give a couple of reflections they gave me:
- Apache ONLY makes source releases, therefore binaries "run it" are not
considered
- Anybody can take our source and make a binary that can depend on foo,
that is
no concern for our release because it is a derived product
- Qt code cannot be part of the source release, independent if it is
optional or not
- Source code using Qt headers and linking with Qt libraries can be
included in
the source release, provided they are truly optional (as in example
code, or 1 of
n consumers).
Given those restraints I designed a framework (presented below), and just
to be sure
I checked it with another project (albeit java) who have similar problems.
Framework (layers are bottom up)
- Layer 0, Actual graphic implementation
Operating system libs, Qt runtime, webkit etc.
These are and cannot be part of our source release
- Layer 1, glue kit and UI design
This layer has 2 main functions:
a) It reads a UI design specification (which happens to have Qt XML format),
and creates the connection to layer 0
b) It contains an API and callbacks to the higher layers.
Remember we only use a very limited part of a full scale UI, which reduces
the size
of this layer dramatically. This is the real critical point, if we cannot
do a major reduction
this framework will not work.
We implement an example of this layer, and by accident we use Qt. Other
developers
might (and most importantly for license reasons "can do it") implement e.g.
webkit.
For test purposes we also implement a NULL version of this layer, thereby
the editor can
link without and third party source.
We supply this source as EXAMPLE source, clearly marked as such.
- Layer 2, UI handling
This layer implements the actual handling, in correspondence with the XML
UI design file.
- Layer 3, Docformat API
Something we need to have for the docformats lib.
- Layer 4, Docfomat with filters
Our main "product".
I recommend we develop along this idea/framework. It has several advantages:
- we can continue our current development undisturbed
- we can make releases without problem
- we do not get sidetracked by having to write our own UI kit.
Should some of us believe we still run into problems when releasing, then
we can
simply release the framework without layer 1 and be very pure (more than
most projects
actually). In this case "libreCorinthia" would consist of layer 1.
But based on the discussions I have had, I am sure we will not have any
other problems,
than those we create ourself.
thoughts?
rgds
jan I.
