Messages in this thread | | | Date | Wed, 24 Jun 2009 10:14:39 -0400 | From | Mathieu Desnoyers <> | Subject | Re: Dual-licensing LTTng, marker and tracepoints under GPLv2+/LGPLv2.1+ |
| |
* 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
| |