Re: Upstream clang compiler plugins, licensing

[Stephan Bergmann]

On 07/10/2018 19:36, Tamás Zolnai wrote:
As I see LO's license is not compatible with LLVM license [1], as LLVM 
license is a more permissive license which allows to make the code part 
of a proprietary software for example. So I just wonder what is the best 
way to integrate things to clang from LO, either as a compiler plugin or 
a static analyzer check.

[...]

[1] https://opensource.org/licenses/NCSA


note that llvm itself is in the process of updating its license, 
 
"[llvm-dev] LLVM Relicensing Update"

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

Re: Upstream clang compiler plugins, licensing

[Tamás Zolnai]

Hi All,

Thanks for the feedback and ideas. It might be a good idea to discuss this
on ESC and make decision how to relicense the compilerplugins code (if
relicense at all) and also how to avoid to get different licensed files
under compilerplugins folder later.
For now I'm OK with asking the authors for relicensing specific plugins
before writing an upstream check based on that.

Thanks,
Tamás

Luboš Luňák  ezt írta (időpont: 2018. okt. 15., H,
10:52):

> On Wednesday 10 of October 2018, Kaganski Mike wrote:
> > On 10/10/2018 10:53 PM, Tamás Zolnai wrote:
> > > With this new information I agree that it would be the best to clear
> the
> > > licensing and use LLVM in every source file under compilerplugins
> > > folder. So the question is what is the best way to do that. What is the
> > > best way to ask every authors for a permission to relicense the code?
> Do
> > > we need some kind of short license statement from the authors, similar
> > > the general LO license statement?
>
>
>  I don't know, I'm not a lawyer or even close.
>
> > I am not sure that having a subdirectory under core which is licensed
> > differently from the rest of the code is good. I imagine a situation
> > when one would need a license statement like
> >
> >"All of my past & future contributions to LibreOffice may be
> > licensed under the MPLv2/LGPLv3+ dual license.
> >
> > All my contributions to directory foo may be licensed under the bar
> > license.
> >
> > All my contributions to directory bar may be licensed ..."
> >
> > which would become a nightmare. I suppose that if a separate-licensed
> > thing is required, then just create a dedicated project, which would be
> > external dependency for LibreOffice. Of course, you'd need to get the
> > license statements for the existing code (as you discussed).
>
>
>  We already have that, don't we? There are a number of patches under
> external/
> and at least some of those shouldn't be MPLv2/LGPLv3+ licensed.
>
>  And do we even need a generic statement in these cases? How many LO
> developers would ever create code for compilerplugins/ or external/ ?
>
> --
>  Luboš Luňák
>  l.lu...@collabora.com
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Upstream clang compiler plugins, licensing

[Luboš Luňák]

On Wednesday 10 of October 2018, Kaganski Mike wrote:
> On 10/10/2018 10:53 PM, Tamás Zolnai wrote:
> > With this new information I agree that it would be the best to clear the
> > licensing and use LLVM in every source file under compilerplugins
> > folder. So the question is what is the best way to do that. What is the
> > best way to ask every authors for a permission to relicense the code? Do
> > we need some kind of short license statement from the authors, similar
> > the general LO license statement?


 I don't know, I'm not a lawyer or even close.

> I am not sure that having a subdirectory under core which is licensed
> differently from the rest of the code is good. I imagine a situation
> when one would need a license statement like
>
>"All of my past & future contributions to LibreOffice may be
> licensed under the MPLv2/LGPLv3+ dual license.
>
> All my contributions to directory foo may be licensed under the bar
> license.
>
> All my contributions to directory bar may be licensed ..."
>
> which would become a nightmare. I suppose that if a separate-licensed
> thing is required, then just create a dedicated project, which would be
> external dependency for LibreOffice. Of course, you'd need to get the
> license statements for the existing code (as you discussed).


 We already have that, don't we? There are a number of patches under external/ 
and at least some of those shouldn't be MPLv2/LGPLv3+ licensed.

 And do we even need a generic statement in these cases? How many LO 
developers would ever create code for compilerplugins/ or external/ ?

-- 
 Luboš Luňák
 l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Upstream clang compiler plugins, licensing

[Kaganski Mike]

On 10/10/2018 10:53 PM, Tamás Zolnai wrote:
> With this new information I agree that it would be the best to clear the 
> licensing and use LLVM in every source file under compilerplugins 
> folder. So the question is what is the best way to do that. What is the 
> best way to ask every authors for a permission to relicense the code? Do 
> we need some kind of short license statement from the authors, similar 
> the general LO license statement?

I am not sure that having a subdirectory under core which is licensed 
differently from the rest of the code is good. I imagine a situation 
when one would need a license statement like

   "All of my past & future contributions to LibreOffice may be
licensed under the MPLv2/LGPLv3+ dual license.

All my contributions to directory foo may be licensed under the bar
license.

All my contributions to directory bar may be licensed ..."

which would become a nightmare. I suppose that if a separate-licensed 
thing is required, then just create a dedicated project, which would be 
external dependency for LibreOffice. Of course, you'd need to get the 
license statements for the existing code (as you discussed).

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Upstream clang compiler plugins, licensing

[Tamás Zolnai]

Hi Lubos, all,

Thanks for the feedback. I did not notice that a lots of compilerplugins
source files are actually licensed with LLVM license, not only the plugin.*
files. I expect that it happened as you described, LO header template was
just copied without considering what is the right license.
With this new information I agree that it would be the best to clear the
licensing and use LLVM in every source file under compilerplugins folder.
So the question is what is the best way to do that. What is the best way to
ask every authors for a permission to relicense the code? Do we need some
kind of short license statement from the authors, similar the general LO
license statement?

Thanks,
Tamás

Luboš Luňák  ezt írta (időpont: 2018. okt. 10., Sze,
12:55):

> On Sunday 07 of October 2018, Tamás Zolnai wrote:
> > Hi all,
> >
> > I plan to work on clang static analyzer in the next monthes and I'm
> > wondering whether how we can move some of the LO's compiler plugins to
> > upstream.
> >
> > As I see LO's license is not compatible with LLVM license [1], as LLVM
> > license is a more permissive license which allows to make the code part
> of
> > a proprietary software for example. So I just wonder what is the best way
> > to integrate things to clang from LO, either as a compiler plugin or a
> > static analyzer check.
> >
> > An idea might be to relicense the compilerplugin code with the LLVM
> > license, which means additional administration of course, but would make
> > reusing the code much easier. However I'm not sure this is the best way
> to
> > solve this licensing incompatibility.
>
>  Yes, that's the right idea. In fact all the plugins should be
> LLVM-licensed,
> that's the way I started it and e.g. plugin.* explicitly specifies that
> license. It doesn't even really make sense to use any other license for
> this
> code, I expect people just copy the generic LO header without
> thinking
> about it.
>
>  As far as I'm concerned, just ask everyone involved to change the license
> to
> LLVM's and if somebody disagrees, nuke that code (unless that somebody
> would
> have a good reason for it, which I doubt).
>
> --
>  Luboš Luňák
>  l.lu...@collabora.com
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Upstream clang compiler plugins, licensing

