This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Can it really be ok to map GPL'd code into any old process?
- From: John Gilmore <gnu at toad dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Pedro Alves <palves at redhat dot com>, Jan Kratochvil <jan dot kratochvil at redhat dot com>, gdb at sourceware dot org
- Date: Wed, 18 Apr 2012 13:30:28 -0700
- Subject: Re: Can it really be ok to map GPL'd code into any old process?
- References: <20120330161403.GA17891@host2.jankratochvil.net> <87aa2rjkb8.fsf@fleche.redhat.com> <4F832D5B.9030308@redhat.com> <87d374pzqt.fsf@fleche.redhat.com>
> It seems to me that we must have a licensing issue here.
> Can it really be ok to map GPL'd code into any old process?
I think you can map it without trouble (just as you can mmap a text
file into a process address space, regardless of its copyright). Or
GDB can mmap a propriatary executable into its address space in order
to read its symbols, read or patch its object code, or run it in a
simulator.
The problem, if any, is that you can't *link* GPL code to proprietary
code (except system libraries). FSF took the position (with NeXT)
that you can't even do that dynamically, if your goal is to circumvent
the GPL (which WAS NeXT's goal).
Ultimately it isn't up to FSF to decide what copyright law allows you
to do -- it's the courts that would figure out whether linking or
mmap-ing GPL'd code to proprietary code produces a derived work (and
thus one whose copyright is derived from the copyright on the GPL'd
code). So far I think it's pretty clear that static linking produces
a derived work. I don't think the courts have ruled about dynamic
linking.
John