Dual-licensing LTTng, marker and tracepoints under GPLv2+/LGPLv2.1+

Dual-licensing LTTng, marker and tracepoints under GPLv2+/LGPLv2.1+

[Mathieu Desnoyers]

Hi,

We want to re-license LTTng as

  dual-license GPLv2 (or better)/LGPLv2.1 (or better)

to facilitate code exchange between the GPLv2 LTTng kernel tracer and
LGPLv2.1 userspace LTTng tracing library.  This will also include
kernel/marker.c, include/linux/marker.h, kernel/tracepoint.c and
include/linux/tracepoint.h. For the LTTng tree, everything under the
ltt/ subdirectory is targeted.

I am the main author of most of these files, and I allow such license
change as far as my code is concerned. Additionally, we need the
approval of most people who contributed code to either LTTng, Linux
Kernel Marker and Tracepoints.

Some in ltt/ltt-relay-alloc.c and include/linux/ltt-relay.h is derived
from kernel/relay.c, on which IBM owns the copyright. I would appreciate
if Paul or Bob could have a look into this.

Hopefully with lkml and ltt-dev, I am reaching most people concerned.

Thanks,

Mathieu


* Pierre-Marc Fournier (pierre-marc.fournier@polymtl.ca) wrote:
> Hello Tom and Karim,
>
> I am writing to you because you are mentioned as copyright holders in  
> LTTng files:
>
> ltt-relay-alloc.c
> http://git.kernel.org/?p=linux/kernel/git/compudj/linux-2.6-lttng.git;a=blob;f=ltt/ltt-relay-alloc.c;h=d073163a75e1f85a9833741b4bce58f8ad27b3e5;hb=2.6.30-lttng-0.141
>
> ltt-relay.h
> http://git.kernel.org/?p=linux/kernel/git/compudj/linux-2.6-lttng.git;a=blob;f=include/linux/ltt-relay.h;h=a8c8836d5a86fd18ca3903f803b08a3672ba1ea9;hb=2.6.30-lttng-0.141
>
>
> At Polytechnique, we are making a userspace port of LTTng. In order for  
> this port to be available to as many users as possible, we would need to  
> license it under LGPL 2.1. Therefore, would you give your permission to  
> release the userspace port of the above files under LGPL 2.1?
>
> Userspace port of the files (please do not distribute as this is not yet  
> released):
>
> relay.c
> http://git.dorsal.polymtl.ca/?p=ust.git;a=blob;f=libust/relay.c;h=27794f9e5e2070358d2658b1ab0fa86336d56fc9;hb=c39c72ee5890c7727ae2697f321ba1b3d6c862f5
>
> relay.h
> http://git.dorsal.polymtl.ca/?p=ust.git;a=blob;f=libust/relay.h;h=ba7c1d63aa2d10c35349bf2d86b70e9000228e04;hb=c39c72ee5890c7727ae2697f321ba1b3d6c862f5
>
>
> Another question: would you allow us to license the two first files  
> (ltt-relay-alloc.c and ltt-relay.h) from the kernel tracer as LGPL? This  
>  would ease maintenance, as it would allow to port code from the kernel  
> tracer to the userspace tracer.

Just to make this clearer : We plan to switch to a dual-license scheme
for LTTng (GPLv2 + LGPLv2.1) to facilitate further resynchronization
between the kernel LTTng and userspace library LTTng.

Thanks,

Mathieu

>
> Thanks
>
> pmf


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

Re: Dual-licensing LTTng, marker and tracepoints under GPLv2+/LGPLv2.1+

[Ingo Molnar]

* Mathieu Desnoyers <compudj@krystal.dyndns.org> wrote:

> Hi,
> 
> We want to re-license LTTng as
> 
>   dual-license GPLv2 (or better)/LGPLv2.1 (or better)
> 
> to facilitate code exchange between the GPLv2 LTTng kernel tracer 
> and LGPLv2.1 userspace LTTng tracing library.  This will also 
> include kernel/marker.c, include/linux/marker.h, 
> kernel/tracepoint.c and include/linux/tracepoint.h. For the LTTng 
> tree, everything under the ltt/ subdirectory is targeted.
> 
> I am the main author of most of these files, and I allow such 
> license change as far as my code is concerned. Additionally, we 
> need the approval of most people who contributed code to either 
> LTTng, Linux Kernel Marker and Tracepoints.

Why dont you license the user-space library under the GPLv2?

