Re: [tdf-discuss] Copyright Assignments & the Document Foundation

----- Original Message ----

> From: Charles-H. Schulz <charles.schulz@documentfoundation.org>
> Le Thu, 28 Oct 2010 07:12:59 -0700 (PDT),
> BRM <bm_witness@yahoo.com> a écrit  :
> > > From: Charles-H.  Schulz <charles.schulz@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+help@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 ***