Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2, headers to Dual BSD/GPL

Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2, headers to Dual BSD/GPL

[Mathieu Desnoyers]

Hi,

I would like to re-license the tracepoint.c/marker.c files from GPL to:

* Dual LGPL v2.1/GPL v2 license.

And re-license tracepoint.h/marker.h to:

* Dual BSD/GPL v2 license.

The goal is to allow sharing code between the kernel tracer and UST
(User-Space Tracer) project, which is a LGPL v2.1 library. Tracepoint
and marker headers might need to be included by proprietary or BSD
applications, hence the dual BSD/GPL v2 license for these two.

I currently have the OK from Kosaki Motohiro for Fujitsu contributions,
which includes Zhao Lei and Lai Jiangshan.

The missing approvals for Dual LGPL v2.1/GPL v2 relicensing are:

For tracepoint.c:

Jaswinder Singh Rajput <jaswinderrajput@gmail.com>

For marker.c:

"Robert P. J. Day" <rpjday@mindspring.com>
Adrian Bunk <bunk@stusta.de>
Harvey Harrison <harvey.harrison@gmail.com>
Jesper Juhl <jesper.juhl@gmail.com>

The missing approvals for Dual BSD/GPL relicensing are:

For tracepoint.h:

GeunSik Lim <leemgs1@gmail.com>
Steven Rostedt <rostedt@goodmis.org>

For marker.h:

Arnaldo Carvalho de Melo <acme@redhat.com>
Wu Fengguang <fengguang.wu@intel.com>

Note that the markers are now removed from the Linux kernel, but I still
use them temporarily in the LTTng tree (until we do the switch to
TRACE_EVENT). It's therefore also used by UST currently.

Note, you may also need to get permission from your corporation to allow
this.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2, headers to Dual BSD/GPL

[Mathieu Desnoyers]

(updated email for Jesper Juhl)

* Mathieu Desnoyers (mathieu.desnoyers@polymtl.ca) wrote:
> Hi,
> 
> I would like to re-license the tracepoint.c/marker.c files from GPL to:
> 
> * Dual LGPL v2.1/GPL v2 license.
> 
> And re-license tracepoint.h/marker.h to:
> 
> * Dual BSD/GPL v2 license.
> 
> The goal is to allow sharing code between the kernel tracer and UST
> (User-Space Tracer) project, which is a LGPL v2.1 library. Tracepoint
> and marker headers might need to be included by proprietary or BSD
> applications, hence the dual BSD/GPL v2 license for these two.
> 
> I currently have the OK from Kosaki Motohiro for Fujitsu contributions,
> which includes Zhao Lei and Lai Jiangshan.
> 
> The missing approvals for Dual LGPL v2.1/GPL v2 relicensing are:
> 
> For tracepoint.c:
> 
> Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
> 
> For marker.c:
> 
> "Robert P. J. Day" <rpjday@mindspring.com>
> Adrian Bunk <bunk@stusta.de>
> Harvey Harrison <harvey.harrison@gmail.com>

Jesper Juhl <jj@chaosbits.net>

> 
> The missing approvals for Dual BSD/GPL relicensing are:
> 
> For tracepoint.h:
> 
> GeunSik Lim <leemgs1@gmail.com>
> Steven Rostedt <rostedt@goodmis.org>
> 
> For marker.h:
> 
> Arnaldo Carvalho de Melo <acme@redhat.com>
> Wu Fengguang <fengguang.wu@intel.com>
> 
> Note that the markers are now removed from the Linux kernel, but I still
> use them temporarily in the LTTng tree (until we do the switch to
> TRACE_EVENT). It's therefore also used by UST currently.
> 
> Note, you may also need to get permission from your corporation to allow
> this.
> 
> Thanks,
> 
> Mathieu
> 
> -- 
> Mathieu Desnoyers
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2, headers to Dual BSD/GPL

[Ingo Molnar]

* Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:

> Hi,
> 
> I would like to re-license the tracepoint.c/marker.c files from GPL 
> to:
> 
> * Dual LGPL v2.1/GPL v2 license.
> 
> And re-license tracepoint.h/marker.h to:
> 
> * Dual BSD/GPL v2 license.
> 
> The goal is to allow sharing code between the kernel tracer and UST 
> (User-Space Tracer) project, which is a LGPL v2.1 library. Tracepoint 
> and marker headers might need to be included by proprietary or BSD 
> applications, hence the dual BSD/GPL v2 license for these two.

We need a clean interface instead of some messy bindings - why do you 
need a different license to kernel/tracepoint.c?

	Ingo

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2, headers to Dual BSD/GPL

[Mathieu Desnoyers]

* Ingo Molnar (mingo@elte.hu) wrote:
> 
> * Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
> 
> > Hi,
> > 
> > I would like to re-license the tracepoint.c/marker.c files from GPL 
> > to:
> > 
> > * Dual LGPL v2.1/GPL v2 license.
> > 
> > And re-license tracepoint.h/marker.h to:
> > 
> > * Dual BSD/GPL v2 license.
> > 
> > The goal is to allow sharing code between the kernel tracer and UST 
> > (User-Space Tracer) project, which is a LGPL v2.1 library. Tracepoint 
> > and marker headers might need to be included by proprietary or BSD 
> > applications, hence the dual BSD/GPL v2 license for these two.
> 
> We need a clean interface instead of some messy bindings - why do you 
> need a different license to kernel/tracepoint.c?
> 

The short answer is: I want to provide static userspace instrumentation
for fast and manageable userspace tracing. The infrastructure developed
for kernel tracepoints applies directly to userspace, but it needs to be
re-licensed to LGPL so we can trace non-GPL applications.


