Re: [Libreoffice] PostgreSQL-SDBC in LO: licensing

2011-11-21 Thread Lionel Elie Mamane 
On Thu, Nov 17, 2011 at 12:59:58PM +, Michael Meeks wrote:
 On Thu, 2011-11-17 at 12:05 +0100, Lionel Elie Mamane wrote:

 Sure I can: the code being *dual*-licensed means anybody legitly
 getting a copy of the code can *choose* between obeying the LGPLv2.1
 *OR* obeying the SISSL. I chose LGPLv2.1.

   Seems reasonable on the face of it to me - the header change
 is fine.  Of course, we have no option of a plus license there which
 is sad, but hopefully over time, bit by bit we can incrementally
 re-write it as a clean MPL/LGPLv3+ thingit.

OK, then. To implement that hopefully over time, bit by bit we can
incrementally re-write it as a clean MPL/LGPLv3+ thingit, we need to
clearly establish that all future contributions to these files are
LGPLv2.1+ / MPL1.1. So I'm changing the headers *again* to say (with parts
in parentheses actually expanded out, and X replaced by the right year):

/*
 *
 *  Effective License of whole file:
 *
 *(LGPLv2.1 blurb)
 *
 *  Parts Copyright by Sun Microsystems, Inc prior to August 2011:
 *
 *The Contents of this file are made available subject to the terms of
 *the GNU Lesser General Public License Version 2.1
 *
 *Copyright: 200X by Sun Microsystems, Inc.
 *
 *Contributor(s): Joerg Budischewski
 *
 *  All parts contributed on or after August 2011:
 *
 *(
 * LO's TEMPLATE.SOURCECODE.HEADER with:
 * sed /LGPLv3/LGPLv2.1/
 * Major Contributor(s): [ Copyright (C) 2011 Lionel Elie Mamane 
lio...@mamane.lu ]
 *)
 *
 /

-- 
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] PostgreSQL-SDBC in LO: licensing

2011-11-21 Thread Michael Meeks 
Hi Lionel,

On Mon, 2011-11-21 at 10:49 +0100, Lionel Elie Mamane wrote:
 OK, then. To implement that hopefully over time, bit by bit we can
 incrementally re-write it as a clean MPL/LGPLv3+ thingit, we need to
 clearly establish that all future contributions to these files are
 LGPLv2.1+ / MPL1.1. So I'm changing the headers *again* to say (with parts
 in parentheses actually expanded out, and X replaced by the right year):

Looks reasonable - but I don't think we need that in the header, we
have it in the git logs for all the commits so we can unwind it later.
But ...

Thanks for that :-)

Michael.

-- 
michael.me...@suse.com  , Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] PostgreSQL-SDBC in LO: licensing

2011-11-17 Thread Lionel Elie Mamane 
On Thu, Nov 17, 2011 at 03:22:33AM -0600, Norbert Thiebaud wrote:
 On Wed, Nov 16, 2011 at 4:22 PM, Lionel Elie Mamane lio...@mamane.lu wrote:

 postgresql-sdbc

 few questions/remarks (mostly on the form, rather than on substance...
 I only glanced at the commits)

 5a2b8cba519bb9d34d3a28a51adcda334147096f:
 Humm, not sure you can do that,

Sure I can: the code being *dual*-licensed means anybody legitly
getting a copy of the code can *choose* between obeying the LGPLv2.1
*OR* obeying the SISSL. I chose LGPLv2.1.

 but even if you could, removing SISSL is not a good idea since that
 is what allow that code to be merged in libreoffice (which is
 MPL/LGPLv3+)

I understand you are saying that the SISSL allows us to relicense the
code under MPL/LGPLv3+; I'm not sure I agree. Could you please explain
why you think that is?

In particular, by (re)distributing the SISSL-covered code under
MPL/LGPLv3+, we allow downstream users to not obey the standards
body clause of the SISSL. And we are not allowed to allow others to
not obey that clause of the SISSL.


My intention/understanding is that mixing LO and postgresql-sdbc is
allowed because:

 - LGPLv2.1 (covering postgresql-sdbc) allows to link nearly any code
   against postgresql-sdbc.

 - LGPLv3 (covering LO) allows to link nearly any code with it.
   As to LO code that gets #include'd in postgresql-sdbc, it is
   allowed under section 3 of the LGPLv3; we just have to state that
   postgresql-sdbc is included with LO, and distribute a copy of the
   LGPLv3 and of the GPL with LO.

People wanting to fork LO under the MPL and not under the LGPLv3(+)
may or may not have to forsake including postgresql-sdbc, I'm not
sure. A cursory glance at the MPL suggests it would be allowed.

 nitpick: f1127d15dfa2cf03cb4a0c79bc2ddf332b8d6093 and later:

 @@ -1,42 +1,42 @@
 -/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- 
 */
 +/* -*- Mode: C++; eval:(c-set-style bsd); tab-width: 4;
 indent-tabs-mode: nil; c-basic-offset: 4 -*- */

 please don't do that. I have a style set to what works for me, it is
 no nice to try to force another on me.

 that tagline line was meant to force only the 'mandatory part' : no
 tabs and indent of 4.

