Le Thu, 28 Oct 2010 07:12:59 -0700 (PDT),
BRM <email@example.com> a écrit :
----- Original Message ----
From: Charles-H. Schulz <firstname.lastname@example.org>
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 "OpenOffice.org, 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.
From what I understand this is already impossible to do under Linux
deaths of at least one contributor.
Yes, and in this case a rewrite is needed.
The main reason projects move towards having copyright assignment is
to be able to keep the licensing language up to date - to use the
latest GPL/LGPL license due to exactly the issue of how hard it is to
track down every contributor and get their permission in should they
want to change the license. At present the bulk of the code is held
by Oracle and such can be most easily changed by garnishing
permission from one entity; though that will not be true for long for
TDF without copyright assignment - in which case there would be two -
TDF and Oracle.
The Linux Kernel guys don't require it; KDE E.v. does. Both methods
have their pros and cons.
Ultimately, as long as TDF and the community are aware and accept
what may occur should Oracle radically change the license it doesn't
Just pointing out it's a little more complex than Oracle is not
likely to change the license since they very well could. Fortunately
they cannot do it retroactively, at least with the LGPL.
P.S. IANAL and such disclaimers. This is just from what I have
learned from years of watching the community and the licensing topics.
Membre du Comité exécutif
The Document Foundation.
Unsubscribe instructions: Email to email@example.com
Posting guidelines: http://netmeister.org/news/learn2quote.html
*** All posts to this list are publicly archived ***
Impressum (Legal Info)
: 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