www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: InfoWorld article on LibreOffice and OpenOffice
Date Wed, 12 Aug 2015 16:17:10 GMT
We have wandered considerably from the original point of this thread which was to suggest that
some expressed level of flexibility available in LibreOffice development was not available
in the case of Apache OpenOffice.  

THE LEVER USED IN THIS THREAD

The speculation that flexibility to use third-party code was a material difference in the
context of the City of Munich giving preference to LibreOffice was used to suggest that perhaps
Apache OpenOffice could have earned that preference (or at least substitutability) was then
hinted at something that would have Apache OpenOffice prefer that ASF license and third-party
content policies be different.  There is no evidence for that, of course, and do-overs are
not possible.  I will not reiterate any of my rationale around that.  

This gives rise to a larger concern of mine (and perhaps a number of civil authorities as
well) about the vaunted substitutability of products that support document-formats defined
by open standards, especially where issues of interoperability and usability and the cost
of supporting end-users in their efforts rise to the forefront.  

That is a far more serious factor, in my considered opinion, and I will not pursue it on this
thread.  It is an issue that Apache OpenOffice does not escape and that is worrisome for me.
 It has nothing to do with open-source licenses.

WHAT THE FLEXIBILITY APPEARS TO BE

Looking at the FAQ provided about the move of LibreOffice to MPL, I surmise that the claimed
flexibility is primarily about what third-party code LibreOffice easily depends on *in its
binaries* and not so much on the ability to comingle in ALv2-licensed derivative source code.
 

It is not for me to assess how much the advantageous dependency of such code from an MPL-licensed
source code is achieved in those binary distributions.  I have already shown that the way
notices and license claims are handled in those distributions is a bit sketchy.  My last lengthy
post on this thread provides a detailed analysis.  

THE REBASING FIASCO

Let's now back off and be clear-eyed about how LibreOffice came to be "rebased" on Apache
OpenOffice ALv2 code that is then wrapped as an MPL 2.0 derivative, with binaries so licensed.
 I agree the behavior is a bit sketchy, though not atypical of non-ASF FOSS projects.  ASF
projects also have to be vigilant around license statements and NOTICE files in project-provided
binary distributions, distinct from the counterparts in source releases.  

The key factor that needs to be understood is that some, perhaps many, LibreOffice developers
felt that the OpenOffice.org code base was theirs *by right* and that the grant of license
from Oracle to the Apache Software Foundation was an insult and improper.  

Much of the posturing that we see around the move to MPL2 has that in its context.  That belief
colors the attitudes expressed in the evolving FAQ about the move to MPL2 at <https://wiki.documentfoundation.org/Development/Re-Basing>.
 See the "Will this mean LibreOffice is powered by Apache?" and "Surely you're not going with
the Apache license?" statements.  (By the way, dual-licensing downstream has not occurred
and I suspect it cannot.)

I think this "whose is OpenOffice" article of faith is reflected in how the files are handled
and in claims that only 6% of the AOO code base differs from what was the work of others with
regard to the forked OpenOffice.org base.  

FINAL OBSERVATION

That this does not square with what many of us see as good OSS citizenship is another matter.
 All that is in our power to influence directly is our own projects and how we serve the public
interest in the manner in which software is provided by our projects, not someone elses.

I also believe that people of good will can arrive at accommodations where there is an over-riding
mutual interest.  I note that the handling of security vulnerabilities and their resolution
is in fact handled well between the two projects with great respect and cooperation.  It is
probably helpful, in this case, that security work is performed in private and that the participants
understand that it is the safety of all our users that matters, not other combative instincts.

 - Dennis

BACK STORY
 
When LibreOffice was forked from OpenOffice.org, the code base they acquired was under LGPL2
and copyright was held by Sun Microsystems (and then Oracle Corporation).  There were, of
course, components under other licenses and Sun was careful to provide a Third Party License
file and handle those components appropriately.  Significant contributors who were not Sun
employees had filed (apparently non-exclusive) copyright transfers, in contrast with the ICLA
and CCLA terms employed by the ASF.

Early in the development of LibreOffice, there was a campaign to obtain new license declarations
from the active developers.  This was accomplished.  What was obtained were agreements that
past, present, and future contributions to LibreOffice by those specific developers and all
new ones were dual licensed under the MPL and LGPL.

This did not apply to all developers of OpenOffice.org, and certainly not those whose employment
contract or circumstances as providers of work for hire, but that is what was done with those
developers.  This certainly applied to new contributions by those developers with the contributions
they made after the fork of the OpenOffice.org code base into a LibreOffice derivative work.

I suspect it became clear that, although some set of contributions were now dual-licensed,
that did not make it possible to move the LibreOffice code base and binaries, still offered
under LGPL2, to MPL.  The [L]GPL simply don't allow it.  (We can talk about the irony of FREE
as in freedom and Shane's talk at OSCON 2015 another time.)

I do not know how the motivation to use MPL arose.  I don't think it had much to do with the
existence of Apache OpenOffice.  However, Apache OpenOffice became an avenue to its achievement.

