How to generate mso.jar (Re: Calligra licensing and copyright bits)

[Friedrich W. H. Kossebau]

Hi Jos,

thanks for the quick and workloaden reaction, great :)

Am Sonntag, 4. Januar 2015, 17:06:26 schrieb Jos van den Oever:
> On Sunday 04 January 2015 02:04:09 Friedrich W. H. Kossebau wrote:
> > Am Donnerstag, 23. Oktober 2014, 23:17:48 schrieb Raúl Sánchez Siles:
> > > Java jar files
> > > ==============
> > > jar files are binary files, as such, in Debian we need the source code
> > > of
> > > those files and generate them on package build (or removing the files
> > > from
> > > the tarball and adding dependencies on the packages that provide these
> > > files).
> > > 
> > > In the jar case, there are some pointers on where the jar comes from,
> > > but
> > > still bundling a generated binary is not desirable.
> > > 
> > > The fixes for that from the licensing point of view are:
> > > - Removing the feature
> > > - If the jar generates code needed at build time, adding the required
> > > (source) files which are generated from the jar. But not the jar. Also
> > > include a script or document a procedure how to get those files.
> > > - If the jar is required as a runtime dependency, you could either add a
> > > run time dependency on a separate package providing that jar or generate
> > > the jar at build time.
> > > 
> > > filters/libmso/generated/mso.jar
> > > 
> > >   As per README in that directory this jar generates some code that's
> > >   used
> > > 
> > > later.
> > > PROPOSAL: Describe (or script) the procedure to generate the code and
> > > remove the jar file.
> > 
> > The README refers to http://www.gitorious.org/msoscheme as the source of
> > mso.jar. Which still exists (good) and seems to be basically done by you,
> > Jos, once upon a time at least. Just, there is no README there and, worse,
> > also no obvious license for msoscheme.
> > And for recursive fun for the good Debian License checking people there is
> > another binary blob inside those sources, from poi.apache.org ;)
> 
> I've added a Readme.md with license information for MSOScheme and POI to the
> repository of MSOscheme now.
> https://www.gitorious.org/msoscheme/msoscheme/
> 
> The POI code is only there for testing the generated java code. This is not
> used by Calligra at all.
> 
> I have updated MSOScheme: it now writes the version of MSOScheme into the
> generated files. The version contains the sha1. So it is always possible to
> find the exact version of MSOScheme to recreate the files simpleParser.h and
> simpleParser.cpp. This means the mso.jar does not need to be part of the
> Calligra source code any more.
> 
> I put up a review request to add the better documentation to calligra.
>   https://git.reviewboard.kde.org/r/121837/
> 
> If the mso.jar should not be part of the Calligra repository, then it should
> be replaced by mso.xml.

Have not yet looked in detail, but already impressed :)

One things though still bugs me: there is no released version of msoscheme, 
right? So when gitorious disappears one day (hopefully not) and you have 
turned evil (more hopefully not), is there any other location where the 
sources of msoscheme might be around? If there would be a release, and at 
least Debian picks the tarball up for generating mso.jar as it seems they want 
to instead of relying on the spyware-loaden^Wfree binary blob there is in 
Calligra repo, chances are higher someone one day could pick up and continue 
work on msoscheme.

So could you perhaps tag the version used for the current mso.jar with a 
release version, for some more official statement? Not sure the commit id is 
nice enough as a reference, as it binds to git as version system.

But Debian people might know better what is needed at minimum, so adding them 
to cc: again.

Cheers
Friedrich