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

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 <lionel@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 <lionel@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