[Luboš Luňák]

On Sunday 07 of October 2018, Tamás Zolnai wrote:
> Hi all,
>
> I plan to work on clang static analyzer in the next monthes and I'm
> wondering whether how we can move some of the LO's compiler plugins to
> upstream.
>
> As I see LO's license is not compatible with LLVM license [1], as LLVM
> license is a more permissive license which allows to make the code part of
> a proprietary software for example. So I just wonder what is the best way
> to integrate things to clang from LO, either as a compiler plugin or a
> static analyzer check.
>
> An idea might be to relicense the compilerplugin code with the LLVM
> license, which means additional administration of course, but would make
> reusing the code much easier. However I'm not sure this is the best way to
> solve this licensing incompatibility.

 Yes, that's the right idea. In fact all the plugins should be LLVM-licensed, 
that's the way I started it and e.g. plugin.* explicitly specifies that 
license. It doesn't even really make sense to use any other license for this 
code, I expect people just copy the generic LO header without thinking 
about it.

 As far as I'm concerned, just ask everyone involved to change the license to 
LLVM's and if somebody disagrees, nuke that code (unless that somebody would 
have a good reason for it, which I doubt).

-- 
 Luboš Luňák
 l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Upstream clang compiler plugins, licensing

[Tamás Zolnai]

Hi Noel,

It's good idea to pick up one plugin first and discuss with the authors and
relicense that plugin only. I think this also means that we'll need to
change the license header of the plugin's source file to LLVM license so
it's unambigous what is the license of this specific plugin. The only
question is that whether it's OK to have mixed licensed files inside LO
source code (some files with LLVM license, others with LO's license).

I expected that I need to adapt the code for clang, but I think it's still
good to make licensing compatible even if I use only small part of the code
one-on-one way.

Best Regards,
Tamás

Noel Grandin  ezt írta (időpont: 2018. okt. 7., V,
19:55):

>
> IANAL, obviously, but possibly you could pick the plugins you want and ask
> all the people who worked on that plugin to re-license their work (there
> are not that many, and they are mostly still around)
>
> For the record, for anything in compilerplugins/ that I have touched, I
> grant you permission to submit my work to LLVM under their license.
>
> Also, note that LLVM is likely to want you to write the plugins in quite
> a different style, they don't use our style of overriding ASTVisitor
> anymore, so upstreaming is not trivial, they like using some kind of
> matcher API for traversing the AST, and they have a whole Checker framework
> for clang-tidy stuff.
>
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Upstream clang compiler plugins, licensing

[Noel Grandin]

IANAL, obviously, but possibly you could pick the plugins you want and ask
all the people who worked on that plugin to re-license their work (there
are not that many, and they are mostly still around)

For the record, for anything in compilerplugins/ that I have touched, I
grant you permission to submit my work to LLVM under their license.

Also, note that LLVM is likely to want you to write the plugins in quite a
different style, they don't use our style of overriding ASTVisitor anymore,
so upstreaming is not trivial, they like using some kind of matcher API for
traversing the AST, and they have a whole Checker framework for clang-tidy
stuff.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Upstream clang compiler plugins, licensing

[Tamás Zolnai]

Hi all,

I plan to work on clang static analyzer in the next monthes and I'm
wondering whether how we can move some of the LO's compiler plugins to
upstream.

As I see LO's license is not compatible with LLVM license [1], as LLVM
license is a more permissive license which allows to make the code part of
a proprietary software for example. So I just wonder what is the best way
to integrate things to clang from LO, either as a compiler plugin or a
static analyzer check.

An idea might be to relicense the compilerplugin code with the LLVM
license, which means additional administration of course, but would make
reusing the code much easier. However I'm not sure this is the best way to
solve this licensing incompatibility.

Any idea is appreciated here or any experience with upstreaming to an open
source software with incompatible license.

Thanks,
Tamás

[1] https://opensource.org/licenses/NCSA
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Kowther Hassan Licensing Statement

[Kowther Hassan]

All of my past & future contributions to LibreOffice may be licensed
under the MPLv2/LGPLv3+ dual license.


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

Licensing Statement

[Yehoshua Kahan]

All of my past & future contributions to LibreOffice may be licensed
under the MPLv2/LGPLv3+ dual license.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Firebird-SDBC Licensing

[Andrzej J. R. Hunt]

Hi,

The Firebird-sdbc drivers still have BSD licence headers, which I
believe is a relic of the skeleton driver. Is it acceptable to add the
following to the top of the file as is done for MPL/Apache (APL?) and
previously MPL/LGPL mix-licenced files?

 * This file is part of the LibreOffice project.
 *
 * This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/.
 *
 * This file incorporates work covered by the following license notice:
*
Original BSD License notice HERE

(The skeleton driver itself seems to have been migrated to APL within AOO, see
http://svn.apache.org/viewvc/openoffice/trunk/main/odk/examples/DevelopersGuide/Database/DriverSkeleton/
However I guess keeping the BSD licence for LO makes it more useful?)

Cheers,

Andrzej


signature.asc
Description: This is a digitally signed message part
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Licensing

[Gregg King]

Forgot to include this with my patch!

All of my past and future contributions to LibreOffice may be licensed
under the MPL/LGPLv3+ dual license.


Cheers,

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

Re: Licensing 35079

[Cedric Bosdonnat]

On Wed, 2012-08-15 at 09:35 +0200, Lennard Wasserthal wrote:
 So to make it clear:
 
 I publish my patch
 [PATCH] fdo#35079: EDITING: Drawing element completely in mouse 
 selection frame not selected.
 Drawing: Fixed Custom Shape Frame-Selection Bounding box bug.
 
 under the terms of the LGPLv3+ and MPL dual license.
 
 An next time I will write it directly to avoid unnecessary mails.

Thanks a lot! I added you to the list here with a link to this email:
https://wiki.documentfoundation.org/Development/Developers

--
Cedric

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

Re: Licensing 35079

[Michael Meeks]

On Wed, 2012-08-15 at 09:35 +0200, Lennard Wasserthal wrote:
 I publish my patch
...
 under the terms of the LGPLv3+ and MPL dual license.
 An next time I will write it directly to avoid unnecessary mails.

Thanks for your contribution ! :-) it's simply brilliant to have people
working on bug fixing and improving the product.

