www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: InfoWorld article on LibreOffice and OpenOffice
Date Wed, 12 Aug 2015 09:12:24 GMT
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


Mime
View raw message