I'll re-spin the small text I sent to Steven, please tell me if it does
not answer your question:

The intent is to allow the tracer code developed both on the kernel-side
as part of Ftrace and LTTng and on the userspace side within UST to be
shared when appropriate. As a result, we can consider userland-only
solutions to user-space tracing without rewriting all the kernel
tracing infrastructure from scratch.

Tracing library has a small specificity though: if we want to be able to
allow tracing of non-GPL applications, we have to license the library
under a licence different from GPL. LGPLv2.1 seems like a very good fit
for that. It would allow proprietary, BSD and other applications to be
traced by linking dynamically to the LGPL tracing library. The intent is
to be able to provide an updated library version that can be dynamically
linked with these proprietary applications.

So, what I propose is to dual-license at the very least the TRACE_EVENT
generation code under GPLv2/LGPLv2.1 so the callbacks generated can be
used in a LGPL library. I plan to do the same for most of the LTTng
project.

I also plan to license the tracepoint.h header under a GPLv2/BSD-style
dual-license, so proprietary apps can include it. It would be the only
part that would not be relinkable. Note that it only involves the
tracing call sites declarations. I really want the probes generated by
TRACE_EVENT (with #CREATE_TRACE_POINTS) to be LGPL, so we can relink and
upgrade them when necessary.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2, headers to Dual BSD/GPL

[Jesper Juhl]

On Fri, 23 Oct 2009, Mathieu Desnoyers wrote:

> (updated email for Jesper Juhl)
> 
> * Mathieu Desnoyers (mathieu.desnoyers@polymtl.ca) wrote:
> > Hi,
> > 
> > I would like to re-license the tracepoint.c/marker.c files from GPL to:
> > 
> > * Dual LGPL v2.1/GPL v2 license.
> > 
> > And re-license tracepoint.h/marker.h to:
> > 
> > * Dual BSD/GPL v2 license.
> > 
> > The goal is to allow sharing code between the kernel tracer and UST
> > (User-Space Tracer) project, which is a LGPL v2.1 library. Tracepoint
> > and marker headers might need to be included by proprietary or BSD
> > applications, hence the dual BSD/GPL v2 license for these two.
> > 
> > I currently have the OK from Kosaki Motohiro for Fujitsu contributions,
> > which includes Zhao Lei and Lai Jiangshan.
> > 
> > The missing approvals for Dual LGPL v2.1/GPL v2 relicensing are:
> > 
> > For tracepoint.c:
> > 
> > Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
> > 
> > For marker.c:
> > 
> > "Robert P. J. Day" <rpjday@mindspring.com>
> > Adrian Bunk <bunk@stusta.de>
> > Harvey Harrison <harvey.harrison@gmail.com>
> 
> Jesper Juhl <jj@chaosbits.net>
> 

I don't think I have enough significant changes in there to actually 
require my approval for relicensing, but since you ask; I personally 
do not have a problem with that file being Dual LGPL v2.1/GPL v2 
licensed.

-- 
Jesper Juhl <jj@chaosbits.net>             http://www.chaosbits.net/
Plain text mails only, please      http://www.expita.com/nomime.html
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2, headers to Dual BSD/GPL

[Mathieu Desnoyers]

* Jesper Juhl (jj@chaosbits.net) wrote:
> On Fri, 23 Oct 2009, Mathieu Desnoyers wrote:
> 
> > (updated email for Jesper Juhl)
> > 
> > * Mathieu Desnoyers (mathieu.desnoyers@polymtl.ca) wrote:
> > > Hi,
> > > 
> > > I would like to re-license the tracepoint.c/marker.c files from GPL to:
> > > 
> > > * Dual LGPL v2.1/GPL v2 license.
> > > 
> > > And re-license tracepoint.h/marker.h to:
> > > 
> > > * Dual BSD/GPL v2 license.
> > > 
> > > The goal is to allow sharing code between the kernel tracer and UST
> > > (User-Space Tracer) project, which is a LGPL v2.1 library. Tracepoint
> > > and marker headers might need to be included by proprietary or BSD
> > > applications, hence the dual BSD/GPL v2 license for these two.
> > > 
> > > I currently have the OK from Kosaki Motohiro for Fujitsu contributions,
> > > which includes Zhao Lei and Lai Jiangshan.
> > > 
> > > The missing approvals for Dual LGPL v2.1/GPL v2 relicensing are:
> > > 
> > > For tracepoint.c:
> > > 
> > > Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
> > > 
> > > For marker.c:
> > > 
> > > "Robert P. J. Day" <rpjday@mindspring.com>
> > > Adrian Bunk <bunk@stusta.de>
> > > Harvey Harrison <harvey.harrison@gmail.com>
> > 
> > Jesper Juhl <jj@chaosbits.net>
> > 
> 
> I don't think I have enough significant changes in there to actually 
> require my approval for relicensing, but since you ask; I personally 
> do not have a problem with that file being Dual LGPL v2.1/GPL v2 
> licensed.

I wonder if trivial one-liners and cleanups require the approval from
the contributors. In doubt, I prefer to ask. But you might be right that
it's not actually needed.

Thanks!

Mathieu

> 
> -- 
> Jesper Juhl <jj@chaosbits.net>             http://www.chaosbits.net/
> Plain text mails only, please      http://www.expita.com/nomime.html
> Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2, headers to Dual BSD/GPL

[Wu Fengguang]

On Sun, Oct 25, 2009 at 05:03:52AM +0800, Jesper Juhl wrote:
> On Fri, 23 Oct 2009, Mathieu Desnoyers wrote:
> 
> > (updated email for Jesper Juhl)
> > 
> > * Mathieu Desnoyers (mathieu.desnoyers@polymtl.ca) wrote:
> > > Hi,
> > > 
> > > I would like to re-license the tracepoint.c/marker.c files from GPL to:
> > > 
> > > * Dual LGPL v2.1/GPL v2 license.
> > > 
> > > And re-license tracepoint.h/marker.h to:
> > > 
> > > * Dual BSD/GPL v2 license.
> > > 
> > > The goal is to allow sharing code between the kernel tracer and UST
> > > (User-Space Tracer) project, which is a LGPL v2.1 library. Tracepoint
> > > and marker headers might need to be included by proprietary or BSD
> > > applications, hence the dual BSD/GPL v2 license for these two.
> > > 
> > > I currently have the OK from Kosaki Motohiro for Fujitsu contributions,
> > > which includes Zhao Lei and Lai Jiangshan.
> > > 
> > > The missing approvals for Dual LGPL v2.1/GPL v2 relicensing are:
> > > 
> > > For tracepoint.c:
> > > 
> > > Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
> > > 
> > > For marker.c:
> > > 
> > > "Robert P. J. Day" <rpjday@mindspring.com>
> > > Adrian Bunk <bunk@stusta.de>
> > > Harvey Harrison <harvey.harrison@gmail.com>
> > 
> > Jesper Juhl <jj@chaosbits.net>
> > 
> 
> I don't think I have enough significant changes in there to actually 
> require my approval for relicensing, but since you ask; I personally 
> do not have a problem with that file being Dual LGPL v2.1/GPL v2 
> licensed.

Me too.

Thanks,
Fengguang

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2,headers to Dual BSD/GPL

[Zhaolei]

* From: "Wu Fengguang" <fengguang.wu@intel.com>
Subject: Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2,headers to Dual BSD/GPL


> On Sun, Oct 25, 2009 at 05:03:52AM +0800, Jesper Juhl wrote:
>> On Fri, 23 Oct 2009, Mathieu Desnoyers wrote:
>> 
>> > (updated email for Jesper Juhl)
>> > 
>> > * Mathieu Desnoyers (mathieu.desnoyers@polymtl.ca) wrote:
>> > > Hi,
>> > > 
>> > > I would like to re-license the tracepoint.c/marker.c files from GPL to:
>> > > 
>> > > * Dual LGPL v2.1/GPL v2 license.
>> > > 
>> > > And re-license tracepoint.h/marker.h to:
>> > > 
>> > > * Dual BSD/GPL v2 license.
>> > > 
>> > > The goal is to allow sharing code between the kernel tracer and UST
>> > > (User-Space Tracer) project, which is a LGPL v2.1 library. Tracepoint
>> > > and marker headers might need to be included by proprietary or BSD
>> > > applications, hence the dual BSD/GPL v2 license for these two.
>> > > 
>> > > I currently have the OK from Kosaki Motohiro for Fujitsu contributions,
>> > > which includes Zhao Lei and Lai Jiangshan.
>> > > 
>> > > The missing approvals for Dual LGPL v2.1/GPL v2 relicensing are:
>> > > 
>> > > For tracepoint.c:
>> > > 
>> > > Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
>> > > 
>> > > For marker.c:
>> > > 
>> > > "Robert P. J. Day" <rpjday@mindspring.com>
>> > > Adrian Bunk <bunk@stusta.de>
>> > > Harvey Harrison <harvey.harrison@gmail.com>
>> > 
>> > Jesper Juhl <jj@chaosbits.net>
>> > 
>> 
>> I don't think I have enough significant changes in there to actually 
>> require my approval for relicensing, but since you ask; I personally 
>> do not have a problem with that file being Dual LGPL v2.1/GPL v2 
>> licensed.
> 
> Me too.
> 
> Thanks,
> Fengguang

Me too.

Thanks,
Zhaoleiÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2,headers to Dual BSD/GPL

[GeunSik Lim]

On Mon, Oct 26, 2009 at 11:08 AM, Zhaolei <zhaolei@cn.fujitsu.com> wrote:
> * From: "Wu Fengguang" <fengguang.wu@intel.com>
> Subject: Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2,headers to Dual BSD/GPL
>
>
>> On Sun, Oct 25, 2009 at 05:03:52AM +0800, Jesper Juhl wrote:
>>> On Fri, 23 Oct 2009, Mathieu Desnoyers wrote:
>>>
>>> > (updated email for Jesper Juhl)
>>> >
>>> > * Mathieu Desnoyers (mathieu.desnoyers@polymtl.ca) wrote:
>>> > > Hi,
>>> > >
>>> > > I would like to re-license the tracepoint.c/marker.c files from GPL to:
>>> > >
>>> > > * Dual LGPL v2.1/GPL v2 license.
>>> > >
>>> > > And re-license tracepoint.h/marker.h to:
>>> > >
>>> > > * Dual BSD/GPL v2 license.
>>> > >
>>> > > The goal is to allow sharing code between the kernel tracer and UST
>>> > > (User-Space Tracer) project, which is a LGPL v2.1 library. Tracepoint
>>> > > and marker headers might need to be included by proprietary or BSD
>>> > > applications, hence the dual BSD/GPL v2 license for these two.
>>> > >
>>> > > I currently have the OK from Kosaki Motohiro for Fujitsu contributions,
>>> > > which includes Zhao Lei and Lai Jiangshan.
>>> > >
>>> > > The missing approvals for Dual LGPL v2.1/GPL v2 relicensing are:
>>> > >
>>> > > For tracepoint.c:
>>> > >
>>> > > Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
>>> > >
>>> > > For marker.c:
>>> > >
>>> > > "Robert P. J. Day" <rpjday@mindspring.com>
>>> > > Adrian Bunk <bunk@stusta.de>
>>> > > Harvey Harrison <harvey.harrison@gmail.com>
>>> >
>>> > Jesper Juhl <jj@chaosbits.net>
>>> >
>>>
>>> I don't think I have enough significant changes in there to actually
>>> require my approval for relicensing, but since you ask; I personally
>>> do not have a problem with that file being Dual LGPL v2.1/GPL v2
>>> licensed.
>>
>> Me too.
>>
>> Thanks,
>> Fengguang
>
> Me too.
>
> Thanks,
> Zhaolei

Sorry for the late reply. Why do we need a different license to GPLV2
sources that  contributors submitted.?  As Mathieu mentioned, I think
that  GPLV2 based some sources needs  to be relicense  to  trace
non-GPL applications
for some developers and some companies.

In real, Some open source  like QT, MySQL is licensed using dual
license for business strategy. tracepoint.c/marker.c file is GPLv2
currently.

Can  we re-distribute with dual license (e.g: bsd/gplv2 or lgpl
2.1/gplv2)   about some source of linux kernel source? I think that
linux kernel source is GPLv2 only. Frankly speaking, I am not know
exactly about  legal issues of your questions.

Thanks,


-- 
Regards,
GeunSik Lim ( Samsung Electronics )
Blog : http://blog.naver.com/invain/
e-Mail: geunsik.lim@samsung.com
           leemgs@gmail.com , leemgs1@gmail.com
--

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2,headers to Dual BSD/GPL

[Ingo Molnar]

* GeunSik Lim <leemgs1@gmail.com> wrote:

> On Mon, Oct 26, 2009 at 11:08 AM, Zhaolei <zhaolei@cn.fujitsu.com> wrote:
> > * From: "Wu Fengguang" <fengguang.wu@intel.com>
> > Subject: Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2,headers to Dual BSD/GPL
> >
> >
> >> On Sun, Oct 25, 2009 at 05:03:52AM +0800, Jesper Juhl wrote:
> >>> On Fri, 23 Oct 2009, Mathieu Desnoyers wrote:
> >>>
> >>> > (updated email for Jesper Juhl)
> >>> >
> >>> > * Mathieu Desnoyers (mathieu.desnoyers@polymtl.ca) wrote:
> >>> > > Hi,
> >>> > >
> >>> > > I would like to re-license the tracepoint.c/marker.c files from GPL to:
> >>> > >
> >>> > > * Dual LGPL v2.1/GPL v2 license.
> >>> > >
> >>> > > And re-license tracepoint.h/marker.h to:
> >>> > >
> >>> > > * Dual BSD/GPL v2 license.
> >>> > >
> >>> > > The goal is to allow sharing code between the kernel tracer and UST
> >>> > > (User-Space Tracer) project, which is a LGPL v2.1 library. Tracepoint
> >>> > > and marker headers might need to be included by proprietary or BSD
> >>> > > applications, hence the dual BSD/GPL v2 license for these two.
> >>> > >
> >>> > > I currently have the OK from Kosaki Motohiro for Fujitsu contributions,
> >>> > > which includes Zhao Lei and Lai Jiangshan.
> >>> > >
> >>> > > The missing approvals for Dual LGPL v2.1/GPL v2 relicensing are:
> >>> > >
> >>> > > For tracepoint.c:
> >>> > >
> >>> > > Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
> >>> > >
> >>> > > For marker.c:
> >>> > >
> >>> > > "Robert P. J. Day" <rpjday@mindspring.com>
> >>> > > Adrian Bunk <bunk@stusta.de>
> >>> > > Harvey Harrison <harvey.harrison@gmail.com>
> >>> >
> >>> > Jesper Juhl <jj@chaosbits.net>
> >>> >
> >>>
> >>> I don't think I have enough significant changes in there to actually
> >>> require my approval for relicensing, but since you ask; I personally
> >>> do not have a problem with that file being Dual LGPL v2.1/GPL v2
> >>> licensed.
> >>
> >> Me too.
> >>
> >> Thanks,
> >> Fengguang
> >
> > Me too.
> >
> > Thanks,
> > Zhaolei
> 
> Sorry for the late reply. Why do we need a different license to GPLV2
> sources that  contributors submitted.?  As Mathieu mentioned, I think
> that  GPLV2 based some sources needs  to be relicense  to  trace
> non-GPL applications
> for some developers and some companies.
> 
> In real, Some open source  like QT, MySQL is licensed using dual
> license for business strategy. tracepoint.c/marker.c file is GPLv2
> currently.
> 
> Can  we re-distribute with dual license (e.g: bsd/gplv2 or lgpl
> 2.1/gplv2)   about some source of linux kernel source? I think that
> linux kernel source is GPLv2 only. Frankly speaking, I am not know
> exactly about  legal issues of your questions.

Yes, the legality of such relicensing is questionable as that code was 
never developed outside of the kernel but as part of the kernel.

But i also disagree with it on a technical level: code duplication is 
_bad_. Why does the code have to be duplicated in user-space like that? 
I'd like Linux tracing code to be in the kernel repo. Why isnt this done 
properly, as part of the kernel project - to make sure it all stays in 
sync?

So for those two grounds i cannot give my permission for this 
relicensing, sorry.

	Ingo

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2,headers to Dual BSD/GPL

[GeunSik Lim]

On Mon, Oct 26, 2009 at 4:30 PM, Ingo Molnar <mingo@elte.hu> wrote:
> Yes, the legality of such relicensing is questionable as that code was
> never developed outside of the kernel but as part of the kernel.
>
> But i also disagree with it on a technical level: code duplication is
> _bad_. Why does the code have to be duplicated in user-space like that?
> I'd like Linux tracing code to be in the kernel repo. Why isnt this done
> properly, as part of the kernel project - to make sure it all stays in
> sync?
It's right. I am not a special  lawyer about license issues currently.
But, Consider GPL v2 license with philosophical view. I think that this
re-licensing have a some problems in Linux kernel(GPL v2) at least.
> So for those two grounds i cannot give my permission for this
> relicensing, sorry.
I agree with your opinion.
>        Ingo
>



-- 
Regards,
GeunSik Lim ( Samsung Electronics )
Blog : http://blog.naver.com/invain/
e-Mail: geunsik.lim@samsung.com
           leemgs@gmail.com , leemgs1@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2,headers to Dual BSD/GPL

[Alan Cox]

> > Can  we re-distribute with dual license (e.g: bsd/gplv2 or lgpl
> > 2.1/gplv2)   about some source of linux kernel source? I think that
> > linux kernel source is GPLv2 only. Frankly speaking, I am not know
> > exactly about  legal issues of your questions.
> 
> Yes, the legality of such relicensing is questionable as that code was 
> never developed outside of the kernel but as part of the kernel.

We have lots of dual licensed code in the kernel. The copy in kernel may
well only act as GPLv2 but the copy outside has other licences (Linus for
example relicensed some of his early locking primitive/atomic bits for
the Mozilla folks)

> So for those two grounds i cannot give my permission for this 
> relicensing, sorry.

One comment here - and one to be careful of for relicensing purposes. In
most parts of the world if you were paid by an employer to produce the
code that the request relates to then the rights to it belong solely to
the employer. Permission (or refusal) from the code author may well be
meaningless because such permission must come from the employer and right
owner in question (so IBM, Red Hat etc) in those cases and not the author.

Alan

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2,headers to Dual BSD/GPL

[Ingo Molnar]

* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > > Can  we re-distribute with dual license (e.g: bsd/gplv2 or lgpl
> > > 2.1/gplv2)   about some source of linux kernel source? I think that
> > > linux kernel source is GPLv2 only. Frankly speaking, I am not know
> > > exactly about  legal issues of your questions.
> > 
> > Yes, the legality of such relicensing is questionable as that code was 
> > never developed outside of the kernel but as part of the kernel.
> 
> We have lots of dual licensed code in the kernel. [...]

Correct, but that that common case for dual licensing is when it was a 
work existing outside of Linux, licensed differently - and it's a common 
courtesy to keep any GPL-compatible licenses when such code goes into 
the kernel.

This is a different case though. This is about code which was written 
within Linux, was licensed under the kernel's license (GPLv2), written 
and modified by many people - and now it's proposed to be extracted 
under a new license - which license it never had before.

> [...] The copy in kernel may well only act as GPLv2 but the copy 
> outside has other licences (Linus for example relicensed some of his 
> early locking primitive/atomic bits for the Mozilla folks)

That's a more clear-cut case: it's for something independent-looking, 
written from scratch by a single person (Linus) and that person gave the 
second license. (it's also rather trivial wrappers around atomic 
instructions and hence most of it might even be not copyrightable)

> > So for those two grounds i cannot give my permission for this 
> > relicensing, sorry.
> 
> One comment here - and one to be careful of for relicensing purposes. 
> In most parts of the world if you were paid by an employer to produce 
> the code that the request relates to then the rights to it belong 
> solely to the employer. Permission (or refusal) from the code author 
> may well be meaningless because such permission must come from the 
> employer and right owner in question (so IBM, Red Hat etc) in those 
> cases and not the author.

Of course - if performed as hire for work in the US. And there's 
jurisdictions where work performed outside of work hours might still be 
the copyright of the author's. (There's even jurisdictions where only 
natural born persons may have copyright ownership, never corporations.) 
So it's safest to ask for both. IMHO it's a complex, "ask your lawyer" 
issue. I am not a lawyer.

	Ingo

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2,headers to Dual BSD/GPL

