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