[lttng-dev] [rp] [PATCH] Ensure that read-side functions meet 10-line LGPL criterion
josh at joshtriplett.org
Sun Sep 2 17:19:24 EDT 2012
On Sun, Sep 02, 2012 at 09:07:33AM -0700, Paul E. McKenney wrote:
> On Sat, Sep 01, 2012 at 10:13:55PM -0700, Josh Triplett wrote:
> > On Sat, Sep 01, 2012 at 05:59:11PM -0700, Paul E. McKenney wrote:
> > > This commit ensures that all read-side functions meet the 10-line LGPL
> > > criterion that permits them to be expanded directly into non-LGPL code,
> > > without function-call instructions. It also documents this as the intent.
> > >
> > > Signed-off-by: Paul E. McKenney <paulmck at linux.vnet.ibm.com>
> > s/directloy/directly/g in the comments.
> Good catch, fixed.
> > Also, this seems inordinately silly. :)
> > Assuming you don't plan to copy other LGPLed code into this library (or
> > more specifically the header file), you might consider just adding an
> > explicit exception at the top, saying that the inline functions in this
> > file may be assumed to qualify for the relevant clause of the LGPL,
> > regardless of their length. (You'd probably want to limit that
> > exception to only the code in the header, not any other code in the
> > library, so someone couldn't just copy the whole library into the
> > headers.)
> I believe that it is important to allow LGPL code to flow easily between
> these headers and other LGPL projects. This commit represents a trivial
> change, admittedly, but one that could save a large amount of bookkeeping
> and license-compatibility hassle down the road.
Incidentally, LGPLv3 (specifically, clause 3) seems much saner in this
regard: exceeding the ten-line limit doesn't cause any issue other than
needing to include a copy of the license and give notice about the usage
of the library, which you'd have to do anyway when linking to the
Of course, LGPLv3 wouldn't necessarily satisfy your goal of
interoperability with other LGPL (v2.1) projects.
- Josh Triplett
More information about the lttng-dev