----- Original Message ---- > From: Charles-H. Schulz <charles.sch...@documentfoundation.org> > Le Thu, 28 Oct 2010 07:12:59 -0700 (PDT), > BRM <bm_witn...@yahoo.com> a écrit : > > > From: Charles-H. Schulz <charles.sch...@documentfoundation.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 > > > Oracle. > > > > 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. >
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. Ben [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 discuss+h...@documentfoundation.org Posting guidelines: http://netmeister.org/news/learn2quote.html Archive: http://www.documentfoundation.org/lists/discuss/ *** All posts to this list are publicly archived ***