As for the boring paper-work; it makes my life -significantly- easier,
if instead of having to track and associated an archived license
statement per-patch; you could give a blanket license statement. This is
what linkage into:

http://wiki.documentfoundation.org/Development/Developers

is really for - see some of the samples there; Cedric - please don't
link single license statements into there without some annotation just
one patch or something - otherwise reviewers can get confused. Of
course, I check all the links there as I build my database but ... ;-)

Anyhow - excited by the contribution, and looking forward to your
next ! :-)

All the best,

Michael.

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

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

Licensing 35079

[Lennard Wasserthal]

So to make it clear:

I publish my patch
[PATCH] fdo#35079: EDITING: Drawing element completely in mouse 
selection frame not selected.

Drawing: Fixed Custom Shape Frame-Selection Bounding box bug.

under the terms of the LGPLv3+ and MPL dual license.

An next time I will write it directly to avoid unnecessary mails.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

MPL/LGPL Contribution Licensing

[Tim Janik]

All of my past  future contributions to LibreOffice may be licensed
under the MPL/LGPLv3+ dual license.

-- 
Yours sincerely,
Tim Janik

---
http://lanedo.com/~timj/ - Managing director at Lanedo GmbH.
Free software author and contributor on various projects.

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

Re: [Libreoffice-ux-advise] Artwork licensing

[Alexander Wilms]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

during the last IRC meeting of the design team we decided that we'd
like to use an icon from the elementary icon theme if possible.

Should I ask the author whether he'd be ok with dual-licensing his work
under MPL and CC-BY?

Thanks

Alex
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQEBmIAAoJECO1/tAiWGrNb1kIAK3Fr7YPENX48dV0reBDOSLZ
nhK3WvGWs64vwl9WRyFk3VqpH0dYda4bz5FL9kjn5FCwzCZ5jQlHgiEqfzYuoqsM
G5IbDkygf/5nA7gNCdkWDJpyjxTwoYEYvgoM1l/LEFvz8y83ex0YxsPLhsB+IhpJ
EGRzhxObghxnBKHShU2UPtK+YTJ+heHokr/Z1ZlRUOzHPxJdhnmfjUhHNKbCrMHH
J4dB9vh+boEm3eurOw5/RFASorE3bZUoCnBOSPyevgRwC058WE9WAPNhadD0gFwr
vJM5/IcIeueZj6Ldozvvb/jZpwjY4HGog3PrWnrtSVGsC2J3ybYDTkjo+wfwDEc=
=UCw1
-END PGP SIGNATURE-


___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Re: [Libreoffice-ux-advise] Artwork licensing

[Alexander Wilms]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

We've just found an equivalent icon in the gnome theme. That should
make licensing easier.

Alex
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQEEGDAAoJECO1/tAiWGrNR0wH/RgcBgjqaDGgTjRfZN8QGKOc
b3zyekLhcbqbwFWb8UAQTjn785i/CrAwN/7/F7ibFGjLOxMZHqEA1o9ne+QwWiJy
wMxXZfU3qiLK85OOjP80gVS5i2SbyJ+YzfF1l2hFLJqVKdvA3QdZ3ThxUpdPtZJ2
bABj0084WHG5zlGLPy+DvGOvHr70uMDlOWiSR803J8v8MRHUnMogcnNWLe/pIf2m
t0ocpYKKv5TaEc8uNloLsP+CnlJdtA9NZmLRkXiPpwcyjJxENWag8MIG8GF8bQww
09QEANm8CUvHkubHy4kWwb33/TdhuZhLMzKYBcF10gsQ7R91/5/AJ0O+nhgwsBg=
=kZOo
-END PGP SIGNATURE-


___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] Artwork licensing

[Mirek M.]

Hi Michael,
Given that it's unlikely that we'll get an okay from the Gnome icon authors
to relicense their work under the MPL anytime soon, perhaps we could think
about licensing all LibreOffice artwork under the more art-appropriate
cc-by license from now on. This would not only decrease confusion around
licensing in LibreOffice, but would also make it easier for
differently-licensed projects to incorporate our Tango icons and for us to
exchange Tango icons with Gnome.
Would that be a possibility? What is your take on this?
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

Templates licensing

[Alexander Wilms]

All my past and future contributions to the templates that I submit to 
be bundled with LibreOffice may be licensed under the CC0 license.


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

About Clean Inspiration Template Licensing

[Mateus Machado Luna]

All my past and future contributions to the LibreOffice Clean Inspiration
template may be licensed under the CC0 license. :)

-- 
*Mateus Machado Luna*
4º ano do Curso de Eletrônica Integrado ao Nível Médio - IFG Goiânia.
http://www.flickr.com/photos/mateus-ml-wetah/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

MPL/LGPLv3+ re-licensing

[Alexandr N. Zamaraev]

All of my past  future contributions to LibreOffice may be licensed
under the MPL/LGPLv3+ dual license
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

licensing statement

[David Nalley]

All of my past  future contributions to LibreOffice may be
licensed under the MPL/LGPLv3+ dual license
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

MPL/LGPLv3+ re-licensing audit

[Vicente Vendrell]

All of my past  future contributions to LibreOffice may be licensed under
the MPL/LGPLv3+ dual license

 

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

Licensing

[Ed Dean]

Sorry if this is noise, but Michael Meeks asked for it!  Blame him! :-P

All of my past/existing contributions to LibreOffice may be licensed
under the MPL/LGPLv3+ dual license.


Hate to use future tense since that requires predictive skill which
I'm horrible at.  Hope that at least sets things straight.  All I did
was remove dead code I think, so it probably wont matter in any case.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Licensing of my contributions to Libre Office

[LeMoyne Castle]

To whom it concerns:

All of my past  future contributions to LibreOffice may be licensed under
the MPL/LGPLv3+ dual license.

John LeMoyne Castle
lemoyne.cas...@gmail.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Licensing

[Alan Du]

All of my past  future contributions to LibreOffice may be licensed under the 
MPL/LGPLv3+ dual license
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Licensing my contributions

[surensp...@gmail.com]

All of my past  future contributions to LibreOffice may be licensed under
the MPL/LGPLv3+ dual license.

Cheers,
Suren.

-- 
Cheers,
~Suren.

Co-Founder, Goyaka Labs
http://suren.in
http://twitter.com/suren
skype: pingsuren
Ph: 9742077760
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Licensing

[Roth Robert]

I might have forgotten to mention previously with my patches:
All of my past  future contributions to LibreOffice may be licensed under
the MPL/LGPLv3+ dual license.

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

Licensing (blanket statement)

[Giuseppe Castagno]

Hi there,

as per subject, better put:

All of my past  future contributions to LibreOffice may be
licensed under the MPL/LGPLv3+ dual license

Thanks,