[Pierre-Marc Fournier]

Ingo Molnar wrote:
> 
> But i also disagree with it on a technical level: code duplication is 
> _bad_. Why does the code have to be duplicated in user-space like that? 
> I'd like Linux tracing code to be in the kernel repo. Why isnt this done 
> properly, as part of the kernel project - to make sure it all stays in 
> sync?
> 

If you mean that this code should solely be used inside the kernel, then
what you propose technically does not work. There is a very high cost to
accessing kernel code from userspace. This cost is simply unacceptable
for the kind of userspace tracing that is needed today.

OTOH, if you mean that the code should reside in the kernel repository,
as GPL, and should be included inside userspace applications from there,
then you don't have this problem. But you create an even worse problem,
which is that only GPL applications can be distributed with support for
tracing compiled in. Again, this won't do for the needs of the industry.

So the GPL code will have to be rewritten. And this will result in the
exact same drawbacks you are trying to avoid by being against
dual-licensing. The goal of dual-licensing is to make it possible to
keep the code in sync between kernel and userspace, not the opposite!

pmf

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2,headers to Dual BSD/GPL

[Steven Rostedt]

On Mon, 2009-10-26 at 09:17 -0400, Pierre-Marc Fournier wrote:
> Ingo Molnar wrote:
> > 
> > But i also disagree with it on a technical level: code duplication is 
> > _bad_. Why does the code have to be duplicated in user-space like that? 
> > I'd like Linux tracing code to be in the kernel repo. Why isnt this done 
> > properly, as part of the kernel project - to make sure it all stays in 
> > sync?
> > 
> 
> If you mean that this code should solely be used inside the kernel, then
> what you propose technically does not work. There is a very high cost to
> accessing kernel code from userspace. This cost is simply unacceptable
> for the kind of userspace tracing that is needed today.

