Date: prev next · Thread: first prev next last
2010 Archives by date, by thread · List index

----- Original Message ----

From: Charles-H. Schulz <>
Le Thu, 28 Oct 2010 07:12:59 -0700 (PDT),
BRM <> a écrit  :
From: Charles-H.  Schulz <>
 > 4) the notion that we cannot change license  because we don't  have
copyright assignment needs to be put to rest once and   for all
today. There is a very simple explanation with respect to  this
issue;  ask any lawyer and he/she will confirm this:  Sun/Oracle has
licensed the  OOo code under LGPL v3. They  could have put "LGPL v3
or later" or "LGPL  v3 or +". But they  didn't. And that's what
makes impossible to turn  OOo into a  different license unless the
sole copyright owner agrees  to  change it, which is unlikely with

While I  like that TDF is not requiring copyright assignment, there is
one point  missing here that is in its favor.

True, Sun/Oracle has  currently licensed OOo under LGPLv3.
But what's to stop them from going  to LGPLv4 when it is available?
Absolutely nothing. At which point TDF  may not be able to accept
changes from OOo any longer assuming it is  still possible at that time
without updating the LO license to be the  same or inclusive therein.

Perhaps the way around that is to  require those contributing TDF to
use the "or later" language; though  some may not want to.

Even without copyright assignment the  only thing standing in the way
of changing the license - whether to  LGPLv4 or even GPLv3 or whatever
else - is getting the permission of  _all_ the copyright holders.

Good objection indeed! Actually, the problem  is partly solved, since we
now license our software under "LGPL v3 or later".  At least it would be
solved for the LGPL side of things. But my real answer  here though, is
perhaps more provocative: if Oracle changes the licence, do  we really
care? for the 3.3 we stick to the codebase of OOo, but I'm unsure  we'll
stick that much  to it in further releases. In fact, I can  already
point out, looking at our development activity, that we're not  taking
the path of being ", just recompiled by the  community". I
think as the time will go by, we will diverge more and more and  end up
becoming quite different software. 

For the most part, probably not. Though all code coming from OOo is LGPLv3 only, 
you might for whatever code is shared if LO was to relicense its code under 
LGPLv4 or later at some point, if only to gain the advantages of the new version 
of the license from the FSF.

And I in no way intended to make it sound as if LO is just a community recompile 
of OOo; rather, it is the community extension of OOo. Kind of similar to how 
Andrew Morton and Linus Torvalds both had their own development trees and 
releases of the Linux Kernel. Linus' is the official kernel, but it equally 
competed with the mm branch maintained by Andrew Morton. The mm branch typically 
had everything in Linus' branch plus some other stuff - extra patches, etc. - 
that Linus is not ready or willing to accept yet.[1] LO, at least at this 
juncture, is very similar with OOo - it's inherited a huge code base that has to 
be maintained, and is adding its own stuff. It is wise to incorporate the 
changes from OOo for any overlap there is if not only so there is a lower level 
of support required for LO until those parts get written out, etc. The bigger 
difference here is that LO has to worry about user interface stuff - where 
Andrew Morton does not. Only time will truly tell how the two products (LO and 
OOo) diverge; but we shouldn't shut the door or exclude the possibility of 
continued merges from OOo.

As a developer I certainly do like the no copyright assignment; as an 
organization looking to be able to enforce and update the license as necessary 
to maintain the product I would prefer the copyright assignment. As I said 
earlier, both have their pros and cons.

I wonder if anyone has ever investigated a middle-ground - a contract between 
the organization and the developer such that the developer allows the 
organization to update the license so long as the license meets certain 
conditions - so the organization can be pro-active concerning license changes, 
yet doing so without assigning copyright. While IANAL it seems there might be a 
way to meet both needs.

Again, just $0.02.


[1] mm tree was closed down several years back. So it's no longer current, but 
there are still numerous other layers in the Linux development model that do 
just this still.

Unsubscribe instructions: Email to
Posting guidelines:
*** All posts to this list are publicly archived ***


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.