--
Kind Regards,
Giuseppe Castagno
Acca Esse http://www.acca-esse.eu
giuseppe.castagno at acca-esse.eu
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Licensing

[Roland Baudin]

Hi,

all of my past  future contributions to LibreOffice may be 
licensed under the MPL/LGPLv3+ dual license.


Best regards,
Roland Baudin

--
X File Explorer http://roland65.free.fr/xfe
Toutes Choses http://roland65.free.fr/ttc
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Licensing

[Roland Baudin]

Hi,

all of my past  future contributions to LibreOffice may be 
licensed under the MPL/LGPLv3+ dual license.


Best regards,
Roland Baudin

--
X File Explorer http://roland65.free.fr/xfe
Toutes Choses http://roland65.free.fr/ttc
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Licensing Statement for LibreOffice contributions

[Steven Butler]

Hi,

All of my past  future contributions to LibreOffice may be licensed under
the MPL/LGPLv3+ dual license.

-- 
Regards,
Steven Butler
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

exine - licensing

[Marcin Merda]

All of my past  future contributions to LibreOffice may be licensed under
the MPL/LGPLv3+ dual license
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Licensing of my contribs

[Julian Seward]

As per request by Michael M:

  All of my past contributions to LibreOffice may be licensed 
  under the MPL/LGPLv3+ dual license, including the go-oo code.

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

Re: LIcensing of libwp* and its effect on that of libcdr and libvisio

[Lubos Lunak]

On Monday 27 of February 2012, Michael Meeks wrote:
 On Mon, 2012-02-27 at 20:00 +0200, Tor Lillqvist wrote:
  The older libwpd, libwpg and libwps libraries are LGPLv2+ The newer
  libcdr and libvisio libraries written in the same style are
  MPL/LGPL.v+2/GPLv2+
  However, as they depend on libwp* stuff, and link to them (statically)
  or maybe include inline C++ code from libwp* headers, that is
  irrelevant, isn't it, they effectively become LGPLv2+-only, too?

   Linking statically might have an unintended licensing impact (IANAL),
 but my hope would be that we could re-work the (fairly small?) parts of
 libwp* that are required for libcdr / libvisio and/or persuade the
 authors to MPL dual license them, such that we can ship them on iOS :-)
 [ I assume that is the question behind the question ].

 IANAL either, but I think the linking mechanism on its own doesn't matter. 
AFAIK the LGPL distinguishes between a derived work of the library and work 
using the library, and our case should be the latter. While the sooner 
requires the result to be LGPL, the latter only has smaller requirements, 
which can be satisfied by providing a notice and our source code. 
Specifically, I think section 5 of LGPLv3 applies here.

 But the proper solution to this problem is finding somebody who can't say 
IANAL and thus should be able to provide a founded answer. I would be 
surprised if e.g. SUSE lawyers haven't run into this yet.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LIcensing of libwp* and its effect on that of libcdr and libvisio

[Tor Lillqvist]

 requires the result to be LGPL, the latter only has smaller requirements,
 which can be satisfied by providing a notice and our source code.

Providing source code (or pre-built object files even), is not enough,
necessarily.

I am thinking from the perspective of somebody wanting to distribute
an app using LibreOffice code, and potentially then also libwp* code,
on the iOS App Store. (LibreOffice itself I hope by then is LGPL/MPL,
MPL being the license that would be used in this case.)

As long as there is a risk that even one of the unknown number of
people holding copyright to libwp* doesn't approve of that, I wouldn't
suggest risking it... (The same holds for other LGPL libraries LO
potentially can use.)

It's not hard to interpret LGPLv2 so that it prevents that kind of
DRM-encumbered distribution of binaries. (After all, it was written
in frigging 1991.) No matter how good intent the app developer has,
how nicely he/she would provide source to everything , etc.

(Back in 1991 most compilers used on what was then normal desktop Unix
systems were definitely not free (in any sense), so the fact that iOS
development program membership (needed to distribute apps through the
App Store) costs €79/a is fairly irrelevant, I think, from LGPLv2's
point of view. It's the DRM and review process that somebody might say
is unacceptable. I think. But, IANAL.)

(And as for LGPLv3, it probably is even easier to interpret it in this
way, or perhaps one of its intents is specifically to prevent such
distribution? I say this based only on my prejudice and vague
knowledge of FSF's and their Dear Leader's opinions of Apple and their
ecosystem...)

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

LIcensing of libwp* and its effect on that of libcdr and libvisio

[Tor Lillqvist]

The older libwpd, libwpg and libwps libraries are LGPLv2+ The newer
libcdr and libvisio libraries written in the same style are
MPL/LGPL.v+2/GPLv2+ However, as they depend on libwp* stuff, and link
to them (statically) or maybe include inline C++ code from libwp*
headers, that is irrelevant, isn't it, they effectively become
LGPLv2+-only, too?

IANAL, am I missing something?

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

Re: LIcensing of libwp* and its effect on that of libcdr and libvisio

[Michael Meeks]

Hi Tor,

On Mon, 2012-02-27 at 20:00 +0200, Tor Lillqvist wrote:
 The older libwpd, libwpg and libwps libraries are LGPLv2+ The newer
 libcdr and libvisio libraries written in the same style are
 MPL/LGPL.v+2/GPLv2+

Right.

 However, as they depend on libwp* stuff, and link to them (statically)
 or maybe include inline C++ code from libwp* headers, that is
 irrelevant, isn't it, they effectively become LGPLv2+-only, too?

Linking statically might have an unintended licensing impact (IANAL),
but my hope would be that we could re-work the (fairly small?) parts of
libwp* that are required for libcdr / libvisio and/or persuade the
authors to MPL dual license them, such that we can ship them on iOS :-)
[ I assume that is the question behind the question ].

Presumably some sort of audit would be necessary there; fun as it
is ;-) I'll prolly delay doing that until after the go-oo  libreoffice
audits are done [ currently in progress ].

So - for iOS, I guess that means disabling them in configure /
elsewhere for now.

HTH,

Michael.

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

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

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