Do you mean that you intend to write code in another style within the
same file? To me it seems bad practise to mix *different* styles
within the same file.

If not, well, the default emacs style (modified by tab-width=4,
indent-tabs-mode:nil and c-basic-offset: 4) does *not* match the style
of the existing code in that file, so it makes it harder than it has
to be to make modifications in that file: indentation is not a simple
matter of pressing the tab key, one has to do it manually for *every*
{} block. Why would we want to inconvenience contributors so?

The default emacs style would lead to:

if ( blah )
{
code;
}


I picked bsd because it matches the style that was already there, not
out of any personal taste.

-- 
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] PostgreSQL-SDBC in LO: licensing

2011-11-17 Thread Norbert Thiebaud 
On Thu, Nov 17, 2011 at 5:05 AM, Lionel Elie Mamane lio...@mamane.lu wrote:
 On Thu, Nov 17, 2011 at 03:22:33AM -0600, Norbert Thiebaud wrote:
 On Wed, Nov 16, 2011 at 4:22 PM, Lionel Elie Mamane lio...@mamane.lu wrote:

 postgresql-sdbc

 few questions/remarks (mostly on the form, rather than on substance...
 I only glanced at the commits)

 5a2b8cba519bb9d34d3a28a51adcda334147096f:
 Humm, not sure you can do that,

 Sure I can: the code being *dual*-licensed means anybody legitly
 getting a copy of the code can *choose* between obeying the LGPLv2.1
 *OR* obeying the SISSL. I chose LGPLv2.1.

And that is a problem, because that is not compatible with the project license.


 but even if you could, removing SISSL is not a good idea since that
 is what allow that code to be merged in libreoffice (which is
 MPL/LGPLv3+)

 I understand you are saying that the SISSL allows us to relicense the
 code under MPL/LGPLv3+; I'm not sure I agree. Could you please explain
 why you think that is?

 In particular, by (re)distributing the SISSL-covered code under
 MPL/LGPLv3+, we allow downstream users to not obey the standards
 body clause of the SISSL. And we are not allowed to allow others to
 not obey that clause of the SISSL.

The least of 2 'evils': we are LGPLv3+ + MPL that can't work at all with LGPLv2
OTOH SISSL explicitly permit integration under a bigger work with the
license of the bigger work, provided that SSIL is respected for the
piece
inserted. The 'obey standard' clause is weird, but irrelevant here
because the only thing it does is force copyleft, which we already
are.




 Do you mean that you intend to write code in another style within the
 same file? To me it seems bad practise to mix *different* styles
 within the same file.

 If not, well, the default emacs style (modified by tab-width=4,
 indent-tabs-mode:nil and c-basic-offset: 4) does *not* match the style
 of the existing code in that file, so it makes it harder than it has
 to be to make modifications in that file: indentation is not a simple
 matter of pressing the tab key, one has to do it manually for *every*
 {} block. Why would we want to inconvenience contributors so?

 The default emacs style would lead to:

The 'factory' default yes, but the 'the default'. my .emacs is set the
way I like it, and it behave the way I am accustomed to (I used a
customized ellemtel for instance)

The 'use the local style' recommendation is my responsibility to
enforce, selectively I might add.

If you want to set-up your emacs to use the built-in bsd style, please
by all means to so, but in your own .emacs

Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] PostgreSQL-SDBC in LO: licensing

2011-11-17 Thread Lionel Elie Mamane 
On Thu, Nov 17, 2011 at 05:33:48AM -0600, Norbert Thiebaud wrote:
 On Thu, Nov 17, 2011 at 5:05 AM, Lionel Elie Mamane lio...@mamane.lu wrote:
 On Thu, Nov 17, 2011 at 03:22:33AM -0600, Norbert Thiebaud wrote:
 On Wed, Nov 16, 2011 at 4:22 PM, Lionel Elie Mamane lio...@mamane.lu 
 wrote:

 postgresql-sdbc

 few questions/remarks (mostly on the form, rather than on substance...
 I only glanced at the commits)

 5a2b8cba519bb9d34d3a28a51adcda334147096f:
 Humm, not sure you can do that,

 Sure I can: the code being *dual*-licensed means anybody legitly
 getting a copy of the code can *choose* between obeying the LGPLv2.1
 *OR* obeying the SISSL. I chose LGPLv2.1.

 And that is a problem, because that is not compatible with the
 project license.

