Sorry for disappearing for years. Is there anything I can do for you? Best, Da
On Sat, Nov 7, 2015 at 5:16 PM, Olaf Buddenhagen <olafbuddenha...@gmx.net> wrote: > Hi, > >> El 07/11/15 a les 12:11, Robert Millan ha escrit: > >> > Unfortunately I didn't get any reply from Zheng Da. Does someone >> > know if Zheng is using another email address nowadays? > > While we haven't heard from him in years, I was able to dig something up > that seems current: http://www.cs.jhu.edu/~zhengda/ > > The linked GitHub account ( https://github.com/icoming ) has an (empty) > subhurd repository -- so it's definitely the right guy :-) There is an > address there: dzhe...@jhu.edu > > There is pretty recent activity; so it should be up to date I hope. > >> > In case he can't be reached anymore, I traced origin of the >> > intloop() routine > [...] >> > With this we have "Copyright (C) 2009, 2010 Zheng Da", but still no >> > licensing information. > > If you are resonably sure that the code in question was indeed added by > him, not imported, then maybe we don't even need to contact him: he > signed a copyright assignment for the Hurd of course, and I assume it > applies to this code as well -- so the copyright holder is actually the > FSF. > >> > Unfortunately this gets a bit confusing: some parts of the Hurd are >> > GPLv2 and some are GPLv2+. > > It should all be v2+, except for bits imported from Linux and/or DDE. > >> > Then the file Zheng was modifying [1] is imported from DDE/L4 which >> > is GPLv2 [2]. > [...] >> > What should we make of this? It's somewhat relevant as the code will >> > be linked into librumpdev_pci, which in turn will be linked by its >> > final users in the application layer. > > By default we can assume that the added code carries the same licensing > terms as the rest of the file, i.e. GPLv2 only. There certainly should > be no problem getting permission from the FSF to distribute it under v2+ > terms; and considering it's nothing strategic, I'm pretty sure we could > also get a permissive license, if we think this is preferable to match > the rest of librump... > > (I don't know how the code fits together though -- it *might* be > preferable to actually put the Hurd interface part into a library in the > Hurd repository, which is what Antti suggested I think...) > > -antrik- >