lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 18 Feb 2009 12:06:08 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Mathieu Desnoyers <compudj@...stal.dyndns.org>
Cc:	linux-kernel@...r.kernel.org, ltt-dev@...ts.casi.polymtl.ca,
	pierre-marc.fournier@...ymtl.ca
Subject: Re: Moving Userspace RCU (urcu) from GPL to LGPL license

On Wed, Feb 18, 2009 at 01:02:32PM -0500, Mathieu Desnoyers wrote:
> Hi Paul,
> 
> I think that it would be good to distribute the userspace rcu work we
> are currently doing (ref. :
> http://lttng.org/cgi-bin/gitweb.cgi?p=userspace-rcu.git) as a
> LGPL library rather than GPL so it can be linked to the userspace part
> of the LTTng tracer. We want to provide this tracer as a LGPL library so
> proprietary applications can link to it and therefore be traceable. The
> only thing is that we cannot put GPL code into a LGPL library.

Ouch!  I only have approval for RCU implementations under GPL.  :-(

One theoretical exception is that GPL covers only distribution.  Of couse,
several have been known to express strong feelings about this exception.
The system-library exception would seem to only cover proprietary
applications that shipped with the platform, so I don't see how it is
generally useful in this case.

So, thoughts about the traced proprietary executables not being
distributed?  Or does the process of tracing them somehow distribute
them in some situations?  If so, can these situations be feasibly
avoided by people tracing proprietary applications.

> The other point is that I use a few low-level primitives from the Linux
> kernel header (e.g. atomic increment for x86, barrier macros). Those are
> simple one-liners, but, still, I wonder about the licensing
> implications. I could simply "rewrite" them, but that would be a shame
> to have a different primitive implementation of those simple primitives
> in userspace and in kernel-space just for a licensing question. I would
> really like to keep the Linux kernel coding-style within this library.
> So the question would be : are those headers, distributed with the Linux
> kernel, distributed under GPL license ? Is there any special clause that
> would permit using their content under LGPL ? If not, would the
> community see such use favorably ?
> 
> Ideas/comments are welcome.

My understanding is that any file in the Linux source tree that does not
contain a specific license is licensed GPLv2-only courtesy of the COPYING
file at the top of the source tree.

Of course, I am not a lawyer, and even if I was, I doubt that I would
be permitted to dispense legal advice...

							Thanx, Paul

> Thanks,
> 
> Mathieu
> 
> 
> -- 
> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