[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

[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

[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

[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

[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

[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

[Libreoffice] licensing and email change

[Laurent Godard]

HI all

Please note my email change from oooc...@free.fr to
lgodard.li...@laposte.net

the most important

I license all my contributions past+future under
MPL/LGPLv3+

Laurent


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

[Libreoffice] Licensing information

[Ivan Timofeev]

I confirm that all my patches to LibreOffice are licensed under
LGPL3+/GPL3+/MPL.

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

[Libreoffice] licensing statement

[Michael Stahl]

hi all,

licensing statement, valid until further notice:

Any patches of which i'm the author that i send to the LibreOffice lists
or commit to the LibreOffice repos are available under LGPLv3+/MPLv1.1
license unless explicitly noted otherwise, or, in case of newly added
files, the license header says otherwise.

regards,
 michael

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

Re: [Libreoffice] Licensing

[Norbert Thiebaud]

On Wed, Sep 7, 2011 at 1:58 PM, Peter Foley pefol...@verizon.net wrote:
 On Wed, 7 Sep 2011, Peter Foley wrote:

 All of my patches are contributed under
 MPL 1.1/GLPv3+/LGPLv3+

 Thanks,

Thanks you for that, and thank you for having updated
http://wiki.documentfoundation.org/Development/Developers, much
appreciated :-)

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

[Libreoffice] Licensing

[Peter Foley]

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

Re: [Libreoffice] Licensing

[Peter Foley]

On Wed, 7 Sep 2011, Peter Foley wrote:

All of my patches are contributed under
MPL 1.1/GLPv3+/LGPLv3+

Thanks,

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

Re: [Libreoffice] Licensing information collection for Dev submitting patch

[Michael Meeks]

Hi Norbert,

On Sun, 2011-08-28 at 15:01 -0500, Norbert Thiebaud wrote:
 I've added a 'License' column in the list of developers in the wiki
 http://wiki.documentfoundation.org/Development/Developers

Thanks for doing that :-) there is a 'le...@documentfoundation.org'
alias - to which I send private mails where people do this. I can't find
public archives, which is prolly for a reason.

 finding that statement in the mailing list history is not trivial.. so
 having these referenced in a centralized place in the wiki would help.

True.

 I encourage patch submitters to fill the wiki page above with the
 relevant information. If you do not want to create a wiki account,
 send me an email with the information you'd like to see there and
 I'll fill it for you.

Thanks for diging that out :-)

 Note: I'll use this email for the purpose of registering my statement
 of license. This is _my_ version of it, by no mean should this be
 considered a template or a suggested wording :-) IANAL etc...

ATB,

Michael.

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

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

[Libreoffice] Licensing information collection for Dev submitting patch

[Norbert Thiebaud]

I've added a 'License' column in the list of developers in the wiki
http://wiki.documentfoundation.org/Development/Developers

This column is meant to have links to post(s) in the mailing list that
indicate the concerned developers statement of license.
This is useful for patch reviewer/committer when a specific patch is
not accompanied with an explicit license, but the submitter of the
patch has already posted a blanket statement covering the patch he
submit to the Maling list.
finding that statement in the mailing list history is not trivial.. so
having these referenced in a centralized place in the wiki would help.

I encourage patch submitters to fill the wiki page above with the
relevant information.
If you do not want to create a wiki account, send me an email with the
information you'd like to see there and I'll fill it for you.

Norbert.

Note: I'll use this email for the purpose of registering my statement
of license. This is _my_ version of it, by no mean should this be
considered a template or a suggested wording :-) IANAL etc...

--


Any patches I submit to the libreoffice-dev mailing list or that I
commit directly in the libreoffice repositories contrib/dev-tools and
contrib/buildbot are under GPLv3+ unless specified otherwise in the
commit message or unless this is a new file, in which case the
licensing information inside the new file, if any, govern.

Any patches I submit to the libreoffice-dev mailing list or that I
commit directly in the libreoffice repositories other than
contrib/dev-tools and contrib/buildbot are under MPL 1.1/LGPLv3+/GPL3+
unless specified otherwise in the commit message or unless this is a
new file, in which case the licensing information inside the new file,
if any, govern.

This declaration remain valid until explicitly revoked or amended by a
post on the libreoffice dev-mailing list and is effective September
28th, 2010.


Norbert Thiebaud, on August 28th 2011.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Licensing for my work

[Anurag Jain]

Hello there,

Yeah, I'd like add to what Thorsten said. My work(Including GSOC works
and apart from that) can be submitted to LGPLv3+/MPL dual license and
its future versions also.


Regards

On Wed, Aug 24, 2011 at 2:57 PM, Thorsten Behrens
t...@documentfoundation.org wrote:
 Anurag Jain wrote:
 I'd like to say that all my contribution towards Libre office suite
 codebase can be licensed under LGPSv3/MPL dual license. My work will
 includes all the patches which I've submitted under GSOC program and
 apart from that , and LGPLv3/MPL can be applied to all of them.

 Hi Anurag,

 please, could you confirm that your work is submitted under LGPLv3+?
 With the + being the option to change to any later version of the
 LGPL.

 Thanks,

 -- Thorsten




-- 
Anurag Jain
Final yr B.Tech CSE
SASTRA University
Thanjavur(T.N.)-613402
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Licensing for my work

[Anurag Jain]

Hello everyone,

I'd like to say that all my contribution towards Libre office suite
codebase can be licensed under LGPSv3/MPL dual license. My work will
includes all the patches which I've submitted under GSOC program and
apart from that , and LGPLv3/MPL can be applied to all of them.


Thanks and regards,

-- 
Anurag Jain
Final yr B.Tech CSE
SASTRA University
Thanjavur(T.N.)-613402
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] LibreOffice licensing

[BRM]

- Original Message 

 From: Jesús Corrius je...@softcatala.org
 To: michael.me...@novell.com
 Hi Michael,
 
 On Sat, Jun 4, 2011 at 6:11 PM, Michael Meeks michael.me...@novell.com  
wrote:
 
  On Sat, 2011-06-04 at 08:48 -0400, Allen Pulsifer  wrote:
  1. TDF takes OOo under the Apache License and combines it  with LO
  contributions under the LGPL/MPL and licenses the combined  work
  (LibreOffice) under both the LGPL and MPL?
 
  So if we say MPLv2 and LGPLv3+ - that is fine; and the resulting 
code
   would be under those (compatible) licenses. Which are  copy-left.
 
  2. A third party takes OOo under the Apache  License and combines it with 
LO
  contributions under the MPL and  proprietary closed-source code of its own 
to
  create a proprietary  closed-source product?
 
 If they have changed the MPL code  modules - they need to release 
those
  changes; otherwise (since the MPL  is a weak-copy-left) they can not
  release other changes (like  extensions) they bundle - obviously.
 
  That would not however  stop third parties from combining the
  Apache OpenOffice code with  LibreOffice code and doing with that whatever
  both licenses  allowed.
 
 Sure - one example is IBM, they have a load of  MPL code, and even 
LGPL
  code in Lotus Symphony. Amusingly, IBM are far  more pragmatic in
  practise than ASF is - one of the tragic ironies of  the situation.
 
 
 I guess it would be useful to create a wiki page  with a FAQ about
 these license topics :)
 

Just remember, that even with LGPL/GPL the changes _do not have to be 
contributed back to the community_; only made available to the customers of 
that 
product upon request (per LGPL, GPL and MPL).
IOW, TDF may not necessarily get the contribution. It's just like any 
downstream 
project - they can modify it and don't necessarily have to contribute those 
modifications back to the upstream project.
Sure, it works best when they do as everyone benefits, but they are not 
_required_ to do so.