I think that Ingo is thinking that the tracing is for the kernel, and is
asking why the duplication needs to be done for tools tracing the
kernel.

But what I think is trying to be done here is to use the same types of
MACROS that we have in the kernel to do tracing in userspace. That a
userspace program can add their own "TRACE_EVENT" and that the headers
there will create a tracepoint for them the same way we currently do in
the kernel.

Am I correct in my analysis?

-- Steve

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2,headers to Dual BSD/GPL

[Steven Rostedt]

On Mon, 2009-10-26 at 10:17 +0000, Alan Cox wrote:
> > > Can  we re-distribute with dual license (e.g: bsd/gplv2 or lgpl
> > > 2.1/gplv2)   about some source of linux kernel source? I think that
> > > linux kernel source is GPLv2 only. Frankly speaking, I am not know
> > > exactly about  legal issues of your questions.
> > 
> > Yes, the legality of such relicensing is questionable as that code was 
> > never developed outside of the kernel but as part of the kernel.
> 
> We have lots of dual licensed code in the kernel. The copy in kernel may
> well only act as GPLv2 but the copy outside has other licences (Linus for
> example relicensed some of his early locking primitive/atomic bits for
> the Mozilla folks)
> 

>From what I know (IANAL disclaimer) is that the Author of the code has
the sole right (or employer of said Author) to decide what the license
is. Not what project the code is used in. Unless there's some contract
signed (like for most GNU projects).