The rebasing effort involved acquiring and checking in ALv2-licensed code that was essentially
the same as the underlying OpenOffice.org code of LibreOffice.  Any modifications (under those
dual MPL+LGPL grants of license) were reapplied.  The rewriting of headers reflects that,
although it appears to have been done wholesale.  Continuing contributions are also under
those dual cases.

This practice also continued, although now less and less, with regard to post-Oracle contributions
to the Apache OpenOffice code by Apache Project (and incubator) contributors.  This extended
to the grant of some IBM Lotus Symphony code (that was never LGPL) to Apache OpenOffice that
provided important accessibility and popular UI features, now employed in LibreOffice to varying
degree.

That this is a one-way arrangement is difficult.  It offends some although it is part of the
ASF DNA and treatment of its public-interest obligations that there are no barriers to such
behavior, so long as the ALv2 and ASF trademarks are honored appropriately.


-----Original Message-----
From: Mark Struberg [mailto:struberg@yahoo.de] 
Sent: Wednesday, August 12, 2015 02:12
To: legal-discuss@apache.org
Subject: Re: InfoWorld article on LibreOffice and OpenOffice

I am personally not happy with the way LO treated this (exactly beause of the practical reasons
you pointed out).

And also because they added the (c) LibreOffice and Licensed under MPL to ALL files even if
they did not change a single code line from the ALv2 version - they initially only did reformatting
to all the code without changing the content and logic. And thus those files are imo still
100% ALv2 with NO effective parts of MPL actually! [1][2][3]


Let’s do a mind-game: if you follow their way and extend it even more then this might end
up with 

/*
 * this file contains content licensed under MPL, ALv2, BeerLicense, BSD, MIT.
 */

And eventually one day

/*
 * this file contains content licensed under MPL, ALv2, BeerLicense, BSD, MIT, LGPL 
 * and we actually don’t know ourselves what else.
 */

Of course I’m not expecting they will add LGPL or even GPL parts, but you get the idea.
If you follow this route then they will simply not been able to say what license which line
belongs to and it will deminish the usage. So they need to be very careful.

LieGrue,
strub

[1] of course they did lots of work in the last 2 years and this new work is ALv2/MPL mixed,
or only MPL? How can a contributor know?
[2] Please help me understand this: this is not a dual-licensed code but a ‚mixed‘ code.
How does this work in practice when it comes to contributions?
[3] The way I know how to handle such situations is to comment code blocks which are taken
from a differently licensed base. But LO didn’t do that.


> Am 11.08.2015 um 19:18 schrieb Richard Eckart de Castilho <rec@apache.org>:
> 
> On 11.08.2015, at 19:01, Marvin Humphrey <marvin@rectangular.com> wrote:
> 
>> On Tue, Aug 11, 2015 at 9:10 AM, Richard Eckart de Castilho
>> <rec@apache.org> wrote:
>> 
>>> If we allowed to integrate patches under MPL, we could just as well put the
>>> whole project accepting these patches under MPL -because managing multiple
>>> licenses within a single source file is not practicable and having a large
>>> number of foreign-licensed files makes refactoring impracticable.
>> 
>> Right, so how have LO managed the integration of Apache-licensed content when
>> the result would be multiply-licensed source files?
> 
> Ok, let's see an example:
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=bdb3f642973b7c7b9ce8bdae1344e4ab520f942a
> 
> The committer here seems to have pulled in a commit from the AOO repository. 
> 
> Looking at one of the files affected by the change, we can see this license header
> 
> /*
> * This file is part of the LibreOffice project.
> *
> * This Source Code Form is subject to the terms of the Mozilla Public
> * License, v. 2.0. If a copy of the MPL was not distributed with this
> * file, You can obtain one at http://mozilla.org/MPL/2.0/.
> *
> * This file incorporates work covered by the following license notice:
> *
> *   Licensed to the Apache Software Foundation (ASF) under one or more
> *   contributor license agreements. See the NOTICE file distributed
> *   with this work for additional information regarding copyright
> *   ownership. The ASF licenses this file to you under the Apache
> *   License, Version 2.0 (the "License"); you may not use this file
> *   except in compliance with the License. You may obtain a copy of
> *   the License at http://www.apache.org/licenses/LICENSE-2.0 .
> */
> 
> That's ok. But now what happens if somebody chose to refactor code from that file into
another file that does not have such a header? It will be hard to impossible to track down
which lines are under which license. 
> 
> The easiest solution would be for LO to simply add that header to *all* of their files
(I'm not sure if they did that) to avoid the headache of tracking such a thing - or at least
be very generous with adding such multi-license headers. But for them that's not a problem
because the dominating license here is the MPL with its copyleft, right? 
> 
> I don't think there is much incentive at LO in trying to isolate ASL-licensed changes
back out. It doesn't affect their ability for refactoring so much if they are generous with
these multi-license headers. 
> 
> On the contrary, the ASF policy cares about isolating such foreign licenses as much as
possible. One effect is that the ability to refactor "pure" ASL code is maximized.
> 
> And at that point we come back to what I stated before: If we allowed to integrate patches
under MPL (or any copyleft license), we could just as well go ahead put the whole project
accepting these patches under MPL.
> 
> Cheers,
> 
> -- Richard
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message