* From: "Wu Fengguang" <[email protected]>
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 ([email protected]) 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 <[email protected]>
>> > >
>> > > For marker.c:
>> > >
>> > > "Robert P. J. Day" <[email protected]>
>> > > Adrian Bunk <[email protected]>
>> > > Harvey Harrison <[email protected]>
>> >
>> > Jesper Juhl <[email protected]>
>> >
>>
>> 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?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Mon, Oct 26, 2009 at 11:08 AM, Zhaolei <[email protected]> wrote:
> * From: "Wu Fengguang" <[email protected]>
> 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 ([email protected]) 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 <[email protected]>
>>> > >
>>> > > For marker.c:
>>> > >
>>> > > "Robert P. J. Day" <[email protected]>
>>> > > Adrian Bunk <[email protected]>
>>> > > Harvey Harrison <[email protected]>
>>> >
>>> > Jesper Juhl <[email protected]>
>>> >
>>>
>>> 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: [email protected]
[email protected] , [email protected]
--
* GeunSik Lim <[email protected]> wrote:
> On Mon, Oct 26, 2009 at 11:08 AM, Zhaolei <[email protected]> wrote:
> > * From: "Wu Fengguang" <[email protected]>
> > 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 ([email protected]) 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 <[email protected]>
> >>> > >
> >>> > > For marker.c:
> >>> > >
> >>> > > "Robert P. J. Day" <[email protected]>
> >>> > > Adrian Bunk <[email protected]>
> >>> > > Harvey Harrison <[email protected]>
> >>> >
> >>> > Jesper Juhl <[email protected]>
> >>> >
> >>>
> >>> 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
On Mon, Oct 26, 2009 at 4:30 PM, Ingo Molnar <[email protected]> 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: [email protected]
[email protected] , [email protected]
> > 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
* Alan Cox <[email protected]> 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
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
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
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
On Mon, 2009-10-26 at 12:31 +0100, Ingo Molnar wrote:
> * Alan Cox <[email protected]> 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
On Mon, 26 Oct 2009 09:17:49 -0400
Pierre-Marc Fournier <[email protected]> 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
* Arjan van de Ven ([email protected]) wrote:
> On Mon, 26 Oct 2009 09:17:49 -0400
> Pierre-Marc Fournier <[email protected]> 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
* Steven Rostedt ([email protected]) 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
* Arjan van de Ven <[email protected]> wrote:
> On Mon, 26 Oct 2009 09:17:49 -0400
> Pierre-Marc Fournier <[email protected]> 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
* Ingo Molnar ([email protected]) wrote:
>
> * GeunSik Lim <[email protected]> wrote:
>
> > On Mon, Oct 26, 2009 at 11:08 AM, Zhaolei <[email protected]> wrote:
> > > * From: "Wu Fengguang" <[email protected]>
> > > 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 ([email protected]) 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 <[email protected]>
> > >>> > >
> > >>> > > For marker.c:
> > >>> > >
> > >>> > > "Robert P. J. Day" <[email protected]>
> > >>> > > Adrian Bunk <[email protected]>
> > >>> > > Harvey Harrison <[email protected]>
> > >>> >
> > >>> > Jesper Juhl <[email protected]>
> > >>> >
> > >>>
> > >>> 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