If you wrote the code, you have the right (or your employer) to pick and
choose what license it is. You can change the license later on, but of
course the code that went out under one license will stay under that
license. But new releases can have the license change if all authors
agree.


> > So for those two grounds i cannot give my permission for this 
> > relicensing, sorry.
> 
> One comment here - and one to be careful of for relicensing purposes. In
> most parts of the world if you were paid by an employer to produce the
> code that the request relates to then the rights to it belong solely to
> the employer. Permission (or refusal) from the code author may well be
> meaningless because such permission must come from the employer and right
> owner in question (so IBM, Red Hat etc) in those cases and not the author.

Correct, and that is why I went to Red Hat legal for this decision and I
did not make it myself. I also (previously) listed the Red Hat employees
that this decision covers. Red Hat has already given permission for the
GPLv2/LGPL change.

-- Steve

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2,headers to Dual BSD/GPL

[Steven Rostedt]

On Mon, 2009-10-26 at 12:31 +0100, Ingo Molnar wrote:
> * Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
> > > > Can  we re-distribute with dual license (e.g: bsd/gplv2 or lgpl
> > > > 2.1/gplv2)   about some source of linux kernel source? I think that
> > > > linux kernel source is GPLv2 only. Frankly speaking, I am not know
> > > > exactly about  legal issues of your questions.
> > > 
> > > Yes, the legality of such relicensing is questionable as that code was 
> > > never developed outside of the kernel but as part of the kernel.
> > 
> > We have lots of dual licensed code in the kernel. [...]
> 
> Correct, but that that common case for dual licensing is when it was a 
> work existing outside of Linux, licensed differently - and it's a common 
> courtesy to keep any GPL-compatible licenses when such code goes into 
> the kernel.
> 
> This is a different case though. This is about code which was written 
> within Linux, was licensed under the kernel's license (GPLv2), written 
> and modified by many people - and now it's proposed to be extracted 
> under a new license - which license it never had before.
> 
> > [...] The copy in kernel may well only act as GPLv2 but the copy 
> > outside has other licences (Linus for example relicensed some of his 
> > early locking primitive/atomic bits for the Mozilla folks)
> 
> That's a more clear-cut case: it's for something independent-looking, 
> written from scratch by a single person (Linus) and that person gave the 
> second license. (it's also rather trivial wrappers around atomic 
> instructions and hence most of it might even be not copyrightable)

