[ltt-dev] Dual-licensing LTTng, marker and tracepoints under GPLv2+/LGPLv2.1+

[Mathieu Desnoyers]

* Ingo Molnar (mingo at elte.hu) wrote:
> 
> * Mathieu Desnoyers <compudj at 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