Obviously, if it is useful or necessary to include the code in LO, I
agree to keep SISSL. I just didn't think it is.

 but even if you could, removing SISSL is not a good idea since that
 is what allow that code to be merged in libreoffice (which is
 MPL/LGPLv3+)

 I understand you are saying that the SISSL allows us to relicense the
 code under MPL/LGPLv3+; I'm not sure I agree. Could you please explain
 why you think that is?

 In particular, by (re)distributing the SISSL-covered code under
 MPL/LGPLv3+, we allow downstream users to not obey the standards
 body clause of the SISSL. And we are not allowed to allow others to
 not obey that clause of the SISSL.

 The least of 2 'evils': we are LGPLv3+ + MPL that can't work at all
 with LGPLv2

It can, in so far that postgresql-sdbc is compiled as a 'stand-alone'
.so file, and LO dlopen()s it (or more generally links to it). That's
allowed under both postgresql-sdbc's LGPLv2.1 and LO's LGPLv3. I
expect it is also allowed under LO's MPL (section 3.7).

 OTOH SISSL explicitly permit integration under a bigger work with
 the license of the bigger work, provided that SSIL is respected for
 the piece inserted.

Ah, clause 3.7, you are right, that would work. Postgresql-sdbc stays
under SISSL, LO under LGPLv3+/MPL and they are allowed to be
combined. The SISSL just allows it unconditionally (with even the
'obey standard' clause applying only to postgresql-sdbc, not the
whole), LO's LGPLv3+ because it is a separate library and LO's MPL
unconditionally.

We still have to be cautious *not* to copy/paste code between LO and
postgresql-sdbc, because of the different licenses.

I feel we don't gain anything of substance by keeping the SISSL, and
I'm not very strongly opposed to it. If, as a project, LibreOffice
prefers to keep SISSL licensing on that code, I'll agree to it.

 Do you mean that you intend to write code in another style within the
 same file? To me it seems bad practise to mix *different* styles
 within the same file.

 If not, well, the default emacs style (...) does *not* match the
 style of the existing code in that file, (...)

 The 'factory' default yes, but the 'the default'. my .emacs is set the
 way I like it, and it behave the way I am accustomed to (I used a
 customized ellemtel for instance)

 If you want to set-up your emacs to use the built-in bsd style,
 please by all means to so, but in your own .emacs

My .emacs applies to *all* C(++) code I open, not only to LO, so
that's IMHO not the right approach.

What you are saying is that every contributor should change their
.emacs to match the style in LO? From where I stand, the purpose of
the modeline is to make contributor's like easier, that they open the
file, start hacking, and emacs will (as far as possible) automatically
apply the right indentation.

And what if I want to hack on emacs itself, or Linux, or any other
C(++) project that has different style guidelines? I have to change my
.emacs every time I switch from the one to the other? (Or have in my
.emacs functions linux-style, libreoffice-style, emacs-style
that I need to *manually* call every time I open a file from one of
these projects to modify it...) To me it seems like gratuitously
making contributor's life more complicated.

All this being said, I don't think this is worth the time to discuss
it, so OK, I'll remove that (and most probably in future at some point
slip up and commit code indented in the wrong style).

Or how about this:

eval:(if (fboundp 'libreoffice-c-set-style) (libreoffice-c-set-style))

This allows each and every person to set their libreoffice-specific
C(++) indentation styles in their .emacs without impacting the rest of
their C(++) editing work.

It has a *big*, *big* disadvantage, that is that the first time one
opens a file with that in the modeline, one gets a warning about
unsafe value in local variable list; so *every* emacs-using LO
contributor is annoyed at least once until he/she marks that
expression as safe :-(

-- 
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] PostgreSQL-SDBC in LO: licensing

2011-11-17 Thread Norbert Thiebaud 
On Thu, Nov 17, 2011 at 7:33 AM, Lionel Elie Mamane lio...@mamane.lu wrote:

 I feel we don't gain anything of substance by keeping the SISSL, and
 I'm not very strongly opposed to it. If, as a project, LibreOffice
 prefers to keep SISSL licensing on that code, I'll agree to it.


hey, don't get me wrong... I _like_ GPL. If it was up to me I would
not even bother with MPL at all...

I was just concerned with the compatibility of LGPLv2 with LGPLv3+MPL.
and since there is some intent to try to get
to some kind of uniform LGPLv3/MPL compatibility... a LGPLv2 only
piece did not sound like progress toward that goal.

Michael apparently seems ok with dropping SISSL, and he is the biggest
proponent of MPL... so if that is good for him
and it is the fact that LGPLv2 is not at issue here (wrt with the
integation in the 'whole)
I don't care that much (actually that make the head smaller, which is
a plus :-) )


 My .emacs applies to *all* C(++) code I open, not only to LO, so
 that's IMHO not the right approach.

for example, http://www.emacswiki.org/ProjectSettings

If you put all that in the variable-line, the only recourse I have to
override is to patch emacs to make it ignore it :-(


Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice