[Libreoffice] PostgreSQL-SDBC in LO: licensing

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.

> 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