You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Jürgen Schmidt <jo...@googlemail.com> on 2012/01/04 12:35:38 UTC
Question related derivative code based on our Apache licensed code
Hi,
over the last days i was asking myself how it is exactly with code that
is based on our Apache licensed code.
Well i have read the Apache license but the practical relevance is not
clear for me.
In detail if a derivative project merge our now Apache licensed code
with their code that was based on the former Oracle licensed LGPL code.
This code becomes automatically Apache licensed, correct?
If yes, does it mean that we can use the changes on this code in our
code as well if it is publicly available?
Ok the license say that it is possible to put an additional license on
all changes made on the code when you mark all changes in an appropriate
way. How is that possible or done in practize with many minor changes
(e.g. improve the performance of an existing loop, or initialize
existing variables etc.)? And which license is valid if a trivial change
is made in our (the original) source in the same way, e.g. initialize a
local variable to prevent a warning?
Anyway it seems that the new changed code becomes derivative work
because the Apache license can't be removed.
I hope my question or thoughts are not too stupid and that somebody know
the answer ;-)
Juergen
PS. we talk about thousands of files, many changes and a lot of stupid
necessary work (marking all changes appropriately)
Re: Question related derivative code based on our Apache licensed code
Posted by Pedro Giffuni <pf...@apache.org>.
Hi;
--- Mer 4/1/12, Yong Lin Ma <ma...@gmail.com> ha scritto:
> Here is my understanding.
> LibreOffice can take code from Apache OpenOffice without
> having to change its license.
>
That is not accurate: they can take it but they will have
to add the Apache License. The result is still LGPL3 but
copyright notices are important nevertheless.
BTW, the only reason for them to adopt the AL2 headers
is actually to be able to adopt the MPL2 for the Oracle
code.
Pedro.
Re: Question related derivative code based on our Apache licensed code
Posted by Yong Lin Ma <ma...@gmail.com>.
Here is my understanding.
LibreOffice can take code from Apache OpenOffice without having to change
its license.
No code from LGPL should be used in Apache Project, even if it is trivial
change. But it is possible and allowable that two identical changes been
made independently.
2012/1/4 Jürgen Schmidt <jo...@googlemail.com>
> On 1/4/12 1:08 PM, Simon Phipps wrote:
>
>> My personal opinions on this, naturally:
>>
>> On 4 Jan 2012, at 11:35, Jürgen Schmidt wrote:
>>
>> In detail if a derivative project merge our now Apache licensed code
>>> with their code that was based on the former Oracle licensed LGPL code.
>>> This code becomes automatically Apache licensed, correct?
>>>
>>
>> Probably not, no. The existing LGPLv3 licensed code remains LGPLv3
>> licensed, and as a requirement of the LGPLv3 the new code added to it has
>> to be made available under the LGPLv3 as well. As a consequence, the
>> resulting modified work will be licensed under LGPLv3. The Apache code that
>> was added remains under the Apache license too (which is OK since there is
>> no conflict between the terms of the AL and LGPLv3).
>>
>> are you sure? For me this special situation seems to be a little bit
> different. Either you go forward with the old code and the old license
> header and can't merge to the new code. Or you move forward with the new
> one and keep the new license headers and put your change on a different
> license. Where you would make the difference which code is from which code
> base. For me it sounds practical impossible because the many thousand files
> with more or less the same code.
>
>
> It is really a special situation, isn't it. It would be interesting to
> hear what a lawyer things about it.
>
> Juergen
>
>
>
> If yes, does it mean that we can use the changes on this code in our code
>>> as well if it is publicly available?
>>>
>>
>> No.
>>
>>
>> S.
>>
>
>
Re: Question related derivative code based on our Apache licensed code
Posted by Ross Gardler <rg...@opendirective.com>.
On 4 January 2012 14:17, Simon Phipps <si...@webmink.com> wrote:
>
> On 4 Jan 2012, at 12:59, Jürgen Schmidt wrote:
>
>> On 1/4/12 1:08 PM, Simon Phipps wrote:
>>> My personal opinions on this, naturally:
>>>
>>> On 4 Jan 2012, at 11:35, Jürgen Schmidt wrote:
>>>
>>>> In detail if a derivative project merge our now Apache licensed code with their code that was based on the former Oracle licensed LGPL code. This code becomes automatically Apache licensed, correct?
>>>
>>> Probably not, no. The existing LGPLv3 licensed code remains LGPLv3 licensed, and as a requirement of the LGPLv3 the new code added to it has to be made available under the LGPLv3 as well. As a consequence, the resulting modified work will be licensed under LGPLv3. The Apache code that was added remains under the Apache license too (which is OK since there is no conflict between the terms of the AL and LGPLv3).
>>>
>> are you sure?
>
> Pretty sure, yes. Rob and Ross appear to agree.
Yes, as a general statement I agree with Simon. However, the devil is
always in the detail. Hence my warning about asking generic legal
questions.
The reply above (and those of Rob and myself) makes certain
assumptions about the conditions in which the question can apply. It
is noticeable that the three of us have made different assumptions
about the specifics and thus have provide slightly different answers,
each based on the same generic position.
Specific questions are needed.
Ross
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
Re: Question related derivative code based on our Apache licensed code
Posted by Simon Phipps <si...@webmink.com>.
On 4 Jan 2012, at 12:59, Jürgen Schmidt wrote:
> On 1/4/12 1:08 PM, Simon Phipps wrote:
>> My personal opinions on this, naturally:
>>
>> On 4 Jan 2012, at 11:35, Jürgen Schmidt wrote:
>>
>>> In detail if a derivative project merge our now Apache licensed code with their code that was based on the former Oracle licensed LGPL code. This code becomes automatically Apache licensed, correct?
>>
>> Probably not, no. The existing LGPLv3 licensed code remains LGPLv3 licensed, and as a requirement of the LGPLv3 the new code added to it has to be made available under the LGPLv3 as well. As a consequence, the resulting modified work will be licensed under LGPLv3. The Apache code that was added remains under the Apache license too (which is OK since there is no conflict between the terms of the AL and LGPLv3).
>>
> are you sure?
Pretty sure, yes. Rob and Ross appear to agree.
> For me this special situation seems to be a little bit different. Either you go forward with the old code and the old license header and can't merge to the new code. Or you move forward with the new one and keep the new license headers and put your change on a different license. Where you would make the difference which code is from which code base. For me it sounds practical impossible because the many thousand files with more or less the same code.
>
>
> It is really a special situation, isn't it. It would be interesting to hear what a lawyer things about it.
>
> Juergen
>
>
>>> If yes, does it mean that we can use the changes on this code in our code as well if it is publicly available?
>>
>> No.
>>
>>
>> S.
>
Re: Question related derivative code based on our Apache licensed code
Posted by eric b <er...@free.fr>.
Le 4 janv. 12 à 22:52, Joe Schaefer a écrit :
>> Not exactly :
>>
>> I'd like to take files from Apache repo, and put them into the
>> OOo4Kids
>> one. This needs to adapt OOo4Kids to Apache tree (based on
>> DEV300_m106).
>
> In that case be our guest. You may keep the LGPL licensing on the
> larger work if you so choose, and you may alter the licensing on
> individual files by adding LGPL headers to them (but NOT REMOVING
> Apache License/Copyright headers, just insert a comment saying
> "portions originally licensed under the following...".
>
Ok, thanks for the information. Anyway I'll have a lot of work,
because a lot of files are concerned at the end.
>> At the begining, OOo4Kids (and OOoLight) are "toys" used as a lab,
>> to test Fun and new features with students, or simply to analyze
>> performance issues. The second idea was to reverse interesting
>> code into OOo.
>
> You are free to do whatever you like with your own creative work,
> but please refrain from incorporating 3rd party contributions to
> OOo4Kids into Apache Openoffice without explicit permission from
> the authors of those contributions.
Sure I won't :-) : using svn, every commit is public, and
commented / documented. And when the code is written by someone else,
this is always mentioned. Should be easy to retrieve everything (svn
log e.g.)
Regards,
Eric
--
qɔᴉɹə
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news
Re: Question related derivative code based on our Apache licensed code
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message -----
> From: eric b <er...@free.fr>
> To: ooo-dev@incubator.apache.org
> Cc:
> Sent: Wednesday, January 4, 2012 4:44 PM
> Subject: Re: Question related derivative code based on our Apache licensed code
>
> Hi,
>
> Le 4 janv. 12 à 22:32, Joe Schaefer a écrit :
>
>> I'm having a hard time following your English prose, but I'll take
> a stab at it...
>
>
> Apologies, I'm not a native speaker, and I do my best. Sometimes, I need
> hours to write simple mails :/
>
>
>>
>> So the situation you find yourself in is that you are making use of
> LGPL'd code (OOo 3.2.1), and in the interests of porting over OOo4Kids to
> Apache OpenOffice you need to take portions of that 3.2.1 codebase and commit it
> back to Apache's subversion repo?
>
>
>
> Not exactly :
>
> I'd like to take files from Apache repo, and put them into the OOo4Kids
> one. This needs to adapt OOo4Kids to Apache tree (based on DEV300_m106).
In that case be our guest. You may keep the LGPL licensing on the larger work
if you so choose, and you may alter the licensing on individual files by adding
LGPL headers to them (but NOT REMOVING Apache License/Copyright headers, just
insert a comment saying "portions originally licensed under the following...".
>
>
> About possible backports: I'd like to keep OOo4Kids under LGPL v3, but
> I'm ok to reverse features considered as enough interesting to be integrated
> into Apache OOo (I hope I'm clear)
>
> At the begining, OOo4Kids (and OOoLight) are "toys" used as a lab, to
> test Fun and new features with students, or simply to analyze performance
> issues. The second idea was to reverse interesting code into OOo.
You are free to do whatever you like with your own creative work, but please
refrain from incorporating 3rd party contributions to OOo4Kids into Apache
Openoffice without explicit permission from the authors of those contributions.
HTH
Re: Question related derivative code based on our Apache licensed code
Posted by eric b <er...@free.fr>.
Hi,
Le 4 janv. 12 à 22:32, Joe Schaefer a écrit :
> I'm having a hard time following your English prose, but I'll take
> a stab at it...
Apologies, I'm not a native speaker, and I do my best. Sometimes, I
need hours to write simple mails :/
>
> So the situation you find yourself in is that you are making use of
> LGPL'd code (OOo 3.2.1), and in the interests of porting over
> OOo4Kids to Apache OpenOffice you need to take portions of that
> 3.2.1 codebase and commit it back to Apache's subversion repo?
Not exactly :
I'd like to take files from Apache repo, and put them into the
OOo4Kids one. This needs to adapt OOo4Kids to Apache tree (based on
DEV300_m106).
About possible backports: I'd like to keep OOo4Kids under LGPL v3,
but I'm ok to reverse features considered as enough interesting to be
integrated into Apache OOo (I hope I'm clear)
At the begining, OOo4Kids (and OOoLight) are "toys" used as a lab, to
test Fun and new features with students, or simply to analyze
performance issues. The second idea was to reverse interesting code
into OOo.
> If so, the answer is that you can only commit back the changes to
> the original codebase that *you* made to it, assuming as you claim
> that the changes are significantly different from what's currently
> in our subversion repo. You should not commit back code from OOo
> 3.2.1 that is not either your own work or significantly different
> from what's already in the subversion repo. (Sorry for the double
> negatives there).
>
> Does that answer your question?
I'm not sure (please read above) :)
Regards,
Eric
--
qɔᴉɹə
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news
Re: Question related derivative code based on our Apache licensed code
Posted by Joe Schaefer <jo...@yahoo.com>.
I'm having a hard time following your English prose, but I'll take a
stab at it...
So the situation you find yourself in is that you are making use of LGPL'd
code (OOo 3.2.1), and in the interests of porting over OOo4Kids to Apache OpenOffice
you need to take portions of that 3.2.1 codebase and commit it back to Apache's
subversion repo?
If so, the answer is that you can only commit back the changes to the original
codebase that *you* made to it, assuming as you claim that the changes are
significantly different from what's currently in our subversion repo. You
should not commit back code from OOo 3.2.1 that is not either your own work
or significantly different from what's already in the subversion repo.
(Sorry for the double negatives there).
Does that answer your question?
----- Original Message -----
> From: eric b <er...@free.fr>
> To: ooo-dev@incubator.apache.org
> Cc:
> Sent: Wednesday, January 4, 2012 4:18 PM
> Subject: Re: Question related derivative code based on our Apache licensed code
>
> Hi,
>
>
> Le 4 janv. 12 à 21:28, Joe Schaefer a écrit :
>
>> ----- Original Message -----
>>
>>> From: Simon Phipps <si...@webmink.com>
>>> To: ooo-dev@incubator.apache.org
>>> 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 ...
>
> --qɔᴉɹə
> Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
> L'association EducOOo : http://www.educoo.org
> Blog : http://eric.bachard.org/news
>
Re: Question related derivative code based on our Apache licensed code
Posted by eric b <er...@free.fr>.
Hi,
Le 4 janv. 12 à 21:28, Joe Schaefer a écrit :
> ----- Original Message -----
>
>> From: Simon Phipps <si...@webmink.com>
>> To: ooo-dev@incubator.apache.org
>> 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 ...
--
qɔᴉɹə
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news
Re: Question related derivative code based on our Apache licensed code
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message -----
> From: Simon Phipps <si...@webmink.com>
> To: ooo-dev@incubator.apache.org
> Cc:
> Sent: Wednesday, January 4, 2012 3:41 PM
> Subject: Re: Question related derivative code based on our Apache licensed code
>
>
> On 4 Jan 2012, at 20:28, Joe Schaefer wrote:
>> It depends on how that is actually done:
>
> There is indeed plenty of detail to take into consideration, and we could
> ping-pong the discussion around many nuances if we wanted to (for example:
> there's often no need to edit the file to change the way it is licensed as
> part of a larger work).
>
> One benefit there seems to be from having me join a thread is people add a lot
> more detail to the discussion in order to correct me, even when we agree.
> Suffice to say we're generally agreed that Jürgen's original assumption
> ("This code becomes automatically Apache licensed, correct?") is
> probably not right :-)
Yes, well the point I'm trying to make is that for *our* purposes (eg interpreting the
licensing on a "contribution" to a derivative work) the *unmodified files* that
are only marked as having Apache license headers in them govern patches based
solely on such files, irrespective of the licensing on a larger derivative work
of the whole work. *And* that such unmodified files will be present in
many derivatives that make use of our codebase.
I realize that wasn't quite the question Jürgen asked, but it's a better question
to address ;-). Sorry for the potential confusion.
RE: Question related derivative code based on our Apache licensed code
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Agreed. The misconception is that the last guy to modify some code not created by that person gets to put his license over all of it.
>From that point on, there are no valid deductions.
- Dennis
-----Original Message-----
From: Simon Phipps [mailto:simon@webmink.com]
Sent: Wednesday, January 04, 2012 12:41
To: ooo-dev@incubator.apache.org
Subject: Re: Question related derivative code based on our Apache licensed code
On 4 Jan 2012, at 20:28, Joe Schaefer wrote:
> It depends on how that is actually done:
There is indeed plenty of detail to take into consideration, and we could ping-pong the discussion around many nuances if we wanted to (for example: there's often no need to edit the file to change the way it is licensed as part of a larger work).
One benefit there seems to be from having me join a thread is people add a lot more detail to the discussion in order to correct me, even when we agree. Suffice to say we're generally agreed that Jürgen's original assumption ("This code becomes automatically Apache licensed, correct?") is probably not right :-)
S.
[IANAL & DNPOOTV]=
Re: Question related derivative code based on our Apache licensed code
Posted by Simon Phipps <si...@webmink.com>.
On 4 Jan 2012, at 20:28, Joe Schaefer wrote:
> It depends on how that is actually done:
There is indeed plenty of detail to take into consideration, and we could ping-pong the discussion around many nuances if we wanted to (for example: there's often no need to edit the file to change the way it is licensed as part of a larger work).
One benefit there seems to be from having me join a thread is people add a lot more detail to the discussion in order to correct me, even when we agree. Suffice to say we're generally agreed that Jürgen's original assumption ("This code becomes automatically Apache licensed, correct?") is probably not right :-)
S.
[IANAL & DNPOOTV]
Re: Question related derivative code based on our Apache licensed code
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message -----
> From: Simon Phipps <si...@webmink.com>
> To: ooo-dev@incubator.apache.org
> Cc:
> 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.
Modulo the usual discrepancies about the virality of the *GPL in the case of sublicensed
(not "relicensed") code, the above is the ASF's position on the subject AIUI.
>
Re: Question related derivative code based on our Apache licensed code
Posted by Simon Phipps <si...@webmink.com>.
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.
S.
[IANAL etc]
Re: Question related derivative code based on our Apache licensed
code
Posted by Andrew Rist <an...@oracle.com>.
On 1/4/2012 6:38 AM, Pedro Giffuni wrote:
> --- Mer 4/1/12, Jürgen Schmidt ha scritto:
> ...
>> are you sure? For me this special situation seems to be a
>> little bit different. Either you go forward with the old
>> code and the old license header and can't merge to the new
>> code. Or you move forward with the new one and keep the new
>> license headers and put your change on a different
>> license. Where you would make the difference which code is
>> from which code base. For me it sounds practical impossible
>> because the many thousand files with more or less the same
>> code.
>>
> The problem is that TDF, or whomever adopts the Apache OO
> headers, doesn't own the modified (MPL/LGPL3) code so even
> if they wanted they can not make it AL2. What will happen
> is that the code will keep the MPL/LGPL3 restrictions in
> addition to the AL2.
I think most of the LO code is just under LGPL, with only their
additions being dual licensed under MPL (I don't think they can
relicense the LGPL code).
In a similar way, (as I understand it) LO will be able to use ALv2
licensed code - but not relicense it.
>
> Nevertheless there will be two consequences:
> - They can have all their code uniformly under LGPL3/MPL2
> dual license. The LGPL being so commercially unfriendly,
> this practically means they will be MPL2, with the LGPL3
> being purely nominal.
> - They will have to carry the AL2 license among their code
> and headers, and the clause 5 is particularly nice to have.
>
> If you add these two points, and this is all IMHO, the
> great loser in all this is the FSF that lost the strong
> copyleft over the flag opensource Office suite.
>
>> It is really a special situation, isn't it. It would be
>> interesting to
>> hear what a lawyer things about it.
>>
> Oh .. I am not a lawyer, so it was all meant IMHO :).
>
> cheers,
>
> Pedro.
Re: Question related derivative code based on our Apache licensed code
Posted by Ross Gardler <rg...@opendirective.com>.
On 16 January 2012 15:41, Norbert Thiebaud <nt...@gmail.com> wrote:
> On Mon, Jan 16, 2012 at 9:28 AM, Pedro Giffuni <pf...@apache.org> wrote:
>>
>> It is really nice because in this project we don't request
>> silly licensing statements. We assume people are not
>> stupid enough to send us code that we can't use.
>
> oh really ?
>
> Is that Apache's position that any code than end-up in an Apache
> Mailing list is 'assumed' to be under AL2 ?
It is the ASFs position that we do not take code that has not been
willingly contributed to us.
What this means in practical terms is that if we are not certain that
the code was intended as a contribution then we will not use it.
Furthermore, if we have any reason to doubt that the contributor is
authorised to make that contribution then we will not accept it.
Ross
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
Re: Question related derivative code based on our Apache licensed code
Posted by Norbert Thiebaud <nt...@gmail.com>.
On Mon, Jan 16, 2012 at 9:28 AM, Pedro Giffuni <pf...@apache.org> wrote:
>
> It is really nice because in this project we don't request
> silly licensing statements. We assume people are not
> stupid enough to send us code that we can't use.
oh really ?
Is that Apache's position that any code than end-up in an Apache
Mailing list is 'assumed' to be under AL2 ?
Norbert
RE: Question related derivative code based on our Apache licensed code
Posted by "Dennis E. Hamilton" <de...@acm.org>.
OT: <http://www.amazon.com/Allegro-non-troppo-Contrappunti-Italian/dp/8815019804/>?
It is conceivable that Cipola produced the English versions himself. A number of his papers have English-language titles.
But the Italian title, leads to these: <http://www.bing.com/search?q=%22Le%20%20leggi%20fundamentali%20della%20stupidita%22&FORM=BB07LB&PC=BB07&QS=n>
The full title is "Le leggi fundamentali della stupidità humana" and I see there is a Facebook group for it (?!).
- Dennis
-----Original Message-----
From: Pedro Giffuni [mailto:pfg@apache.org]
Sent: Monday, January 16, 2012 07:28
To: ooo-dev@incubator.apache.org; michael.meeks@suse.com
Subject: Re: Question related derivative code based on our Apache licensed code
[ ... ]
It is really nice because in this project we don't request
silly licensing statements. We assume people are not
stupid enough to send us code that we can't use. Here
the term "stupid" has the same connotation as defined in
Carlo Cipola's classical paper:
http://cantrip.org/stupidity.html
(BTW, Anyone has a link to the original in italian?)
cheers,
Pedro.
RE: Question related derivative code based on our Apache licensed code
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Oracle required copyright assignment and had all the rights it needed to license the code base to the ASF. That is a different conversation than the honoring of licenses and directing ones contributions under one license or another.
- Dennis
-----Original Message-----
From: Bjoern Michaelsen [mailto:bjoern.michaelsen@canonical.com]
Sent: Monday, January 16, 2012 17:11
To: ooo-dev@incubator.apache.org
Subject: Re: Question related derivative code based on our Apache licensed code
Hi Rob,
On Mon, Jan 16, 2012 at 07:07:03PM -0500, Rob Weir wrote:
> That "mutual respect" argument can take you in strange places. For
> example, if a LibreOffice contributor modifies a file that was
> originally authored by someone who is now an Apache OpenOffice
> contributor, then shouldn't they put that file under ALv2, in order to
> "respect the wishes of contributors caring about the license"?
You mean like for example Oracle changing its mind and not only relicensing
their own contributions, but also past contributions of others without even
consulting these authors should force everyone to follow suit(*)? No,
fortunately the beauty of a license -- intentionally chosen by the author at
the time -- is that it gives you the freedom _not_ to be forced to do so
because the rights once given cant be revoked and thus the license is a source
of security and sustainability for everyone.
Best,
Bjoern
(*) Or as asked so eloquently elsewhere:
"And Oracle's private conversations, and their decisions regarding OOo contrary
to the community, were somehow acceptable?"
http://mail-archives.apache.org/mod_mbox/incubator-general/201201.mbox/%3CCABD8fLWRDfcABcwyKOsVBpWagkQPoihzkn=DY13U=3bKjPZekw@mail.gmail.com%3E
Re: Question related derivative code based on our Apache licensed
code
Posted by Bjoern Michaelsen <bj...@canonical.com>.
Hi Rob,
On Mon, Jan 16, 2012 at 09:05:03PM -0500, Rob Weir wrote:
> I assume their views on licensing are more flexible than yours.
My personal view on licensing is very liberal: In general, as long as it is
open and forkable, I personally am good because a possible fork will either
keep everyone in line or the offender will be superseded by the fork. However,
when it is about a project my personal view is just one voice among others and
I respect the wishes of other contributors when selecting a license for a
project, esp. if they provide major shares -- as they clearly do for
LibreOffice contributors, both corporate sponsored and volunteers.
> So back to my question, which you did not answer.
Which part of:
> > No, fortunately the beauty of a license -- intentionally chosen by the
> > author at the time -- is that it gives you the freedom _not_ to be forced
> > to do so because the rights once given cant be revoked and thus the license
> > is a source of security and sustainability for everyone.
is unclear to you? The thing to respect -- both morally and legally -- is the
license given by the contributor when publishing, which LibreOffice does very
faithfully. Everything else would be madness as one would morally subject
oneself to the future caprice of each and every contributor and his heirs. That
is even more true for organizations (like XFree86 or Sun and its heir Oracle).
So again: The answer to your question is a clear and resounding "No".
Best,
Bjoern
Re: Question related derivative code based on our Apache licensed code
Posted by Rob Weir <ro...@apache.org>.
On Mon, Jan 16, 2012 at 8:10 PM, Bjoern Michaelsen
<bj...@canonical.com> wrote:
> Hi Rob,
>
> On Mon, Jan 16, 2012 at 07:07:03PM -0500, Rob Weir wrote:
>> That "mutual respect" argument can take you in strange places. For
>> example, if a LibreOffice contributor modifies a file that was
>> originally authored by someone who is now an Apache OpenOffice
>> contributor, then shouldn't they put that file under ALv2, in order to
>> "respect the wishes of contributors caring about the license"?
>
> You mean like for example Oracle changing its mind and not only relicensing
> their own contributions, but also past contributions of others without even
> consulting these authors should force everyone to follow suit(*)? No,
I certainly acknowledge that there are some contributors to OOo who
were not happy that Oracle contributed the code to Apache under ALv2.
But it is also clear that there are some contributors to the legacy
OOo who were happy to see this change, and who have joined the Apache
OpenOffice project and signed the ICLA and contribute. And there are
some legacy contributors who are members both of TDF and AOO. I
assume their views on licensing are more flexible than yours. And I
imagine that there are some that think it was a bad thing to accept
MPL for LibreOffice at all.
So back to my question, which you did not answer. If a LibreOffice
contributor modifies a file that was originally authored by someone
who is now an Apache OpenOffice contributor (i.e., someone who has
signed the ICLA and joined the AOO project), then shouldn't the LO
contributor put their modifications under ALv2 as well, in order to
"respect the wishes of contributors caring about the license"? It
seems this would be the right thing to do, given your arguments above.
-Rob
> fortunately the beauty of a license -- intentionally chosen by the author at
> the time -- is that it gives you the freedom _not_ to be forced to do so
> because the rights once given cant be revoked and thus the license is a source
> of security and sustainability for everyone.
>
> Best,
>
> Bjoern
>
> (*) Or as asked so eloquently elsewhere:
> "And Oracle's private conversations, and their decisions regarding OOo contrary
> to the community, were somehow acceptable?"
> http://mail-archives.apache.org/mod_mbox/incubator-general/201201.mbox/%3CCABD8fLWRDfcABcwyKOsVBpWagkQPoihzkn=DY13U=3bKjPZekw@mail.gmail.com%3E
Re: Question related derivative code based on our Apache licensed
code
Posted by Bjoern Michaelsen <bj...@canonical.com>.
Hi Rob,
On Mon, Jan 16, 2012 at 07:07:03PM -0500, Rob Weir wrote:
> That "mutual respect" argument can take you in strange places. For
> example, if a LibreOffice contributor modifies a file that was
> originally authored by someone who is now an Apache OpenOffice
> contributor, then shouldn't they put that file under ALv2, in order to
> "respect the wishes of contributors caring about the license"?
You mean like for example Oracle changing its mind and not only relicensing
their own contributions, but also past contributions of others without even
consulting these authors should force everyone to follow suit(*)? No,
fortunately the beauty of a license -- intentionally chosen by the author at
the time -- is that it gives you the freedom _not_ to be forced to do so
because the rights once given cant be revoked and thus the license is a source
of security and sustainability for everyone.
Best,
Bjoern
(*) Or as asked so eloquently elsewhere:
"And Oracle's private conversations, and their decisions regarding OOo contrary
to the community, were somehow acceptable?"
http://mail-archives.apache.org/mod_mbox/incubator-general/201201.mbox/%3CCABD8fLWRDfcABcwyKOsVBpWagkQPoihzkn=DY13U=3bKjPZekw@mail.gmail.com%3E
Re: Question related derivative code based on our Apache licensed code
Posted by Rob Weir <ro...@apache.org>.
On Mon, Jan 16, 2012 at 6:40 PM, Bjoern Michaelsen
<bj...@canonical.com> wrote:
> Hi Rob,
>
> On Mon, Jan 16, 2012 at 03:51:26PM -0500, Rob Weir wrote:
>> As far as I can tell, there is nothing that would prevent an
>> individual developer from submitting a patch to this mailing list or
>> to the LO mailing list and saying it was available AL2 or MPL/LGPL at
>> the receiver's election.
>
> Only if you are willing to ignore the rights of previous contributors upon
> whose work the patch is based and who contributed their work as MPL/LGPL/GPL.
That's the wonderful thing about a patch. It is just a delta. So
long as the patch itself is original work, then the patch can be
contributed without violating anyone's license, and can be applied to
AOO without violating anyone's license.
Of course, if someone is patching a feature that only exists in LO,
then creating a pure patch for AOO may not be possible. But I assure
you that I am only interested in what is possible ;-)
> Some LibreOffice contributors care very much about not carelessly giving away
> their contribution AL-licensed, while others contribute to the LibreOffice
> project for its openness, features and agility. Mutual respect requires to
> respect the wishes of contributors caring about the license, which was one
> important founding principles of the project, as well as we care for the other
> values put down in the manifesto of the document foundation.
>
That "mutual respect" argument can take you in strange places. For
example, if a LibreOffice contributor modifies a file that was
originally authored by someone who is now an Apache OpenOffice
contributor, then shouldn't they put that file under ALv2, in order to
"respect the wishes of contributors caring about the license"?
-Rob
> Best,
>
> Bjoern
Re: Question related derivative code based on our Apache licensed code
Posted by Pedro Giffuni <pf...@apache.org>.
--- Lun 16/1/12, Joe Schaefer ha scritto:
...
> You're probably right about the copyrightability
> of trivial patches. If there's really only one
> obvious way of doing something, that expression
> typically doesn't enjoy copyright protection.
>
> In any case you should expect people to be conscientious
> about their licensing choices, particularly people with
> GPL stripes. But if the ideas are good, you're certainly
> allowed to reuse them so long as the expression is your
> own creation.
>
In this case I wouldn't consider the patches trivial. I
recall vaguely someone mentioning that for the FSF three
lines of code were not copyrightable. These were big
changes but still they were not copyrightable.
In any case I surely agree, the correct thing to do is
ask first and in general respect people's opinions.
Pedro.
Re: Question related derivative code based on our Apache licensed code
Posted by Joe Schaefer <jo...@yahoo.com>.
You're probably right about the copyrightability
of trivial patches. If there's really only one
obvious way of doing something, that expression
typically doesn't enjoy copyright protection.
In any case you should expect people to be conscientious
about their licensing choices, particularly people with
GPL stripes. But if the ideas are good, you're certainly
allowed to reuse them so long as the expression is your
own creation.
>________________________________
> From: Pedro Giffuni <pf...@apache.org>
>To: ooo-dev@incubator.apache.org; Joe Schaefer <jo...@yahoo.com>
>Sent: Monday, January 16, 2012 8:13 PM
>Subject: Re: Question related derivative code based on our Apache licensed code
>
>--- Lun 16/1/12, Joe Schaefer ha scritto:
>...
>> Kinda hard to claim you own all the
>> rights to
>>
>> a patch when in 99% of the situations it's merely
>> a derivative work of the thing you produced the
>> patch from.
>>
>
>FWIW .. I have asked for two set of patches from
>LibreOffice authors and my request on both cases
>was rejected:
>
>1. Patches to build with clang.
>2. Patches to replace uses of STLport with
>boost.
>
>I personally think neither of those changes are
>copyrightable as the changes are pretty easy to
>reproduce without looking at them.
>
>For the rest I don't find the LO changes too
>interesting at all. I do see some of our changes
>would be interesting to them but I don't think
>they have sufficient developers to keep up with
>our changes anyways.
>
>Despite of this, the core of both is still the
>SUN/oracle code and the code is not hugely
>different yet, perhaps (and it's just my
>speculation) 5-6 years of constant development
>will still be needed for LO to gain it's own
>identity at a source level and even then the
>origin will still be traceable.
>
>Pedro.
>
>
>
>
Re: Question related derivative code based on our Apache licensed code
Posted by Rob Weir <ro...@apache.org>.
On Mon, Jan 16, 2012 at 7:06 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> Kinda hard to claim you own all the rights to
>
> a patch when in 99% of the situations it's merely
> a derivative work of the thing you produced the
> patch from.
>
> In any case if the patch will be applicable to
> either codebase, and the author of the patch
> deems it appropriate to include in either of
> them, there is no need to haggle further over
> it, from either camp.
>
I think that's the key point. The cases where it would not work from
the license perspective are the same cases where it would not work
from the technical perspective. Any useful patch could be applied to
both AOO and LO would be a patch to the common OOo base code.
>
>
>
>
>>________________________________
>> From: Ross Gardler <rg...@opendirective.com>
>>To: ooo-dev@incubator.apache.org
>>Sent: Monday, January 16, 2012 7:01 PM
>>Subject: Re: Question related derivative code based on our Apache licensed code
>>
>>On 16 January 2012 23:40, Bjoern Michaelsen
>><bj...@canonical.com> wrote:
>>> Hi Rob,
>>>
>>> On Mon, Jan 16, 2012 at 03:51:26PM -0500, Rob Weir wrote:
>>>> As far as I can tell, there is nothing that would prevent an
>>>> individual developer from submitting a patch to this mailing list or
>>>> to the LO mailing list and saying it was available AL2 or MPL/LGPL at
>>>> the receiver's election.
>>>
>>> Only if you are willing to ignore the rights of previous contributors upon
>>> whose work the patch is based and who contributed their work as MPL/LGPL/GPL.
>>
>>Although Rob didn't say it he actually meant "an individual developer
>>from submitting a patch ***to which they own all rights***"
>>
>>Ross
>>
>>
>>
Re: Question related derivative code based on our Apache licensed code
Posted by Ross Gardler <rg...@opendirective.com>.
On 17 January 2012 00:06, Joe Schaefer <jo...@yahoo.com> wrote:
> Kinda hard to claim you own all the rights to
>
> a patch when in 99% of the situations it's merely
> a derivative work of the thing you produced the
> patch from.
heh - good point. I think I was assuming we were talking about a patch
from a shared code-base, e.g. the original Sun/Oracle code. However,
you are right as things diverge this will become less and less the
common.
> In any case if the patch will be applicable to
> either codebase, and the author of the patch
> deems it appropriate to include in either of
> them, there is no need to haggle further over
> it, from either camp.
Also true.
Ross
>
>>________________________________
>> From: Ross Gardler <rg...@opendirective.com>
>>To: ooo-dev@incubator.apache.org
>>Sent: Monday, January 16, 2012 7:01 PM
>>Subject: Re: Question related derivative code based on our Apache licensed code
>>
>>On 16 January 2012 23:40, Bjoern Michaelsen
>><bj...@canonical.com> wrote:
>>> Hi Rob,
>>>
>>> On Mon, Jan 16, 2012 at 03:51:26PM -0500, Rob Weir wrote:
>>>> As far as I can tell, there is nothing that would prevent an
>>>> individual developer from submitting a patch to this mailing list or
>>>> to the LO mailing list and saying it was available AL2 or MPL/LGPL at
>>>> the receiver's election.
>>>
>>> Only if you are willing to ignore the rights of previous contributors upon
>>> whose work the patch is based and who contributed their work as MPL/LGPL/GPL.
>>
>>Although Rob didn't say it he actually meant "an individual developer
>>from submitting a patch ***to which they own all rights***"
>>
>>Ross
>>
>>
>>
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
Re: Question related derivative code based on our Apache licensed code
Posted by Pedro Giffuni <pf...@apache.org>.
--- Lun 16/1/12, Joe Schaefer ha scritto:
...
> Kinda hard to claim you own all the
> rights to
>
> a patch when in 99% of the situations it's merely
> a derivative work of the thing you produced the
> patch from.
>
FWIW .. I have asked for two set of patches from
LibreOffice authors and my request on both cases
was rejected:
1. Patches to build with clang.
2. Patches to replace uses of STLport with
boost.
I personally think neither of those changes are
copyrightable as the changes are pretty easy to
reproduce without looking at them.
For the rest I don't find the LO changes too
interesting at all. I do see some of our changes
would be interesting to them but I don't think
they have sufficient developers to keep up with
our changes anyways.
Despite of this, the core of both is still the
SUN/oracle code and the code is not hugely
different yet, perhaps (and it's just my
speculation) 5-6 years of constant development
will still be needed for LO to gain it's own
identity at a source level and even then the
origin will still be traceable.
Pedro.
Re: Question related derivative code based on our Apache licensed code
Posted by Joe Schaefer <jo...@yahoo.com>.
Kinda hard to claim you own all the rights to
a patch when in 99% of the situations it's merely
a derivative work of the thing you produced the
patch from.
In any case if the patch will be applicable to
either codebase, and the author of the patch
deems it appropriate to include in either of
them, there is no need to haggle further over
it, from either camp.
>________________________________
> From: Ross Gardler <rg...@opendirective.com>
>To: ooo-dev@incubator.apache.org
>Sent: Monday, January 16, 2012 7:01 PM
>Subject: Re: Question related derivative code based on our Apache licensed code
>
>On 16 January 2012 23:40, Bjoern Michaelsen
><bj...@canonical.com> wrote:
>> Hi Rob,
>>
>> On Mon, Jan 16, 2012 at 03:51:26PM -0500, Rob Weir wrote:
>>> As far as I can tell, there is nothing that would prevent an
>>> individual developer from submitting a patch to this mailing list or
>>> to the LO mailing list and saying it was available AL2 or MPL/LGPL at
>>> the receiver's election.
>>
>> Only if you are willing to ignore the rights of previous contributors upon
>> whose work the patch is based and who contributed their work as MPL/LGPL/GPL.
>
>Although Rob didn't say it he actually meant "an individual developer
>from submitting a patch ***to which they own all rights***"
>
>Ross
>
>
>
Re: Question related derivative code based on our Apache licensed code
Posted by Ross Gardler <rg...@opendirective.com>.
On 16 January 2012 23:40, Bjoern Michaelsen
<bj...@canonical.com> wrote:
> Hi Rob,
>
> On Mon, Jan 16, 2012 at 03:51:26PM -0500, Rob Weir wrote:
>> As far as I can tell, there is nothing that would prevent an
>> individual developer from submitting a patch to this mailing list or
>> to the LO mailing list and saying it was available AL2 or MPL/LGPL at
>> the receiver's election.
>
> Only if you are willing to ignore the rights of previous contributors upon
> whose work the patch is based and who contributed their work as MPL/LGPL/GPL.
Although Rob didn't say it he actually meant "an individual developer
from submitting a patch ***to which they own all rights***"
Ross
Re: Question related derivative code based on our Apache licensed
code
Posted by Bjoern Michaelsen <bj...@canonical.com>.
Hi Rob,
On Mon, Jan 16, 2012 at 03:51:26PM -0500, Rob Weir wrote:
> As far as I can tell, there is nothing that would prevent an
> individual developer from submitting a patch to this mailing list or
> to the LO mailing list and saying it was available AL2 or MPL/LGPL at
> the receiver's election.
Only if you are willing to ignore the rights of previous contributors upon
whose work the patch is based and who contributed their work as MPL/LGPL/GPL.
Some LibreOffice contributors care very much about not carelessly giving away
their contribution AL-licensed, while others contribute to the LibreOffice
project for its openness, features and agility. Mutual respect requires to
respect the wishes of contributors caring about the license, which was one
important founding principles of the project, as well as we care for the other
values put down in the manifesto of the document foundation.
Best,
Bjoern
Re: Question related derivative code based on our Apache licensed code
Posted by Simon Phipps <si...@webmink.com>.
On 17 Jan 2012, at 01:46, Dennis E. Hamilton wrote:
> Perhaps one source of misunderstanding at AOO is the notion that a contribution to Apache OpenOffice is transitively available to LibreOffice by virtue of ALv2.
Thanks, Dennis. This is actually true in both directions. There is more to making a contribution to any project that just posting code under their preferred license to an arbitrary place on the internet.
S.
RE: Question related derivative code based on our Apache licensed code
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I see no effort to weaken affiliation with LibreOffice. I see prominent affiliation by participants on Apache OpenOffice with LibreOffice (and consequently vice versa). That there are individuals on each project that find cooperation unappealing has not hindered cross-contribution.
Perhaps one source of misunderstanding at AOO is the notion that a contribution to Apache OpenOffice is transitively available to LibreOffice by virtue of ALv2. As Michael Meeks remarks, it is not quite that easy (but not impossible, as is the case for the reverse direction). It does require a level of attribution and preservation of provenance that tends to be disdained among some open-source communities. ("Relicensing" is an unfortunate myth. But combination into an other-licensed work is not and it is completely possible with ALv2-licensed material.)
In the case of modest patches, I think it is a matter of where the contributor who has the rights to do so actually contributes the patch. It is strange to affirm any license other than that used by the project the contribution is made to. It is also awkward to submit a patch in more than one place.
Contributing to a shared place with it being clear there are no additional strings attached gets around all of this. That could happen when a patch is submitted without additional ceremony to a commonly-subscribed security list, for example. And, in that case, a multi-license declaration might work more easily too.
- Dennis
-----Original Message-----
From: Simon Phipps [mailto:simon@webmink.com]
Sent: Monday, January 16, 2012 17:18
To: ooo-dev@incubator.apache.org
Subject: Re: Question related derivative code based on our Apache licensed code
On 17 Jan 2012, at 01:07, Joe Schaefer wrote:
> Did you have trouble with the part where
> he wrote "this mailing list"? In any case
> we have 1-way compatibility from AL to LGPL
> so there's little technical need for it.
No, Joe, I spotted that, but thanks for your concern.
This meme only arises in Rob's communications in connection with LibreOffice contributors being encouraged to join Apache. Licensing is as much a community choice as it is a mechanical matter, and as a member of both communities I have observed that the apparent encouragement to weaken affiliation with LibreOffice diminishes Apache's credibility among many LibreOffice community members.
My comment to Rob was by way of a reminder that it would be better to stop acting divisively like this. My apologies if this brevity was confusing.
S.
Re: Question related derivative code based on our Apache licensed code
Posted by Rob Weir <ro...@apache.org>.
On Mon, Jan 16, 2012 at 8:17 PM, Simon Phipps <si...@webmink.com> wrote:
>
> On 17 Jan 2012, at 01:07, Joe Schaefer wrote:
>
>> Did you have trouble with the part where
>> he wrote "this mailing list"? In any case
>> we have 1-way compatibility from AL to LGPL
>> so there's little technical need for it.
>
> No, Joe, I spotted that, but thanks for your concern.
>
> This meme only arises in Rob's communications in connection with LibreOffice contributors being encouraged to join Apache. Licensing is as much a community choice as it is a mechanical matter, and as a member of both communities I have observed that the apparent encouragement to weaken affiliation with LibreOffice diminishes Apache's credibility among many LibreOffice community members.
>
> My comment to Rob was by way of a reminder that it would be better to stop acting divisively like this. My apologies if this brevity was confusing.
>
Simon,
If you think it is divisive for me to encourage people to join Apache,
use the Apache license and to download and install Apache products,
then I must apologize profusely for that, as well as the far greater
anguish I will surely be causing you in the future.
-Rob
> S.
>
Re: Question related derivative code based on our Apache licensed code
Posted by Simon Phipps <si...@webmink.com>.
On 17 Jan 2012, at 01:07, Joe Schaefer wrote:
> Did you have trouble with the part where
> he wrote "this mailing list"? In any case
> we have 1-way compatibility from AL to LGPL
> so there's little technical need for it.
No, Joe, I spotted that, but thanks for your concern.
This meme only arises in Rob's communications in connection with LibreOffice contributors being encouraged to join Apache. Licensing is as much a community choice as it is a mechanical matter, and as a member of both communities I have observed that the apparent encouragement to weaken affiliation with LibreOffice diminishes Apache's credibility among many LibreOffice community members.
My comment to Rob was by way of a reminder that it would be better to stop acting divisively like this. My apologies if this brevity was confusing.
S.
Re: Question related derivative code based on our Apache licensed code
Posted by Joe Schaefer <jo...@yahoo.com>.
Did you have trouble with the part where
he wrote "this mailing list"? In any case
we have 1-way compatibility from AL to LGPL
so there's little technical need for it.
>________________________________
> From: Simon Phipps <si...@webmink.com>
>To: ooo-dev@incubator.apache.org
>Sent: Monday, January 16, 2012 8:03 PM
>Subject: Re: Question related derivative code based on our Apache licensed code
>
>
>On 16 Jan 2012, at 20:51, Rob Weir wrote:
>> As far as I can tell, there is nothing that would prevent an
>> individual developer from submitting a patch to this mailing list or
>> to the LO mailing list and saying it was available AL2 or MPL/LGPL at
>> the receiver's election.
>
>Will you be proposing this to AOO contributors as enthusiastically as you do in relation to LibreOffice contributors?
>
>S.
>
>
>
>
Re: Question related derivative code based on our Apache licensed code
Posted by Simon Phipps <si...@webmink.com>.
On 16 Jan 2012, at 20:51, Rob Weir wrote:
> As far as I can tell, there is nothing that would prevent an
> individual developer from submitting a patch to this mailing list or
> to the LO mailing list and saying it was available AL2 or MPL/LGPL at
> the receiver's election.
Will you be proposing this to AOO contributors as enthusiastically as you do in relation to LibreOffice contributors?
S.
Re: Question related derivative code based on our Apache licensed code
Posted by Rob Weir <ro...@apache.org>.
On Mon, Jan 16, 2012 at 7:31 AM, Michael Meeks <mi...@suse.com> wrote:
> Hi Pedro,
>
> On Wed, 2012-01-04 at 06:38 -0800, Pedro Giffuni wrote:
>> What will happen is that the code will keep the MPL/LGPL3
>> restrictions in addition to the AL2.
>
> That would be the plan; though our code will -emphatically- not be
> available under the AL2; only an MPL/LGPLv3+ [as well as any lingering
> terms from the AL2].
>
In what sense do you mean "our code"? Is that the "royal we" or are
you speaking on behalf of Suse?
As far as I can tell, there is nothing that would prevent an
individual developer from submitting a patch to this mailing list or
to the LO mailing list and saying it was available AL2 or MPL/LGPL at
the receiver's election.
These are the rights that creative people have over their creative
works, that they own the copyright and can assign permissions pretty
much as they wish. Unless, of course, TDF/LO intends to institute
some sort of CLA that would prohibit the author of code to share it as
they wish?
>> - They will have to carry the AL2 license among their code
>> and headers, and the clause 5 is particularly nice to have.
>
> Clause five of the AL2 is:
>
> "5. Submission of Contributions. Unless You explicitly state
> otherwise, any Contribution intentionally submitted for
> inclusion in the Work by You to the Licensor shall be under the
> terms and conditions of this License, without any additional
> terms or conditions. Notwithstanding the above, nothing herein
> shall supersede or modify the terms of any separate license
> agreement you may have executed with Licensor regarding such
> Contributions."
>
> IANAL, but to create a superabundance of clarity - no contribution
> submitted to LibreOffice is a 'Contribution'. It is not submitted to
> 'Licensor' which is ASF (cf. definition of Contribution). The TDF
> infrastructure is not /managed by, or on behalf of, the ASF/.
>
Understood. But (and correct me if I am mistaken) the TDF
infrastructure is not managed by or on behalf of the Free Software
Foundation or the Mozilla Foundation, but still your users opt to send
declarations like the following to your mailing list:
http://lists.freedesktop.org/archives/libreoffice/2011-November/021345.html
So the org that runs your website and the org that wrote the license
are no necessarily connected, and it is rather silly to confuse them.
In any case it would be trivial for a developer to add ("as well as
Apache License v2") to such a statement. If that is not clear to
developers, then maybe I can help make this fact better known.
> If it would help to clarify this, we can add a "Not a contribution"
> line or similar language to our new (MPL/LGPL)onAL2 header as/when we've
> got that worked through.
>
> Of course, individuals are quite at liberty to choose to license their
> contributions to the ASF if they so choose, and to include -their- code
> into either project; though that is something I'd personally
> discourage :-)
>
Well, that's one reason we have pseudonyms.
> So - any expansion on "is particularly nice to have" would be helpful
> Pedro - why do you think this is particularly nice ? :-)
>
> All the best,
>
> Michael.
>
> --
> michael.meeks@suse.com <><, Pseudo Engineer, itinerant idiot
>
Re: Question related derivative code based on our Apache licensed
code
Posted by TJ Frazier <tj...@cfl.rr.com>.
On 1/16/2012 10:28, Pedro Giffuni wrote:
> Hi Michael;
>
> Just to be clear ...
> I am not a lawyer, and even if I were whatever I say in
> respect to licensing doesn't have any legal permission
> or state any rule wrt what should be done.
>
> just to make that clear :).
>
> --- Lun 16/1/12, Michael Meeks<mi...@suse.com> ha scritto:
>
>> Hi Pedro,
>>
>> On Wed, 2012-01-04 at 06:38 -0800, Pedro Giffuni wrote:
>>> What will happen is that the code will keep the
>> MPL/LGPL3
>>> restrictions in addition to the AL2.
>>
>> That would be the plan; though our code
>> will -emphatically- not be
>> available under the AL2; only an MPL/LGPLv3+ [as well as
>> any lingering terms from the AL2].
>>
>
> In the projects I participate we never *ever* replace a
> license, we just add a copyright header with our license
> when relevant. I would expect LO will have to comply
> with AL2, adding the respective restrictions imposed
> by your own licensing scheme (MPL/GPL).
>
>>> - They will have to carry the AL2 license among their
>> code
>>> and headers, and the clause 5 is particularly nice to
>> have.
>>
>> Clause five of the AL2 is:
>>
>> "5. Submission of Contributions. Unless
>> You explicitly state
>> otherwise, any Contribution
>> intentionally submitted for
>> inclusion in the Work by You
>> to the Licensor shall be under the
>> terms and conditions of this
>> License, without any additional
>> terms or conditions.
>> Notwithstanding the above, nothing herein
>> shall supersede or modify the
>> terms of any separate license
>> agreement you may have
>> executed with Licensor regarding such
>> Contributions."
>>
>> IANAL, but to create a superabundance of
>> clarity - no contribution
>> submitted to LibreOffice is a 'Contribution'. It is not
>> submitted to
>> 'Licensor' which is ASF (cf. definition of Contribution).
>> The TDF
>> infrastructure is not /managed by, or on behalf of, the
>> ASF/.
>>
>
> Issue 5 only applies to contributions made to the Apache
> project. Surely the code that has been contributed to LO
> cannot be taken by us unless the author specifically
> authorizes sends it to us too.
>
>> If it would help to clarify this, we can
>> add a "Not a contribution"
>> line or similar language to our new (MPL/LGPL)onAL2 header
>> as/when we've got that worked through.
>>
>
> This type of sillyness, attempting to obfuscate the language,
> is one of the reasons why I keep away from projects with
> unreadable licenses.
>
>> Of course, individuals are quite at
>> liberty to choose to license their
>> contributions to the ASF if they so choose, and to include
>> -their- code
>> into either project; though that is something I'd
>> personally
>> discourage :-)
>>
>> So - any expansion on "is particularly
>> nice to have" would be helpful
>> Pedro - why do you think this is particularly nice ? :-)
>>
>
> It is really nice because in this project we don't request
> silly licensing statements. We assume people are not
> stupid enough to send us code that we can't use. Here
> the term "stupid" has the same connotation as defined in
> Carlo Cipola's classical paper:
> http://cantrip.org/stupidity.html
>
> (BTW, Anyone has a link to the original in italian?)
>
> cheers,
>
> Pedro.
>
>
http://www.amazon.com/Allegro-non-troppo-Contrappunti-Italian/dp/8815019804/ref=pd_sim_sbs_b_1/185-0371021-4419420
A commercial link, but maybe a good starting point.
--
/tj/
Re: Question related derivative code based on our Apache licensed code
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Michael;
Just to be clear ...
I am not a lawyer, and even if I were whatever I say in
respect to licensing doesn't have any legal permission
or state any rule wrt what should be done.
just to make that clear :).
--- Lun 16/1/12, Michael Meeks <mi...@suse.com> ha scritto:
> Hi Pedro,
>
> On Wed, 2012-01-04 at 06:38 -0800, Pedro Giffuni wrote:
> > What will happen is that the code will keep the
> MPL/LGPL3
> > restrictions in addition to the AL2.
>
> That would be the plan; though our code
> will -emphatically- not be
> available under the AL2; only an MPL/LGPLv3+ [as well as
> any lingering terms from the AL2].
>
In the projects I participate we never *ever* replace a
license, we just add a copyright header with our license
when relevant. I would expect LO will have to comply
with AL2, adding the respective restrictions imposed
by your own licensing scheme (MPL/GPL).
> > - They will have to carry the AL2 license among their
> code
> > and headers, and the clause 5 is particularly nice to
> have.
>
> Clause five of the AL2 is:
>
> "5. Submission of Contributions. Unless
> You explicitly state
> otherwise, any Contribution
> intentionally submitted for
> inclusion in the Work by You
> to the Licensor shall be under the
> terms and conditions of this
> License, without any additional
> terms or conditions.
> Notwithstanding the above, nothing herein
> shall supersede or modify the
> terms of any separate license
> agreement you may have
> executed with Licensor regarding such
> Contributions."
>
> IANAL, but to create a superabundance of
> clarity - no contribution
> submitted to LibreOffice is a 'Contribution'. It is not
> submitted to
> 'Licensor' which is ASF (cf. definition of Contribution).
> The TDF
> infrastructure is not /managed by, or on behalf of, the
> ASF/.
>
Issue 5 only applies to contributions made to the Apache
project. Surely the code that has been contributed to LO
cannot be taken by us unless the author specifically
authorizes sends it to us too.
> If it would help to clarify this, we can
> add a "Not a contribution"
> line or similar language to our new (MPL/LGPL)onAL2 header
> as/when we've got that worked through.
>
This type of sillyness, attempting to obfuscate the language,
is one of the reasons why I keep away from projects with
unreadable licenses.
> Of course, individuals are quite at
> liberty to choose to license their
> contributions to the ASF if they so choose, and to include
> -their- code
> into either project; though that is something I'd
> personally
> discourage :-)
>
> So - any expansion on "is particularly
> nice to have" would be helpful
> Pedro - why do you think this is particularly nice ? :-)
>
It is really nice because in this project we don't request
silly licensing statements. We assume people are not
stupid enough to send us code that we can't use. Here
the term "stupid" has the same connotation as defined in
Carlo Cipola's classical paper:
http://cantrip.org/stupidity.html
(BTW, Anyone has a link to the original in italian?)
cheers,
Pedro.
Re: Question related derivative code based on our Apache licensed
code
Posted by Michael Meeks <mi...@suse.com>.
Hi Pedro,
On Wed, 2012-01-04 at 06:38 -0800, Pedro Giffuni wrote:
> What will happen is that the code will keep the MPL/LGPL3
> restrictions in addition to the AL2.
That would be the plan; though our code will -emphatically- not be
available under the AL2; only an MPL/LGPLv3+ [as well as any lingering
terms from the AL2].
> - They will have to carry the AL2 license among their code
> and headers, and the clause 5 is particularly nice to have.
Clause five of the AL2 is:
"5. Submission of Contributions. Unless You explicitly state
otherwise, any Contribution intentionally submitted for
inclusion in the Work by You to the Licensor shall be under the
terms and conditions of this License, without any additional
terms or conditions. Notwithstanding the above, nothing herein
shall supersede or modify the terms of any separate license
agreement you may have executed with Licensor regarding such
Contributions."
IANAL, but to create a superabundance of clarity - no contribution
submitted to LibreOffice is a 'Contribution'. It is not submitted to
'Licensor' which is ASF (cf. definition of Contribution). The TDF
infrastructure is not /managed by, or on behalf of, the ASF/.
If it would help to clarify this, we can add a "Not a contribution"
line or similar language to our new (MPL/LGPL)onAL2 header as/when we've
got that worked through.
Of course, individuals are quite at liberty to choose to license their
contributions to the ASF if they so choose, and to include -their- code
into either project; though that is something I'd personally
discourage :-)
So - any expansion on "is particularly nice to have" would be helpful
Pedro - why do you think this is particularly nice ? :-)
All the best,
Michael.
--
michael.meeks@suse.com <><, Pseudo Engineer, itinerant idiot
Re: Question related derivative code based on our Apache licensed code
Posted by Pedro Giffuni <pf...@apache.org>.
--- Mer 4/1/12, Jürgen Schmidt ha scritto:
...
> >
> are you sure? For me this special situation seems to be a
> little bit different. Either you go forward with the old
> code and the old license header and can't merge to the new
> code. Or you move forward with the new one and keep the new
> license headers and put your change on a different
> license. Where you would make the difference which code is
> from which code base. For me it sounds practical impossible
> because the many thousand files with more or less the same
> code.
>
The problem is that TDF, or whomever adopts the Apache OO
headers, doesn't own the modified (MPL/LGPL3) code so even
if they wanted they can not make it AL2. What will happen
is that the code will keep the MPL/LGPL3 restrictions in
addition to the AL2.
Nevertheless there will be two consequences:
- They can have all their code uniformly under LGPL3/MPL2
dual license. The LGPL being so commercially unfriendly,
this practically means they will be MPL2, with the LGPL3
being purely nominal.
- They will have to carry the AL2 license among their code
and headers, and the clause 5 is particularly nice to have.
If you add these two points, and this is all IMHO, the
great loser in all this is the FSF that lost the strong
copyleft over the flag opensource Office suite.
>
> It is really a special situation, isn't it. It would be
> interesting to
> hear what a lawyer things about it.
>
Oh .. I am not a lawyer, so it was all meant IMHO :).
cheers,
Pedro.
Re: Question related derivative code based on our Apache licensed
code
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 1/4/12 1:08 PM, Simon Phipps wrote:
> My personal opinions on this, naturally:
>
> On 4 Jan 2012, at 11:35, Jürgen Schmidt wrote:
>
>> In detail if a derivative project merge our now Apache licensed code with their code that was based on the former Oracle licensed LGPL code. This code becomes automatically Apache licensed, correct?
>
> Probably not, no. The existing LGPLv3 licensed code remains LGPLv3 licensed, and as a requirement of the LGPLv3 the new code added to it has to be made available under the LGPLv3 as well. As a consequence, the resulting modified work will be licensed under LGPLv3. The Apache code that was added remains under the Apache license too (which is OK since there is no conflict between the terms of the AL and LGPLv3).
>
are you sure? For me this special situation seems to be a little bit
different. Either you go forward with the old code and the old license
header and can't merge to the new code. Or you move forward with the new
one and keep the new license headers and put your change on a different
license. Where you would make the difference which code is from which
code base. For me it sounds practical impossible because the many
thousand files with more or less the same code.
It is really a special situation, isn't it. It would be interesting to
hear what a lawyer things about it.
Juergen
>> If yes, does it mean that we can use the changes on this code in our code as well if it is publicly available?
>
> No.
>
>
> S.
Re: Question related derivative code based on our Apache licensed code
Posted by Simon Phipps <si...@webmink.com>.
My personal opinions on this, naturally:
On 4 Jan 2012, at 11:35, Jürgen Schmidt wrote:
> In detail if a derivative project merge our now Apache licensed code with their code that was based on the former Oracle licensed LGPL code. This code becomes automatically Apache licensed, correct?
Probably not, no. The existing LGPLv3 licensed code remains LGPLv3 licensed, and as a requirement of the LGPLv3 the new code added to it has to be made available under the LGPLv3 as well. As a consequence, the resulting modified work will be licensed under LGPLv3. The Apache code that was added remains under the Apache license too (which is OK since there is no conflict between the terms of the AL and LGPLv3).
> If yes, does it mean that we can use the changes on this code in our code as well if it is publicly available?
No.
S.
Re: Question related derivative code based on our Apache licensed code
Posted by Rob Weir <ro...@apache.org>.
2012/1/4 Jürgen Schmidt <jo...@googlemail.com>:
> Hi,
>
> over the last days i was asking myself how it is exactly with code that is
> based on our Apache licensed code.
>
> Well i have read the Apache license but the practical relevance is not clear
> for me.
>
> In detail if a derivative project merge our now Apache licensed code with
> their code that was based on the former Oracle licensed LGPL code. This code
> becomes automatically Apache licensed, correct?
If author "A" writes code and releases it under LGPL, there is nothing
that prevents them from also releasing the same code as ALv2, at the
same time and place or someplace else. We see this with Oracle and
the OOo SGA, for example. The owner of the code can attach licenses
as they wish. The right to license (give permission) is one of the
exclusive rights that a copyright owner has.
If author "B" then takes this base work and makes changes, then "B"
owns the changes they make. What license exactly those patches are
available under depends on several things, including the license of
the base work, whether the changes are published or kept private,
whether "B" has signed a CLA that obligates them to make contributions
under a certain license, etc.
The Oracle SGA has made OOo source files available under ALv2 in
general, not only for this project, but for anyone, including others
who based their product on the same files. We've certainly been
working under this model, as other OOo derivatives and ports have
merged in their patches that were originally based on OOo LPGL
releases. The eventual Symphony contribution is also enabled by the
SGA.
So person "B", if they wanted, is not required to make their patches
available under LPGL. As of the SGA date they could make their
patches available under other licenses, including ALv2. But they are
not obligated to do this. They could also chose to remain with LGPL.
The switch to ALv2 does not obligate moving to a less restrictive
license for derivatives. It only permits it.
(This assumes that "B" is making changes only to "A" code. It gets
more complicated if person "C" made changes to "A" under LGPL as well)
> If yes, does it mean that we can use the changes on this code in our code as
> well if it is publicly available?
>
It depends on the license granted by the author of the changes.
> Ok the license say that it is possible to put an additional license on all
> changes made on the code when you mark all changes in an appropriate way.
> How is that possible or done in practize with many minor changes (e.g.
> improve the performance of an existing loop, or initialize existing
> variables etc.)? And which license is valid if a trivial change is made in
> our (the original) source in the same way, e.g. initialize a local variable
> to prevent a warning?
>
First, trivial changes might not be copyrightable at all. If there is
a bug and fixing the bug requires that you change:
ptr = malloc(len)
to
ptr = malloc(len+1)
Then you could argue that this change does not amount to creative
expression. The copyright protects the creative expression, not the
labor involved in debugging. But in general I'd recommend that we
avoid making calls like this.
In any case, one can express a license intent in many ways. For
example, with the iCLA, you make a blanket statement that all
contributions you make to SVN are under ALv2. You don't mark them
individually. You only put the license header in new files. But all
contributions, even one line ones, are covered.
You see, in a less formal way, assertions made like this in other
projects. For example, on the LO Dev list you see statements like
this:
http://lists.freedesktop.org/archives/libreoffice/2011-November/021345.html
There is nothing in theory that would prevent someone from making such
a statement that also included ALv2 among the licenses granted by an
author.
> Anyway it seems that the new changed code becomes derivative work because
> the Apache license can't be removed.
>
Apache license is not viral. So although the license on the base code
remains Apache license, it does not require that the modifications
(the patch) is also ALv2. It can be, but this depends on the patch
author's wishes.
> I hope my question or thoughts are not too stupid and that somebody know the
> answer ;-)
>
>
> Juergen
>
>
> PS. we talk about thousands of files, many changes and a lot of stupid
> necessary work (marking all changes appropriately)
Re: Question related derivative code based on our Apache licensed code
Posted by Ross Gardler <rg...@opendirective.com>.
2012/1/4 Jürgen Schmidt <jo...@googlemail.com>:
> In detail if a derivative project merge our now Apache licensed > code with
> their code that was based on the former Oracle licensed LGPL code. This code
> becomes automatically Apache licensed, correct?
[Of course IANAL so be careful with my responses, I believe them to be
correct, legal-discuss@ will provide clarification if anyone contests
my opinion. Also discussing legal issues like this is difficult
without specific cases to examine. If you do need further
clarification it is better to have concrete examples - legal-discuss@
refuse to discuss hypotheticals and inside on actual cases.]
No. The Apache License has no "viral" element to it and the LGPL has
no provision for relicensing. Each part of the code remains under the
original licence.
> If yes, does it mean that we can use the changes on this code
> in our code as
> well if it is publicly available?
The answer to the first question is no, but this question is still
relevant. Modifications to the LGPL code, if distributed along with
that code must be LGPL. However, as copyright owner the person making
the modifications could make their modifications available on whatever
license they want as long as it is distributed separately from the
original LGPL code.
In other words, if someone task class Foo under Oracles LGPL and
modifies it they can choose to provide the patch against the AOO class
Foo under an Apache license.
>
> Ok the license say that it is possible to put an additional license > on all
> changes made on the code when you mark all changes in an
> appropriate way.
> How is that possible or done in practize with many minor
> changes (e.g.
> improve the performance of an existing loop, or initialize
> existing
> variables etc.)?
Will difficulty. One practice I have seen is to indicate "portions (c)
Foo Bar" and then maintain a patch file against the original code to
identify those portions.
> And which license is valid if a trivial change is
> made in
> our (the original) source in the same way, e.g. initialize a local
> variable
> to prevent a warning?
If the change is made against LGPL and distributed then it is LGPL,
there is no choice. If the change is against the Apache licence then
the copyright holder gets to choose. But see my note above that even
under LGPL the copyright holder can donate a patch to the ASF under an
Apache License if they choose.
It is only if the code is distributed alongside the original LGPL code
that the "viral" nature of the LGPL becomes important.
Ross