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. > 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. > (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. > 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. -- Mel Gorman SUSE Labs
