On 2015-11-25 15:42, Mel Gorman wrote:
On Wed, Nov 25, 2015 at 02:40:19PM -0500, Geoffrey Thomas wrote:
Hi Mel, Eric, and Jarod,
I'm looking into uploading libhugetlbfs to Debian, and I wanted to
double-check a few files with ambiguous copyright or license notices.
I assume they're all intended to be LGPLv2.1+ like the rest of the
package but they're not labeled as such.
* huge_page_setup_helper.py is labeled just "(c) Red Hat, Inc., 2009,"
but does not have a license statement. Jarod, can this be used under
LGPLv2.1+?
I can't comment on this at all.
* Similarly, oprofile_start.sh just says "oprofile_start.sh (c) Mel
Gorman 2008" with no license statement. Mel, is this also LGPLv2.1+?
It was originally part of a GPL project but I fully intended it to have
the same license as libhugetlbfs when I created the patches. I had the
full rights to relicense it as the primary author.
* A few files (TLBC/*, contrib/tlbmiss_cost.sh, cpupcstat,
oprofile_map_events.pl) are "Licensed under LGPL 2.1 as packaged with
libhugetlbfs." Eric, Mel, I assume that these are intended to be
LGPLv2.1 or any higher version, like the rest of the package?
Same here, the intent was to have the same license as libhugetlbfs
and I'm the principal author. However, I would suggest dropping them
from a package. They were valid at the time of writing but things like
oprofile_map_events.pl were not actively maintained and it would not be
used like that today. tlbmiss_cost.sh might still be valid in some
cases
but modern TLB implementations are notoriously difficult to measure and
I
would not trust the results it produced. If I needed to know the TLB
miss
overhead in cycles these days, I would use different methods.
I will put together a patch that drops them at some point, I don't think
anyone is actually using them.
Less importantly:
* alloc.c and two tests have _just_ a license, not a copyright
statement; I guess they're owned by IBM?
Yes. I was the main author and I was an employee of IBM at the time.
The terms of my contract transferred copyright to IBM.
* There are a few other files without copyright notices, but right now
I'm assuming they're under the LGPL (though it would be great to have
comments on them, or a clear statement in a README). It's the ones
that have a copyright statement and no license that I want to be
particularly sure of.
* For the files that say things like "Copyright (C) 2005-2006 David
Gibson & Adam Litke, IBM Corporation.", do you know if the copyright
is held by the individuals as well as IBM, or just by IBM? I can just
copy these statements verbatim into debian/copyright, but it seems
worth clarifying.
At the time, both of those guys were employees of IBM at the time.
Sorry about the annoyance, but Debian cares about getting this stuff
right (and I think that's a good policy, honestly).
Thanks for double checking and it's not even remotely annoying. I
understand and agree with your concerns.
I can send in a
follow-up patch to add comments to the files that don't have copyright
notices once I get responses; I'd also be okay with a notice in the
README that clearly asserts a license for the entire package, if you'd
prefer that.
If you cc me on the patch then I can explicitly ack the parts I'm
confident
of. However, I do not have merge rights to that library (or at least
I'm
unaware of it if I do). Eric does but I've no idea if he does any
maintenance
work on it any more. I've taken the liberty of cc'ing him on an address
that
should be active just in case he's not reading the email address you
used.
I would be happy to merge such a patch. Until I have a new mailing
list,
please post a pull request on GitHub so anyone that may be watching can
see it.
Thanks for cc'ing my work address, but I do all libhugetlbfs work from
this
address to keep all my libhugetlbfs work separate from my Akamai work.
(By the way, I seem to be unable to subscribe to the librelist, which
is maybe where I should ask this - at least I have gotten no
confirmation email from my subscribe email, and I'm not sure how to
send without first subscribing as described in SubmittingCode.)
I'm actually not subscribed to the libhugetlbfs-devel mailing list at
the
moment so I know nothing about it. When I unsubscribed, it was a hell
hole
of spam. There was very little real traffic once the project was deemed
feature complete for anything people cared about.
Part of the motivation to move to librelist was the lack of spam
filtering
on Sourceforge. Unfortunately, the librelist doesn't seem to keep the
list around, so I am hunting for a new host. I will update the GitHub
repo when I find one.
Also if there's anything you'd like me to be aware of when preparing
the Debian package or to package in a certain way, do let me know.
Nothing in particular other than I would suggest separating the library
and the administrative utilities such as hugeadm into separate
packages.
Thanks Geoffrey.
Thanks for the work Geoffrey.
