openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From eric b <>
Subject Re: Question related derivative code based on our Apache licensed code
Date Wed, 04 Jan 2012 21:18:18 GMT

Le 4 janv. 12 à 21:28, Joe Schaefer a écrit :

> ----- Original Message -----
>> From: Simon Phipps <>
>> To:
>> Sent: Wednesday, January 4, 2012 3:22 PM
>> Subject: Re: Question related derivative code based on our Apache  
>> licensed code
>> On 4 Jan 2012, at 19:33, Andrew Rist wrote:
>>>  In a similar way, (as I understand it) LO will be able to use  
>>> ALv2 licensed
>> code - but not relicense it.
>> Code can be made available under multiple licenses simultaneously,  
>> as long as none of the licenses in force have terms that are  
>> mutually incompatible. This is especially easy when one of the  
>> licenses is a permissive license with minimal compliance  
>> requirements. Thus another project can typically include code  
>> under a license like AL or BSD and make it available under another  
>> license such as
>> LGPLv3.
> It depends on how that is actually done: just going in and changing  
> licensing on files you have no copyright interest in is actually a  
> violation of copyright law.
> However if you make substantive modifications to those files, that  
> derivative work may be licensed under any terms that are compatible  
> with the original Apache
> license.

Let's try with a concrete example :

OOo4Kids is based on OOo3.2.1 source code, under LGPLv3 license.  
Apache OpenOffice is based on DEV300_m106 (really different)

Imagine now I'm integrating the great SVG native feature Armin wrote.  
After two weeks of work (currently fixing sfx2 chaos), it appears  
that the most simple (sigh) is to partialy and incrementaly rebase  
the concerned code + the dependencies with Apache OpenOffice tree.

Concretely, to achieve that, I modified a lot of code, say around 30  
to 40 modules - over ~180 - , like (cppuhelper, comphelper, basegfx,  
canvas, tools, svtools, toolkit, transex3, svx, sfx2, vcl,  
drawinglayer, framework, offapi and so on). For some modules (e.g.  
offapi) the interface was modified a lot, some dllapi were added etc,  
and the most simple for me is to copy the new files from Apache OOo,  
to the OOo4Kids tree, at the right location (or a no one if not  
existing. Next step consists in fix build issue after build issue.  
e.g. in comphelper, basegfx and cppuhelper, occured some other  
extremely important changes, causing a lot of issues in other  
modules. Plus svl introduction is a nightmare (zillion of #include  
<svl/something.hxx> to be fixed) if I do not create it and so on.

If I add that I'd like to keep the dmake system (working well, on all  
OSs), I even have to modify the tree, adding svgio, svl, cui,  
editeng, and maybe other modules (I probably forgot some, sorry)

Back to license issue :  I didn't know exactly what do, but I was  
lazy so I directly replaced the file containing LGPLv3 headers, with  
the one containing AL headers.

At some other locations, I just adapted Armin changes manually  
(original one from Armin will never apply). Yet at some others, I  
perfecly know how to proceed, without look at the Apache code/files :  
e.g. move goodies filters in filter, create editeng, and all the  
mandatory makefiles and so on. Yet at other places, I did not add  
some useless void functions added in meantime, but empty and doing  
nothing serious and so on***

I forgot:  I didn't commit anything yet, waiting for information  
(thanks to Jürgen who asked the question at the right moment ! )

My question is : am I wrong somewhere (I meant on the license side,  
not on the code side), and if so, what shall I do exactly to respect  
every license ?    :-)

Thanks in advance,
Eric Bachard

*** the only mystery I'll have to solve, is to understand exactly  
what I'll have to modify to use new config manager though. The  
problem is : I'm not able to extract the diffs when the cws was  
integrated, maybe my fault ...

Projet OOo4Kids :
L'association EducOOo :
Blog :

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message