Yes, and new changes to the code in the kernel would also need written
permission to stay covered under the dual license. There's been a few
times I fixed a bug in some piece of code and later been asked by the
owner of said code if I was OK with my change being dual licensed.
Otherwise they would not be able to use it.

I agree, dual licensing in the kernel can be an administrative pain :-p

One that Mathieu will need to do ;-)

> > > So for those two grounds i cannot give my permission for this 
> > > relicensing, sorry.
> > 
> > One comment here - and one to be careful of for relicensing purposes. 
> > In most parts of the world if you were paid by an employer to produce 
> > the code that the request relates to then the rights to it belong 
> > solely to the employer. Permission (or refusal) from the code author 
> > may well be meaningless because such permission must come from the 
> > employer and right owner in question (so IBM, Red Hat etc) in those 
> > cases and not the author.
> 
> Of course - if performed as hire for work in the US. And there's 
> jurisdictions where work performed outside of work hours might still be 
> the copyright of the author's. (There's even jurisdictions where only 
> natural born persons may have copyright ownership, never corporations.) 
> So it's safest to ask for both. IMHO it's a complex, "ask your lawyer" 
> issue. I am not a lawyer.

True, I did not take into account for those working in Holland, Hungary
or Japan. But I did give the list of people that touched the code to
Legal, so I'm assuming that they did check it out.

-- Steve

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2,headers to Dual BSD/GPL

[Arjan van de Ven]

On Mon, 26 Oct 2009 09:17:49 -0400
Pierre-Marc Fournier <pierre-marc.fournier@polymtl.ca> wrote:

