Rob makes some important points.  Here's my analysis based on that:

 1. Oracle did not put anything under the ALv2 with its Software Grant 
Agreement.  It granted the ASF a nonexclusive license (and to none others that 
we are aware of), to use the identified code in a particular way, including 
licensing to others (or not).  [The Lotus Symphony software grant from IBM is 
on the same basis.]

 2. The licensed code that the ASF (via the Apache OpenOffice podling) makes 
available under the ALv2 consists of those digital artifacts that bear the ALv2 
license notice in the Apache OpenOffice SVN repository, in the source-code 
release tar-balls, and elsewhere.  This is allowed under the license conditions 
of the applicable SGA.

 3. It is that ALv2-licensed, and only that ALv2-licensed code that downstream 
users can create derivatives of under the provisions of the ALv2 and with any 
appropriately-added licensing for their contribution to the derivative and/or 
its combining, such as the MPL.  (There is no relicensing in this scenario.  
That is a misnomer.  It would be good to stop using the term because it 
suggests liberties that are not necessarily provided for under an open-source 
license such as the ALv2.)

 4. While the ALv2 code will assist the TDF in rebasing LibreOffice into 
MPL-licensed code, source code under the MPL (or MPL dual with LGPL) license 
cannot be brought upstream for use in Apache OpenOffice.  That's an ASF 
constraint on license-compatibility of third-party code derived/combined into 
source code distributed by Apache projects.

 5. It seems to me that making as much available under the Alv2 that can be 
preserved from the CWS collection is a good thing to do insofar that it makes 
sense for the Apache OpenOffice project to bring that material into AOO custody 
and maintenance and with ALv2 licensing.  It makes the result of that work 
widely available and usable in ALv2-based undertakings.  There's a public 
benefit.  

 6. Nevertheless, downstream rebasing under MPL is of no direct benefit, 
cooperatively or otherwise, to the Apache OpenOffice project.  There's no 
problem with that happening -- forking is a feature.  But all of the benefits 
of that are downstream, just as they are if LibreOffice remains LGPL in total.  
And cooperative efforts are just as possible (and no more so) either way.  And 
it is part of the ASF operation in the public interest that there is no problem 
with this, I say.

 - Dennis

-----Original Message-----
From: Rob Weir [mailto:robw...@apache.org] 
Sent: Wednesday, May 23, 2012 19:31
To: ooo-dev@incubator.apache.org
Subject: Re: LibreOffice relicensing efforts

On Wed, May 23, 2012 at 9:43 AM, Shane Curcuru <a...@shanecurcuru.org> wrote:
> In case folks haven't seen this:
>
>  http://legal-discuss.markmail.org/thread/mleqsm636zf5fqia
>
> Which points to:
>
>  http://wiki.documentfoundation.org/Development/Relicensing
>
> So it looks like there will be plenty of code sharing! 8->
>

It seems to be based on an interesting theory about what an SGA
actually does.  It seems to assume that the SGA itself puts the code
under the Apache License.  But does it?   Take a look at the actually
text:  http://www.apache.org/licenses/cla-corporate.txt  I don't see
anything where it states that the grantor gives the files to the ASF
under ALv2.  But it does give the ASF a broader bucket of permissions,
including the right to sublicense.

My impression I think the ALv2 is attached during the IP review
process in the Podling, as we review the code, as Oracle (via Andrew)
changed the LGPL headers to Apache headers, and ultimately when the
IPMC voted to approve the AOO 3.4 release.

Ultimately, basing a LO license rebasing on a pre-IP review,
pre-release version of AOO is not recommended.  We all know what types
of issues we ran into and had to clean up.  The released code is in
much better, in terms of straightening out the licenses.

> - Shane

Reply via email to