I only mention this, as it is often overlooked - and in comments like the above 
- by Meeks and others - they seem to forget that aspect about Copy-Left, 
LGPL/GPL/MPL.

So yes, someone could take LO code directly, make a downstream, proprietary 
product and sell it - and they only have to make the code to that proprietary 
version (whether it is identical to the LO version or modified) to those who 
have purchased their proprietary product. (MPL says for 12 months; FSF 
recommends per GPL/LGPL 3 years).

My point being that Allen is 100% correct, and copy-left does not prevent the 
situation you all seem to be so concerned about. Remember, Copy-Left is about 
the End-User, not the Developer.

$0.02

Ben

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

Re: [Libreoffice] LibreOffice licensing

[Kohei Yoshida]

On Mon, 2011-06-06 at 07:39 -0700, BRM wrote:

 Just remember, that even with LGPL/GPL the changes _do not have to be 
 contributed back to the community_; only made available to the customers of 
 that 
 product upon request (per LGPL, GPL and MPL).

Not entirely correct.  The source has to be made available to the legal
recipients of the binary.  Whether or not they are customers is
irrelevant in this context.

 IOW, TDF may not necessarily get the contribution. It's just like any 
 downstream 
 project - they can modify it and don't necessarily have to contribute those 
 modifications back to the upstream project.

Sure.  But we can certainly ask for the source if we are interested, and
they are obligated to provide it if we have (legally) received the
binary, under the same license as the original source code.  This is a
very important point.

 Sure, it works best when they do as everyone benefits, but they are not 
 _required_ to do so.

I wouldn't put it that way.  It works better for the downstream
maintainers if they upstream their work, to make it easier to maintain
their own modifications.  If they think the benefit outweighs the cost
of upstreaming, then they have every right not to upstream their
changes.

 I only mention this, as it is often overlooked - and in comments like the 
 above 
 - by Meeks and others - they seem to forget that aspect about Copy-Left, 
 LGPL/GPL/MPL.

I don't think it is overlooked, but is already implied.

 (MPL says for 12 months; FSF 
 recommends per GPL/LGPL 3 years).

This I didn't know.  Good to know.

 My point being that Allen is 100% correct, and copy-left does not prevent the 
 situation you all seem to be so concerned about. Remember, Copy-Left is about 
 the End-User, not the Developer.

In the context where copy-left licenses such as GPL/LGPL are used, the
end users sometimes (or many times) equal developers.

Surely the majority of end users of consumer applications who are not
developers or servicers of those apps don't really care about the
availability of the source code, though they may care more about the
availability of the binaries.  They may want to have the source
available in case they need to hire consultancies to service the
software after the purchase (or download), but even in those cases the
direct beneficiaries of the copy-left licenses (often referred to as
users in some context) are developers who end up servicing the app for
the users of the binary.

Kohei

-- 
Kohei Yoshida, LibreOffice hacker, Calc
kyosh...@novell.com

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

Re: [Libreoffice] LibreOffice licensing

[BRM]

- Original Message 

 From: Kohei Yoshida kyosh...@novell.com
 To: BRM bm_witn...@yahoo.com
 Cc: libreoffice@lists.freedesktop.org
 Sent: Mon, June 6, 2011 11:44:37 AM
 Subject: Re: [Libreoffice] LibreOffice licensing
 
 On Mon, 2011-06-06 at 07:39 -0700, BRM wrote:
 
  Just remember, that  even with LGPL/GPL the changes _do not have to be 
  contributed back to  the community_; only made available to the customers 
  of 
that 

  product  upon request (per LGPL, GPL and MPL).
 
 Not entirely correct.  The  source has to be made available to the legal
 recipients of the binary.   Whether or not they are customers is
 irrelevant in this context.

When dealing with a proprietary product, they are one-in-the-same, however they 
present the EULA.
 
   IOW, TDF may not necessarily get the contribution. It's just like any 
downstream 

  project - they can modify it and don't necessarily have to contribute  
  those 

  modifications back to the upstream project.
 
 Sure.   But we can certainly ask for the source if we are interested, and
 they are  obligated to provide it if we have (legally) received the
 binary, under the  same license as the original source code.  This is a
 very important  point.

As you pointed out - only if you have a _legal_ right to ask.
That won't likely be the case though unless you are their customer.
Yes, they can't prevent you from distributing the GPL/LGPL/MPL portion of the 
work; but they could prevent you from distributing their additions to the 
degree 
that the MPL/GPL/LGPL derivative work restrictions apply, if at all.
 
  Sure, it works best when they do as everyone benefits, but  they are not 
  _required_ to do so.
 
 I wouldn't put it that  way.  It works better for the downstream
 maintainers if they upstream  their work, to make it easier to maintain
 their own modifications.  If  they think the benefit outweighs the cost
 of upstreaming, then they have  every right not to upstream their
 changes.
 
  I only mention this,  as it is often overlooked - and in comments like the 
above 

  - by Meeks  and others - they seem to forget that aspect about Copy-Left, 
   LGPL/GPL/MPL.
 
 I don't think it is overlooked, but is already  implied.

Overlooked b/c of the nature of the statement. Your next response goes to show 
it...

  (MPL says for 12 months; FSF 
  recommends per  GPL/LGPL 3 years).
 
 This I didn't know.  Good to know.

Most on FLOSS don't - or don't realize it. But if you stopped and read the 
license it would become obvious - especially in the MPL case, didn't take me 
long to find section 3.2, or section 6 of the GPLv3 (specifically 6.d, a-c 
refer 
to distributing the object code/binary while 6d covers the source requirement).

And, FYI, it doesn't have to be public - it could be behind an access protected 
service, or simply a write them and let them know you want a CD kind of thing - 
or even for free.
So yes, one could start a company, make a derivative of LO. Offer it for sale; 
even make modifications, etc. and the only recipients of the changes would be 
said customers of the proprietary version. Further, they only necessarily have 
to get the source if they request it in some form, which may or may not happen 
during the required time period. (There is no requirement in either license 
beyond the required time period.)

So, for example, a customer buys a copy from said company. After 4 years, they 
find a bug they want fixed, but the company only produced the one version. The 
customer is then out-of-luck with any ability to gain access to the source - 
the 
company is under no obligation to do so. Now suppose the company went out of 
business 2 years after the sale, they must then setup a means for 1 year by 
which customers can get the source (supposing Bankruptcy Court/etc allow the 
estate to meet the requirement). But if they went out of business 3 years and 1 
day after the sale then again, there is no further obligation.

  My  point being that Allen is 100% correct, and copy-left does not prevent 
