Hi, I would like to inform you about my attendance of a workshop from the OSBA  to discuss a potential future project to improve the interoperability of OpenOffice/LibreOffice with the also standardized file format OOXML. But also with focus on an improved and a standardized change tracking proposal.
I attended as individual AOO member and IBM representative. I made clear that I am no official spoke person for AOO and explained once more that we don't really have a hierarchy or formal leaders. One part of the workshop was to review the first project  which was a success for open source but not directly for OpenOffice. We know all that the patches are not yet integrated in AOO. I reported that I have informed the AOO project/community about the availability  of the related patches but that nobody has worked on it so far. And that it is not easy without having access to the test documents. Svante Schubert gave a good overview presentation about the change tracking proposal that is currently discussed and proposed in the related OASIS sub committee. All attendees agreed more or less that it is important to have it more formalized and be part of the ODF standard. Funding to work on the ODF specification is one aspect ... During the workshop new problems were reported and feature requests communicated. This will be me worked out in detail and new use-case specifications will be prepared similar to the first project. When they are available I will share them with the community. Interested developers and companies can give an offer to work on the implementation later, similar to the first project. A further important point was the potential collaboration between OpenOffice and LibreOffice at least on source code level. Some of the sponsors of the first project were not 100% satisfied because they can't benefit from the work they have paid for which I can understand. The availability of patches under ALv2 is not enough to have them integrated. The integration work have to be done and ideally from the people who were paid for. Or at least in time and in collaboration with other volunteers. Anyway something that will be probably improved in the future. Jan Holosevsky from Collabora and a developer on LO and me as a developer from AOO were asked about a proposal/idea how such a collaboration can happen. We all know that it is not so easy to answer and that it comes quite fast to an ideological and political discussion. I simply tried to explain the situation we already have today. In detail I showed the code flow from AOO to LO and the dependency of LO to AOO since their rebase. They mirror our svn repos and merge fixes and features on a regular basis into their code. And most of their source code is under the ALV2 because you can't remove the license. You can only add additional licenses for significant changes you made in a source file. As one possible way for collaboration I proposed to work more directly on the same code base. And that the TDF could continue to provide binaries and could continue with their community work they are doing today (I like of course many things they doing). The only requirement would be to work together on the same code and contribute the changes upstream. I believe this would make most sense and the resources in both project would be used more efficient. And the most important point from my point of view it would reflect the main idea of open source and would benefit the open source spirit. Jan Holesovsky with backing from Simon Phipps proposed that we could use LO code which is under MPLv2. As a reminder the additional MPLv2 is the result of their rebasing work against the AOO code base after our first official release AOO 3.4.1. Well I found not very much information about the exact licensing on their webpage, mainly LGPLv3. And no reference that at least major parts of their code is under ALv2 today. At least to me it looks quite confusing and I am happy that we have it much clearer today. But back to the proposal I have to confess that I don't really understand how this should work in detail. MPL is category-b and we can link against it but we can't host any MPL code in our repo. And it would work on completely new code only that is quite well encapsulated and modularized. It can be potentially an option for some of their new filters but that have to be checked in detail and is only one aspect. We talk about million lines of code mainly. It was also mentioned that mixing of ALv2 and MPL code is possible in general and that it is more a problem of the ASF and the processes applied to projects here at Aapche. I was thinking what it should mean, confuse people even more or an indirect recommendation that OpenOffice should be hosted somewhere else? I stopped thinking about it because it's out of scope I think. If people think I misunderstood things or summarized it incorrect, please feel free to correct me or add missing information. I shared this with you because AOO is a community project and such discussion have to be discussed with the community in the end anyway. I found it interesting to learn from their experience of the first project and to learn what the problems of real users are. It was interesting to see that people from more the outside of the projects are interested to force or seek ways for collaboration on the same common goal, that is the best free office productivity suite. Well they belong to the project as users and are very important because without users we wouldn't have neither AOO nor LO. More information will be shared when it becomes available. And hopefully some volunteers are interested to start working on the OSBA patches to get as much as possible out of them. Juergen  http://www.osb-alliance.de/working-groups/wg-office-interoperability/  http://www.osb-alliance.de/working-groups/projekte/ooxml-filter/  http://www.osb-alliance.de/working-groups/projekte/ooxml-filter/projektergebnisse-ooxml-filter/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org