> Ingo Molnar wrote:
> > 
> > But i also disagree with it on a technical level: code duplication
> > is _bad_. Why does the code have to be duplicated in user-space
> > like that? I'd like Linux tracing code to be in the kernel repo.
> > Why isnt this done properly, as part of the kernel project - to
> > make sure it all stays in sync?
> > 
> 
> If you mean that this code should solely be used inside the kernel,
> then what you propose technically does not work. There is a very high
> cost to accessing kernel code from userspace. 

yeah 100 cycles is insanely high, that's at least the equivalent of...
say one cache miss.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2,headers to Dual BSD/GPL

[Mathieu Desnoyers]

* Arjan van de Ven (arjan@infradead.org) wrote:
> On Mon, 26 Oct 2009 09:17:49 -0400
> Pierre-Marc Fournier <pierre-marc.fournier@polymtl.ca> wrote:
> 
> > Ingo Molnar wrote:
> > > 
> > > But i also disagree with it on a technical level: code duplication
> > > is _bad_. Why does the code have to be duplicated in user-space
> > > like that? I'd like Linux tracing code to be in the kernel repo.
> > > Why isnt this done properly, as part of the kernel project - to
> > > make sure it all stays in sync?
> > > 
> > 
> > If you mean that this code should solely be used inside the kernel,
> > then what you propose technically does not work. There is a very high
> > cost to accessing kernel code from userspace. 
> 
> yeah 100 cycles is insanely high, that's at least the equivalent of...
> say one cache miss.
> 

Hi Arjan,

Maybe it's just me, but if you are talking of system calls performed
with sysenter, my own machine (with an Intel Xeon E5405 CPU) seems to
disagree with your estimations:

For a system call doing basically _nothing_:

Cache-cold system call:
Time for a system call (returns after a simple test) :
TSC diff : 6426 cycles
time diff : 3212.53 ns

Cache-hot system call:
Time for system call (10000 calls) (returns after a simple test) :
TSC diff : 599.893 cycles per call
time diff : 299.903 ns per call

Otherwise, if you are instead referring to a vDSO, then the contexts is
slightly different, and it becomes cheaper, but it does not allow to
share code as much between the in-kernel and vDSO implementations,
mainly due to different locking required. Moreover, I wonder about the
maximum vDSO size that can be ported across multiple architectures. It
has only been used for really tiny pieces of code so far.

Thanks,

Mathieu

> 
> -- 
> Arjan van de Ven 	Intel Open Source Technology Centre
> For development, discussion and tips for power savings, 
> visit http://www.lesswatts.org

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2,headers to Dual BSD/GPL

[Mathieu Desnoyers]

* Steven Rostedt (rostedt@goodmis.org) wrote:
> On Mon, 2009-10-26 at 09:17 -0400, Pierre-Marc Fournier wrote:
> > Ingo Molnar wrote:
> > > 
> > > But i also disagree with it on a technical level: code duplication is 
> > > _bad_. Why does the code have to be duplicated in user-space like that? 
> > > I'd like Linux tracing code to be in the kernel repo. Why isnt this done 
> > > properly, as part of the kernel project - to make sure it all stays in 
> > > sync?
> > > 
> > 
> > If you mean that this code should solely be used inside the kernel, then
> > what you propose technically does not work. There is a very high cost to
> > accessing kernel code from userspace. This cost is simply unacceptable
> > for the kind of userspace tracing that is needed today.
> 
> I think that Ingo is thinking that the tracing is for the kernel, and is
> asking why the duplication needs to be done for tools tracing the
> kernel.
> 
> But what I think is trying to be done here is to use the same types of
> MACROS that we have in the kernel to do tracing in userspace. That a
> userspace program can add their own "TRACE_EVENT" and that the headers
> there will create a tracepoint for them the same way we currently do in
> the kernel.
> 
> Am I correct in my analysis?
> 
> -- Steve
> 

Hi Steve,

Yes, you are correct about the intent of making the static
instrumentation macros available to userspace. This is indeed our goal.

What Ingo is trying to propose (I guess) is to perform tracing through
the kernel (e.g. probably through a vDSO or syscall).

However, the licensing question here is for tracepoints, markers,
trace_event, which is a _static instrumentation_ mechanism. In this
case, the kernel cannot really help, because we have to build the
instrumentation into the application anyway, so we run into these
license problems, and it cannot be magically solved by the kernel. Or
maybe Ingo has a different perspective on static instrumentation that
would involve the kernel ? If it's the case, then I'd like to hear it.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2,headers to Dual BSD/GPL

[Ingo Molnar]

* Arjan van de Ven <arjan@infradead.org> wrote:

> On Mon, 26 Oct 2009 09:17:49 -0400
> Pierre-Marc Fournier <pierre-marc.fournier@polymtl.ca> wrote:
> 
> > Ingo Molnar wrote:
> > > 
> > > But i also disagree with it on a technical level: code duplication
> > > is _bad_. Why does the code have to be duplicated in user-space
> > > like that? I'd like Linux tracing code to be in the kernel repo.
> > > Why isnt this done properly, as part of the kernel project - to
> > > make sure it all stays in sync?
> > > 
> > 
> > If you mean that this code should solely be used inside the kernel,
> > then what you propose technically does not work. There is a very high
> > cost to accessing kernel code from userspace. 
> 
> yeah 100 cycles is insanely high, that's at least the equivalent of... 
> say one cache miss.

