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

[Jos van den Oever]

On 01/10/2015 08:47 PM, Friedrich W. H. Kossebau wrote:
> Am Sonntag, 4. Januar 2015, 20:24:26 schrieb Jos van den Oever:
>> On 01/04/2015 07:43 PM, Friedrich W. H. Kossebau wrote:
>>> thanks for the quick and workloaden reaction, great :)
>>
>> It was some needed work. Happy to help.
>>
>>> 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.
>
> Hm. Usually a repo contains only sources, and all tools needed for creating
> products from those sources are outside the repo. At least those shared with
> others. rng2cpp is an example where the tool is inside the Calligra repo (are
> there more like that here?).
>
> mso.xml could be considered the real source of the generated files which are
> then used by Calligra. Just, those files (in theory) could be useful to other
> projects as well. So mso.xml is currently not really specific to Calligra (and
> thus also not a Calligra source). And the created files simpleParser.{h,cpp}
> are also not Calligra-specific.
>
> In a perfect world there would be some package which installs simpleParser.a
> and simpleParser.h & leinputstream.h, and Calligra would require that package
> and use it during build-time.
>
> Instead, for convenience, we have copies of the intermediate products in the
> Calligra repo.
>
> So to make Debian happy, we possibly could add a switch to not use the
> convenience-copies in the Calligra repo, but require some msosimpleparser
> package and compile and link against that. A package which would be created
> from running msoscheme and installing those files.
>
> Such a package might perhaps also make it more interesting to use for others,
> BTW. Would be willing to assist any needed work.

I disagree that packaging msoscheme is useful. Currently only Calligra 
uses msoscheme and I do not expect that to change. MSOSchem could be 
useful to projects like Document Liberation. But also there, they would 
probably prefer to simply copy the two files.

MSOScheme encourages writing a custom code generator. So the files 
generated would often be different, optimized for each project.

>>> 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.
>>
>> I've now tagged a new/first release: 1.0.0.
>> The code can be downloaded here:
>>     https://www.gitorious.org/msoscheme/msoscheme/archive/1.0.0.tar.gz
>>
>> The version number that is embedded in the generated files is now:
>>      1.0.0-0-g8c6d5941f11a7667b0f915b0e94ef72eb8c42938
>> This is generated by git:
>>      git describe --abbrev=40 --always --long --dirty --tags
>> (The arguments are sorted for maximum comic effect.)
>
> ;) K, thanks, that might be really sufficient (not knowing Debian's rules,
> though :P ).
>
>> I'm fine with mirroring this on kde. Everyone is welcome to clone the
>> repo of course.
>
> (Cloning only still has the danger of missing updates)
> Given that msoscheme has not yet seen and Calligra is the only user, it might
> make sense to host it closer to Calligra. Not sure about the real benefits,
> besides only dying together with Calligra repo in case of KDE goes /dev/null.
> Any 3rd-party ever shown interest? (hm, the mso.xsd still might be interesting
> to look at for some old WIP project for the Structures tool in Okteta, you
> might remember a discussion, but unrelated to central repo location),

Yes, MSOScheme is, despite the name, not specific to binary microsoft 
office files. It would be great if it grows into a general grammar for 
binary files.

>> In the recent past Matus Uzak and Brijesh Patel have worked on mso.xml,
>> so the bus factor is > 1.
>
> Ah, good.
> /me removes bus rerouting rules based on jos' phone coordinates
>

Cheers,
Jos