the 

  situation you all seem to be so concerned about. Remember, Copy-Left is  
about 

  the End-User, not the Developer.
 
 In the context where  copy-left licenses such as GPL/LGPL are used, the
 end users sometimes (or  many times) equal developers.
 
 Surely the majority of end users of  consumer applications who are not
 developers or servicers of those apps don't  really care about the
 availability of the source code, though they may care  more about the
 availability of the binaries.  They may want to have the  source
 available in case they need to hire consultancies to service  the
 software after the purchase (or download), but even in those cases  the
 direct beneficiaries of the copy-left licenses (often referred to  as
 users in some context) are developers who end up servicing the app  for
 the users of the binary.
 

Only if the end-user obtains the source to provide to the developer.
The developer may not necessarily

Re: [Libreoffice] LibreOffice licensing

[Kohei Yoshida]

On Mon, 2011-06-06 at 12:32 -0700, BRM wrote:
 - Original Message 
 
  From: Kohei Yoshida kyosh...@novell.com
  To: BRM bm_witn...@yahoo.com
  Cc: libreoffice@lists.freedesktop.org
  Sent: Mon, June 6, 2011 11:44:37 AM
  Subject: Re: [Libreoffice] LibreOffice licensing
  
  On Mon, 2011-06-06 at 07:39 -0700, BRM wrote:
  
   Just remember, that  even with LGPL/GPL the changes _do not have to be 
   contributed back to  the community_; only made available to the customers 
   of 
 that 
 
   product  upon request (per LGPL, GPL and MPL).
  
  Not entirely correct.  The  source has to be made available to the legal
  recipients of the binary.   Whether or not they are customers is
  irrelevant in this context.
 
 When dealing with a proprietary product, they are one-in-the-same, however 
 they 
 present the EULA.

Not one-in-the-same (sic).  But I think we are talking past each other,
so I won't discuss any further.  Your statement already implies that
they are not exactly the same.

IOW, TDF may not necessarily get the contribution. It's just like any 
 downstream 
 
   project - they can modify it and don't necessarily have to contribute  
   those 
 
   modifications back to the upstream project.
  
  Sure.   But we can certainly ask for the source if we are interested, and
  they are  obligated to provide it if we have (legally) received the
  binary, under the  same license as the original source code.  This is a
  very important  point.
 
 As you pointed out - only if you have a _legal_ right to ask.
 That won't likely be the case though unless you are their customer.

Beta test, evaluation versions, demos etc..?  There are a number of ways
of obtaining the binary legally without being a customer.

 Yes, they can't prevent you from distributing the GPL/LGPL/MPL portion of the 
 work; but they could prevent you from distributing their additions to the 
 degree 
 that the MPL/GPL/LGPL derivative work restrictions apply, if at all.
  
   Sure, it works best when they do as everyone benefits, but  they are not 
   _required_ to do so.
  
  I wouldn't put it that  way.  It works better for the downstream
  maintainers if they upstream  their work, to make it easier to maintain
  their own modifications.  If  they think the benefit outweighs the cost
  of upstreaming, then they have  every right not to upstream their
  changes.
  
   I only mention this,  as it is often overlooked - and in comments like 
   the 
 above 
 
   - by Meeks  and others - they seem to forget that aspect about Copy-Left, 
LGPL/GPL/MPL.
  
  I don't think it is overlooked, but is already  implied.
 
 Overlooked b/c of the nature of the statement. Your next response goes to 
 show 
 it...

I don't understand the connection.

 Only if the end-user obtains the source to provide to the developer.

Of course.

 The developer may not necessarily be granted the right by the proprietary 
 distributor to get direct access to the source.

 So I still maintain that it is end-users and not _necessarily_ developers 
 that Copy-left is about.

Ok.  This is already becoming a meaningless word game.  My point
basically is that the distinction between the end users and developers
are not necessarily clear cut when talking about copy-left licenses.  No
more no less.  And I believe, based on what you said you also agree with
that.

 However, if I as a developer come along and tell them that I could add some 
 feature to it, they would need to ask for and obtain the source code for me 
 if 
 that was necessary.

Of course.  I never said that the developers didn't have to get the
source code to service the software.

Anyway, this is already off-topic here on this list.  I suggest we end
this thread here, and if anybody is interested on pursuing this, take it
to a more appropriate list.

Kohei

-- 
Kohei Yoshida, LibreOffice hacker, Calc
kyosh...@novell.com

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

[Libreoffice] LibreOffice licensing

[Allen Pulsifer]

 If I understand correctly:
 What is developed by the Apache license can be used at LibreOffice but
what is done by LibreOffice
 can not be used by OpenOffice as OpenOffice would move to offer the
principles of under the GPL.

I'm not sure this is entirely correct.  TDF allowed itself some license
flexibility by asking that all contributions to LO be licensed under both
the LGPL and the MPL.

Originally, TDF took OOo code under the LGPL, combined it with dual licensed
LGPL/MPL contributions, and licensed the combined work under the LGPL, as
required by the LGPL.

That situation will likely change in the near future.  The original OOo code
will shortly be released under the Apache License (AL).  The Apache License
allows anyone to take the code and use it in a proprietary work.  Once the
OOo code is released under the AL, I expect to see many people recompiling
OOo and selling it, some with no modifications, some with their own
proprietary closed-source enhancements.

The Apache Foundation will also likely to be hosting an Apache OpenOffice
project where people can make contributions to that codebase, with the
contributions also licensed under the Apache License.  TDF will be able to
use those contributions in LO.  Everyone else will also be able to use those
contributions, in both open-source and proprietary projects.

Here's the tricky part.  With the release of the original OOo code under the
Apache License, it may now be possible, depending on license compatibility,
to take the original OOo under the AL, combine it with LO modifications
under the MPL, and incorporate that code into a closed-source project.  If
that is possible, we may also soon see the LO code incorporated into
proprietary products.

I'm not an expert on the compatibility of these two licenses however, either
with each other or with proprietary code.  Can anyone offer an opinion or
shed some light on this?  Which of the following could occur, once the
original OOo codebase is released under the Apache License?

1. TDF takes OOo under the Apache License and combines it with LO
contributions under the LGPL/MPL and licenses the combined work
(LibreOffice) under both the LGPL and MPL?

2. A third party takes OOo under the Apache License and combines it with LO
contributions under the MPL and proprietary closed-source code of its own to
create a proprietary closed-source product?

Regardless of the above two situations, the Apache Software Foundation will
not take LO modifications dual-licensed under the LGPL and MPL and include
them in the Apache OpenOffice distribution.  There may be no license barrier
to that, but ASF has a policy barrier that prevents it: the ASF has a policy
that all code distributed at the ASF must be licensed only under the Apache
License.  The ASF will not incorporate any code that requires a different
license.  That would not however stop third parties from combining the
Apache OpenOffice code with LibreOffice code and doing with that whatever
both licenses allowed.


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