Also, i dont agree that such interfaces should be ABIs, hence i 
oppose the librarization of such raw kernel interfaces. For example 
markers will be removed in the future, and tracepoints will sure 
undergo more corrective iterations as well.

	Ingo

Re: Dual-licensing LTTng, marker and tracepoints under GPLv2+/LGPLv2.1+

[Mathieu Desnoyers]

* Ingo Molnar (mingo@elte.hu) wrote:
> 
> * Mathieu Desnoyers <compudj@krystal.dyndns.org> wrote:
> 
> > Hi,
> > 
> > We want to re-license LTTng as
> > 
> >   dual-license GPLv2 (or better)/LGPLv2.1 (or better)
> > 
> > to facilitate code exchange between the GPLv2 LTTng kernel tracer 
> > and LGPLv2.1 userspace LTTng tracing library.  This will also 
> > include kernel/marker.c, include/linux/marker.h, 
> > kernel/tracepoint.c and include/linux/tracepoint.h. For the LTTng 
> > tree, everything under the ltt/ subdirectory is targeted.
> > 
> > I am the main author of most of these files, and I allow such 
> > license change as far as my code is concerned. Additionally, we 
> > need the approval of most people who contributed code to either 
> > LTTng, Linux Kernel Marker and Tracepoints.
> 

Hi Ingo,

> Why dont you license the user-space library under the GPLv2?
> 

The goal we pursue by dual-licensing with GPLv2/LGPLv2.1 is to permit
instrumented applications to be themselves distributed under other
license than GPL. We currently have a working userspace tracing library
port of the LTTng tracer. The goal is to permit this library, which
includes the tracepoints, markers and LTTng features, to be used by
userspace applications and libraries so they can add static
instrumentation (as we currently do in the kernel). We already got the
OK from IBM to release the userspace RCU library I've created to support
the userspace LTTng port under LGPL. We have also re-created most of the
low-level primitives we needed under the MIT-style or LGPL license.


> Also, i dont agree that such interfaces should be ABIs, hence i 
> oppose the librarization of such raw kernel interfaces. For example 
> markers will be removed in the future, and tracepoints will sure 
> undergo more corrective iterations as well.
> 
> 	Ingo

There might be some misunderstanding here: the portion of
markers/tracepoints/LTTng added to a userspace library have absolutely
nothing to do with the kernel anymore. Their scope is only the process
they instrument and trace. Therefore this is a different and separate
API provided by a userspace library. I don't see how this can be related
to the kernel ABI.. ?

And we plan to release these first versions of the library by stating
clearly that we reserve all rights to change the interface to match the
Linux kernel modifications. But we have to start somewhere you know. :)

And keeping these libraries under LGPL will ensure that we offer
interfaces that permits to re-link the applications with newer
instrumentation/tracing libraries, so we won't get stucked with
compatibility problems.

Mathieu

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

Re: Dual-licensing LTTng, marker and tracepoints under GPLv2+/LGPLv2.1+

[Frank Ch. Eigler]

Mathieu Desnoyers <compudj@krystal.dyndns.org> writes:

> [...]  The goal we pursue by dual-licensing with GPLv2/LGPLv2.1 is
> to permit instrumented applications to be themselves distributed
> under other license than GPL. [...]

Is there some reason you can't just fork/copy off some earlier version
of these files over which you had sole authorship (if any)?


> [...]The goal is to permit this library, which includes the
> tracepoints, markers and LTTng features, to be used by userspace
> applications and libraries so they can add static instrumentation
> (as we currently do in the kernel). [...]

Just in case you're not aware, some API prior art for this is the
dtrace sdt.h widget (already supported by systemtap), and of course
it has no similarity to the various kernel tracing APIs.

- FChE

Re: Dual-licensing LTTng, marker and tracepoints under GPLv2+/LGPLv2.1+

[Mathieu Desnoyers]

* Frank Ch. Eigler (fche@redhat.com) wrote:
> Mathieu Desnoyers <compudj@krystal.dyndns.org> writes:
> 
> > [...]  The goal we pursue by dual-licensing with GPLv2/LGPLv2.1 is
> > to permit instrumented applications to be themselves distributed
> > under other license than GPL. [...]
> 
> Is there some reason you can't just fork/copy off some earlier version
> of these files over which you had sole authorship (if any)?
> 

Actually, for LTTng, I own the copyright of almost everything we need.
Most files written by others are mainly the debugfs interfaces done by
Fujitsu. There is some derived work from RelayFS in
ltt/ltt-relay-alloc.c and include/linux/ltt-relay.h, where getting IBM's
approval would be good, but I think in the end this will end up being
only a few tens of lines.