That too - plus 'being in the kernel repo' does not mean it has to run 
in kernel mode. It could be a vdso feature or a library in tools/. I'm 
quite sure it's a mistake to ad-hoc export the current tracepoint.c code 
to user-space without having it all under the same maintenance envelope.

	Ingo

Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2,headers to Dual BSD/GPL

[Mathieu Desnoyers]

* Ingo Molnar (mingo@elte.hu) wrote:
> 
> * GeunSik Lim <leemgs1@gmail.com> wrote:
> 
> > On Mon, Oct 26, 2009 at 11:08 AM, Zhaolei <zhaolei@cn.fujitsu.com> wrote:
> > > * From: "Wu Fengguang" <fengguang.wu@intel.com>
> > > Subject: Re: Relicensing tracepoints and markers to Dual LGPL v2.1/GPL v2,headers to Dual BSD/GPL
> > >
> > >
> > >> On Sun, Oct 25, 2009 at 05:03:52AM +0800, Jesper Juhl wrote:
> > >>> On Fri, 23 Oct 2009, Mathieu Desnoyers wrote:
> > >>>
> > >>> > (updated email for Jesper Juhl)
> > >>> >
> > >>> > * Mathieu Desnoyers (mathieu.desnoyers@polymtl.ca) wrote:
> > >>> > > Hi,
> > >>> > >
> > >>> > > I would like to re-license the tracepoint.c/marker.c files from GPL to:
> > >>> > >
> > >>> > > * Dual LGPL v2.1/GPL v2 license.
> > >>> > >
> > >>> > > And re-license tracepoint.h/marker.h to:
> > >>> > >
> > >>> > > * Dual BSD/GPL v2 license.
> > >>> > >
> > >>> > > The goal is to allow sharing code between the kernel tracer and UST
> > >>> > > (User-Space Tracer) project, which is a LGPL v2.1 library. Tracepoint
> > >>> > > and marker headers might need to be included by proprietary or BSD
> > >>> > > applications, hence the dual BSD/GPL v2 license for these two.
> > >>> > >
> > >>> > > I currently have the OK from Kosaki Motohiro for Fujitsu contributions,
> > >>> > > which includes Zhao Lei and Lai Jiangshan.
> > >>> > >
> > >>> > > The missing approvals for Dual LGPL v2.1/GPL v2 relicensing are:
> > >>> > >
> > >>> > > For tracepoint.c:
> > >>> > >
> > >>> > > Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
> > >>> > >
> > >>> > > For marker.c:
> > >>> > >
> > >>> > > "Robert P. J. Day" <rpjday@mindspring.com>
> > >>> > > Adrian Bunk <bunk@stusta.de>
> > >>> > > Harvey Harrison <harvey.harrison@gmail.com>
> > >>> >
> > >>> > Jesper Juhl <jj@chaosbits.net>
> > >>> >
> > >>>
> > >>> I don't think I have enough significant changes in there to actually
> > >>> require my approval for relicensing, but since you ask; I personally
> > >>> do not have a problem with that file being Dual LGPL v2.1/GPL v2
> > >>> licensed.
> > >>
> > >> Me too.
> > >>
> > >> Thanks,
> > >> Fengguang
> > >
> > > Me too.
> > >
> > > Thanks,
> > > Zhaolei
> > 
> > Sorry for the late reply. Why do we need a different license to GPLV2
> > sources that  contributors submitted.?  As Mathieu mentioned, I think
> > that  GPLV2 based some sources needs  to be relicense  to  trace
> > non-GPL applications
> > for some developers and some companies.
> > 
> > In real, Some open source  like QT, MySQL is licensed using dual
> > license for business strategy. tracepoint.c/marker.c file is GPLv2
> > currently.
> > 
> > Can  we re-distribute with dual license (e.g: bsd/gplv2 or lgpl
> > 2.1/gplv2)   about some source of linux kernel source? I think that
> > linux kernel source is GPLv2 only. Frankly speaking, I am not know
> > exactly about  legal issues of your questions.
> 
> Yes, the legality of such relicensing is questionable as that code was 
> never developed outside of the kernel but as part of the kernel.
> 
> But i also disagree with it on a technical level: code duplication is 
> _bad_. Why does the code have to be duplicated in user-space like that? 
> I'd like Linux tracing code to be in the kernel repo. Why isnt this done 
> properly, as part of the kernel project - to make sure it all stays in 
> sync?
> 

Hi Ingo,

I would like to know more about what role you think a kernel vDSO can
have in static instrumentation of user-space applications.

Basically, static instrumentation has to be declared in the
application. In the current Ftrace scheme (same for LTTng), probes have
to be specifically built for each instrumentation site (this is the
purpose of TRACE_EVENT). Given this has to be integrated with the
application build/link phases, I do not see the gain in doing static
instrumentation through a vDSO.

Data extraction is a separate topic though, and could possibly benefit
from being done from within the kernel. However, the tracer
implementations for kernel vs user-space contexts will differ due to
locking which has to be done slightly differently in both contexts (e.g.
RCU read-side cannot be used from a vDSO). If we find a way to keep the
difference between the kernel and user-space implementation to a
minimum, which can be expressed using preprocessor macros, maybe it
could be worth it. But in any case, I think it will be useful to
prototype this in a stand-alone userspace library first and get it in
the hand of users ASAP. Then we can compare and decide which is the
optimal technical solution.

Technical aspect aside, I'm concerned about your attitude of blocking
progress of competitive technical solutions through licensing arguments.
It is not really helping global progress here. I'd much prefer to
discuss on a technical ground and not mix that with licensing goo.

Thanks,

Mathieu

> So for those two grounds i cannot give my permission for this 
> relicensing, sorry.
> 
> 	Ingo

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68