Re: [Libreoffice] LibreOffice licensing

[Rafael Dominguez]

Well im no legal expert, but from what i understand of the LGPL/MPL
licenses, they still are copyleft licenses, you can merge apache code and
libreoffice code, make your own version if you want, sell it etc, but if you
make any derivative work, you need to make those changes available to the
rest, so i dont think its possible to make a closed source office suite with
libreoffice code under LGPL/MPL.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] LibreOffice licensing

[Greg Stein]

On Sat, Jun 4, 2011 at 10:59, Rafael Dominguez venccsra...@gmail.com wrote:

 Well im no legal expert, but from what i understand of the LGPL/MPL
 licenses, they still are copyleft licenses, you can merge apache code and
 libreoffice code, make your own version if you want, sell it etc, but if you
 make any derivative work, you need to make those changes available to the
 rest, so i dont think its possible to make a closed source office suite with
 libreoffice code under LGPL/MPL.

A third party could do the following:

1. Core [from Apache], licensed under ALv2.
2. Features [from LO], licensed under MPL (you offer a choice, they pick MPL)
3. Proprietary stuff

This package can then be sold. If they make modifications to the LO
work, then they must release those changes. The third party is not
obligated to release any changes to the Apache code, nor their
proprietary code.

Note that the LGPL operates similarly. A third party could take LO
Core licensed under the LGPL and make releases, alongside
proprietary code. They would need to release changes to the core, but
it would still be possible *today*. The relink requirements under the
LGPL get a bit annoying, but would still be possible.

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

Re: [Libreoffice] LibreOffice licensing

[Michael Meeks]

On Sat, 2011-06-04 at 08:48 -0400, Allen Pulsifer wrote:
 1. TDF takes OOo under the Apache License and combines it with LO
 contributions under the LGPL/MPL and licenses the combined work
 (LibreOffice) under both the LGPL and MPL?

So if we say MPLv2 and LGPLv3+ - that is fine; and the resulting code
would be under those (compatible) licenses. Which are copy-left.

 2. A third party takes OOo under the Apache License and combines it with LO
 contributions under the MPL and proprietary closed-source code of its own to
 create a proprietary closed-source product?

If they have changed the MPL code modules - they need to release those
changes; otherwise (since the MPL is a weak-copy-left) they can not
release other changes (like extensions) they bundle - obviously.

 That would not however stop third parties from combining the
 Apache OpenOffice code with LibreOffice code and doing with that whatever
 both licenses allowed.

Sure - one example is IBM, they have a load of MPL code, and even LGPL
code in Lotus Symphony. Amusingly, IBM are far more pragmatic in
practise than ASF is - one of the tragic ironies of the situation.

HTH,

Michael.

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


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

Re: [Libreoffice] LibreOffice licensing

[Jesús Corrius]

Hi Michael,

On Sat, Jun 4, 2011 at 6:11 PM, Michael Meeks michael.me...@novell.com wrote:

 On Sat, 2011-06-04 at 08:48 -0400, Allen Pulsifer wrote:
 1. TDF takes OOo under the Apache License and combines it with LO
 contributions under the LGPL/MPL and licenses the combined work
 (LibreOffice) under both the LGPL and MPL?

        So if we say MPLv2 and LGPLv3+ - that is fine; and the resulting code
 would be under those (compatible) licenses. Which are copy-left.

 2. A third party takes OOo under the Apache License and combines it with LO
 contributions under the MPL and proprietary closed-source code of its own to
 create a proprietary closed-source product?

        If they have changed the MPL code modules - they need to release those
 changes; otherwise (since the MPL is a weak-copy-left) they can not
 release other changes (like extensions) they bundle - obviously.

 That would not however stop third parties from combining the
 Apache OpenOffice code with LibreOffice code and doing with that whatever
 both licenses allowed.

        Sure - one example is IBM, they have a load of MPL code, and even LGPL
 code in Lotus Symphony. Amusingly, IBM are far more pragmatic in
 practise than ASF is - one of the tragic ironies of the situation.


I guess it would be useful to create a wiki page with a FAQ about
these license topics :)

-- 
Jesús Corrius je...@softcatala.org
Document Foundation founding member
Mobile: +34 661 11 38 26
Skype: jcorrius | Twitter: @jcorrius
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] LibreOffice licensing

[Marc Paré]

Le 2011-06-04 12:11, Michael Meeks a écrit :


On Sat, 2011-06-04 at 08:48 -0400, Allen Pulsifer wrote:

1. TDF takes OOo under the Apache License and combines it with LO
contributions under the LGPL/MPL and licenses the combined work
(LibreOffice) under both the LGPL and MPL?


So if we say MPLv2 and LGPLv3+ - that is fine; and the resulting code
would be under those (compatible) licenses. Which are copy-left.


2. A third party takes OOo under the Apache License and combines it with LO
contributions under the MPL and proprietary closed-source code of its own to
create a proprietary closed-source product?


If they have changed the MPL code modules - they need to release those
changes; otherwise (since the MPL is a weak-copy-left) they can not
release other changes (like extensions) they bundle - obviously.


That would not however stop third parties from combining the
Apache OpenOffice code with LibreOffice code and doing with that whatever
both licenses allowed.


Sure - one example is IBM, they have a load of MPL code, and even LGPL
code in Lotus Symphony. Amusingly, IBM are far more pragmatic in
practise than ASF is - one of the tragic ironies of the situation.

HTH,

Michael.



I am not sure how much this would complicate it, but on Groklaw[1]:

===

Oracle is signing a SGA (Software Grant Agreement) giving the 
OpenOffice.org code to Apache Server Foundation (ASF) under the Apache 
2.0 license. As you know, Oracle (via Sun) had ownership of the code via 
the CLA that they required from contributors. Oracle is also giving ASF 
the OpenOffice.org trademark, the logo with the birds, and the 
openoffice.org domain name.


Some of this has happened already, some of it is in progress.

Oracle appears to be retaining the copyright, not assigning it to 
Apache.


The bottom line, then, if this is so, is that Oracle owns the code it is 
donating, thanks to a contribution agreement whereby contributors handed 
over copyright to Sun, now Oracle. And by retaining the copyright, it 
continues to own the code. Let this be an object lesson, that any time a 
project asks for all the copyrights, it can do what it pleases with your 
contributions. If you don't care, contribute as much as you wish. But do 
it knowing that it's like putting your baby up for adoption. You are not 
the parent any more afterward, so you don't get a say in anything.


===

This seems to be muddying up the waters even more.

Cheers

Marc

[1] http://www.groklaw.net/article.php?story=2011060314010442

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