> 
> > [...]The goal is to permit this library, which includes the
> > tracepoints, markers and LTTng features, to be used by userspace
> > applications and libraries so they can add static instrumentation
> > (as we currently do in the kernel). [...]
> 
> Just in case you're not aware, some API prior art for this is the
> dtrace sdt.h widget (already supported by systemtap), and of course
> it has no similarity to the various kernel tracing APIs.

Yep, we're aware of this. However, last time I checked, dtrace SDT used
a breakpoint even for their userspace tracing, which has a way too large
performance overhead for our needs.

Moreover, they support only very, very limited typing (0 to 5 u32). In
this respect, tracepoints and markers are much more flexible.

Thanks,

Mathieu

> 
> - FChE
> 

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

Re: Dual-licensing LTTng, marker and tracepoints under GPLv2+/LGPLv2.1+

[Paul E. McKenney]

On Wed, Jun 24, 2009 at 12:49:09PM -0400, Mathieu Desnoyers wrote:
> * Frank Ch. Eigler (fche@redhat.com) wrote:
> > Mathieu Desnoyers <compudj@krystal.dyndns.org> writes:
> > 
> > > [...]  The goal we pursue by dual-licensing with GPLv2/LGPLv2.1 is
> > > to permit instrumented applications to be themselves distributed
> > > under other license than GPL. [...]
> > 
> > Is there some reason you can't just fork/copy off some earlier version
> > of these files over which you had sole authorship (if any)?
> > 
> 
> Actually, for LTTng, I own the copyright of almost everything we need.
> Most files written by others are mainly the debugfs interfaces done by
> Fujitsu. There is some derived work from RelayFS in
> ltt/ltt-relay-alloc.c and include/linux/ltt-relay.h, where getting IBM's
> approval would be good, but I think in the end this will end up being
> only a few tens of lines.

It is going to be a -lot- easier and faster to simply rewrite a few tens
of lines than to get any kind of approval.  ;-)

I cannot reasonably argue that the prior approval for RCU covers tracing,
sad to say.  So unless there is something very special about the few
tens of lines, could you please look at just clean-room rewriting them?

							Thanx, Paul

> > > [...]The goal is to permit this library, which includes the
> > > tracepoints, markers and LTTng features, to be used by userspace
> > > applications and libraries so they can add static instrumentation
> > > (as we currently do in the kernel). [...]
> > 
> > Just in case you're not aware, some API prior art for this is the
> > dtrace sdt.h widget (already supported by systemtap), and of course
> > it has no similarity to the various kernel tracing APIs.
> 
> Yep, we're aware of this. However, last time I checked, dtrace SDT used
> a breakpoint even for their userspace tracing, which has a way too large
> performance overhead for our needs.
> 
> Moreover, they support only very, very limited typing (0 to 5 u32). In
> this respect, tracepoints and markers are much more flexible.
> 
> Thanks,
> 
> Mathieu
> 
> > 
> > - FChE
> > 
> 
> -- 
> Mathieu Desnoyers
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: Dual-licensing LTTng, marker and tracepoints under GPLv2+/LGPLv2.1+

[Mark Wielaard]

Mathieu Desnoyers <compudj <at> krystal.dyndns.org> writes:
> * Frank Ch. Eigler (fche <at> redhat.com) wrote:
> > > [...]The goal is to permit this library, which includes the
> > > tracepoints, markers and LTTng features, to be used by userspace
> > > applications and libraries so they can add static instrumentation
> > > (as we currently do in the kernel). [...]
> > 
> > Just in case you're not aware, some API prior art for this is the
> > dtrace sdt.h widget (already supported by systemtap), and of course
> > it has no similarity to the various kernel tracing APIs.
> 
> Yep, we're aware of this. However, last time I checked, dtrace SDT used
> a breakpoint even for their userspace tracing, which has a way too large
> performance overhead for our needs.

You might want to check again. Although the systemtap sdt.h should be source
compatible with dtrace markers since it provides the same compile time
interfaces/macros (which is how systemtap support java hotspot probing for
example), it isn't tied to any implementation details. The default
implementation inserts a NOP that can be replaced by a breakpoint instruction.
But Stan Cox added variants that can use syscalls/utrace/kprobes which have
different performance overhead tradeoffs
(http://article.gmane.org/gmane.linux.systemtap/12667). This is an
implementation detail though since the source interfaces are the same. Just
recompiling your application and/or libraries against a newer version of the
sdt.h interfaces will automagically provide the different probe types.

Cheers,

Mark