<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 6, 2013 at 12:10 AM, Stéphane Graber <span dir="ltr"><<a href="mailto:stgraber@ubuntu.com" target="_blank">stgraber@ubuntu.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<br>
Well since they're currently shipped out of tree, you're free to do<br>
whatever you want. GPLv2 code is allowed to link with an LGPLv2.1+<br>
library so your code isn't in violation of LXC's license.<br>
<br>
However this very likely means that any software using your Go bindings<br>
will have to be GPLv2 in order to respect the binding's license.<br>
While that's your right, it's fairly uncommon and that's why I tend to<br>
prefer having bindings under a more permissive license with regard to<br>
linking, such as LGPLv2.1+.<br></blockquote><div><br></div><div>That's a good point. I'll re-license them with LGPLv2.1 as your argument really makes sense.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


Btw, speaking of those bindings, do they have to remain out of tree to<br>
be easily usable with go or could they be merged into LXC upstream at<br>
some point?</blockquote><div><br></div><div>I guess one potential issue would be packaging. Right now all magic is handled by "go get" and to be honest it's pretty convenient to use :). A quick Google search yielded multiple discussions about packaging RFC's on both go-nuts and debian mailing list. I haven't read all of them (so maybe I missed something) but it looks like none of them ended up with results. Even Juju's installation instructions says something like "install go via sudo apt-get install golang-go and then get Juju by running go get -v <a href="http://launchpad.net/juju-core/.">launchpad.net/juju-core/.</a>." so I'm assuming there is a reason for that.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">
On Fri, Sep 06, 2013 at 12:01:15AM -0400, S.Çağlar Onur wrote:<br>
> Hey Stéphane,<br>
><br>
> I realized that Go bindings are licensed as GPLv2. I've no objection to<br>
> re-licensing them with LGPL v2.1 but wanted to clarify it with you first.<br>
> Should I go ahead and change the license or is it ok to stay with GPLv2?<br>
><br>
> Best,<br>
><br>
> On Fri, Aug 30, 2013 at 3:42 PM, Stéphane Graber <<a href="mailto:stgraber@ubuntu.com">stgraber@ubuntu.com</a>>wrote:<br>
><br>
> > Hello,<br>
> ><br>
> > First of all, sorry for the boring e-mail, nobody likes to deal with<br>
> > licenses but it's an unfortunate thing we have to deal with from time to<br>
> > time.<br>
> ><br>
> > Thomas Moschny reported some inconsistencies in the way LXC is currently<br>
> > licensed.<br>
> > The bug report is available here: <a href="https://github.com/lxc/lxc/issues/36" target="_blank">https://github.com/lxc/lxc/issues/36</a><br>
> ><br>
> ><br>
> > Basically the way I see it, LXC is made of 4 different bits:<br>
> >  - The main library<br>
> >  - The language bindings<br>
> >  - The binary tools/scripts<br>
> >  - The templates<br>
> ><br>
> > In order to make the library easily usable by others, LXC was originally<br>
> > licensed entirely under the LGPL v2.1 and higher and that certainly<br>
> > makes sense for any bit in the main library as well as for the bindings.<br>
> ><br>
> > Most of the tools, scripts and templates followed course and are also<br>
> > under LGPLv2.1+, some are under GPLv2 and that's all fine since they're<br>
> > tools and not libraries.<br>
> ><br>
> ><br>
> > The problem is that we currently have some files that are part of the<br>
> > library or part of bindings which are licensed under the wrong license,<br>
> > namely, they're currently under GPLv2.<br>
> ><br>
> > I believe this was an oversight and that we should get those switched to<br>
> > the proper license immediately. But I'm not simply going to go ahead and<br>
> > do that myself since I'm not the actual copyright holder for those.<br>
> ><br>
> > Instead, I'd like the original/main author of those to confirm it's fine<br>
> > by them and then we can do that.<br>
> ><br>
> ><br>
> > This still means we'll effectively re-license the code of some of our<br>
> > contributors without explicitly asking them about it. As I said, I'm<br>
> > convinced that this isn't a problem since we're just talking about a<br>
> > handful of files and it's always been clear that the LXC library is<br>
> > licensed under LGPLv2.1+.<br>
> ><br>
> > Nevertheless, if anyone contributed to one of those files we're about to<br>
> > re-license and do not wish their contributions re-licensed, please get<br>
> > in touch as soon as possible so we can remove the affected code from the<br>
> > project.<br>
> ><br>
> ><br>
> > The following files will be re-licensed from GPLv2 to LGPLv2.1+:<br>
> >  - src/lua-lxc/core.c (Dwight)<br>
> >  - src/lxc/lxccontainer.c (Serge)<br>
> >  - src/lxc/lxclock.c (Serge)<br>
> >  - src/lxc/lxclock.h (Serge)<br>
> >  - src/tests/cgpath.c (Serge)<br>
> >  - src/tests/containertests.c (Serge)<br>
> >  - src/tests/createtest.c (Serge)<br>
> >  - src/tests/destroytest.c (Serge)<br>
> >  - src/tests/getkeys.c (Serge)<br>
> >  - src/tests/get_item.c (Serge)<br>
> >  - src/tests/locktests.c (Serge)<br>
> >  - src/tests/lxcpath.c (Serge)<br>
> >  - src/tests/saveconfig.c (Serge)<br>
> >  - src/tests/shutdowntest.c (Serge)<br>
> >  - src/tests/startone.c (Serge)<br>
> >  - templates/<a href="http://lxc-ubuntu.in" target="_blank">lxc-ubuntu.in</a> (Serge)<br>
> >  - templates/<a href="http://lxc-ubuntu-cloud.in" target="_blank">lxc-ubuntu-cloud.in</a> (Serge)<br>
> ><br>
> > Any file that currently doesn't contain a licensing header is assumed to<br>
> > be under the LGPLv2.1+ (as specified in COPYING).<br>
> ><br>
> ><br>
> > Additionally, some of the Android compatibility bits under lxc/includes/<br>
> > are licensed under a two-clause BSD license. To the best of my<br>
> > knowledge, there are no restrictions in linking LGPLv2 code to BSD code.<br>
> ><br>
> ><br>
> > While processing that bug report, I've also noticed some cases where our<br>
> > license headers are out of date (wrong FSF address) or inconsistent (in<br>
> > the form, not the content). I'll be fixing those too before I send the<br>
> > alpha1 pull-request.<br>
> ><br>
> > --<br>
> > Stéphane Graber<br>
> > Ubuntu developer<br>
> > <a href="http://www.ubuntu.com" target="_blank">http://www.ubuntu.com</a><br>
> ><br>
> ><br>
> > ------------------------------------------------------------------------------<br>
> > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!<br>
> > Discover the easy way to master current and previous Microsoft technologies<br>
> > and advance your career. Get an incredible 1,500+ hours of step-by-step<br>
> > tutorial videos with LearnDevNow. Subscribe today and save!<br>
> > <a href="http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk</a><br>
> > _______________________________________________<br>
> > Lxc-devel mailing list<br>
> > <a href="mailto:Lxc-devel@lists.sourceforge.net">Lxc-devel@lists.sourceforge.net</a><br>
> > <a href="https://lists.sourceforge.net/lists/listinfo/lxc-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/lxc-devel</a><br>
> ><br>
> ><br>
><br>
><br>
> --<br>
> S.Çağlar Onur <<a href="mailto:caglar@10ur.org">caglar@10ur.org</a>><br>
<br>
--<br>
Stéphane Graber<br>
Ubuntu developer<br>
<a href="http://www.ubuntu.com" target="_blank">http://www.ubuntu.com</a></div></div></blockquote></div><br clear="all"><div><br></div>-- <br>S.Çağlar Onur <<a href="mailto:caglar@10ur.org">caglar@10ur.org</a>>
</div></div>