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

[Mathieu Desnoyers]

* Ingo Molnar (mingo@xxxxxxx) wrote:
> 
> * GeunSik Lim <leemgs1@xxxxxxxxx> wrote:
> 
> > On Mon, Oct 26, 2009 at 11:08 AM, Zhaolei <zhaolei@xxxxxxxxxxxxxx> wrote:
> > > * From: "Wu Fengguang" <fengguang.wu@xxxxxxxxx>
> > > 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@xxxxxxxxxx) 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@xxxxxxxxx>
> > >>> > >
> > >>> > > For marker.c:
> > >>> > >
> > >>> > > "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx>
> > >>> > > Adrian Bunk <bunk@xxxxxxxxx>
> > >>> > > Harvey Harrison <harvey.harrison@xxxxxxxxx>
> > >>> >
> > >>> > Jesper Juhl <jj@xxxxxxxxxxxxx>
> > >>> >
> > >>>
> > >>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/