This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: New 'as' port: GPL requirements?


John Moran wrote:
> I know GPL-legalese is possibly the dullest thing on the planet, but I
> can't start on this port without a definitive answer, so I'd  appreciate
> some feedback on this...

  Probably you should enquire directly of the FSF, who after all are, by
definition, definitive in matters of GPL interpretation.  However, I think the
answers are fairly straightforward in this particular case:

> Summary: I want to modify an existing GPL-ed program (gas) such that it
> makes calls to proprietary library 'A'. I'm not the copyright holder of
> 'A', and there is no chance that the copyright holder will allow 'A' to
> be GPL'ed. 'A' is linked dynamically at runtime. Question: does the GPL
> allow me to do this 

  ... Up to this point, unambiguously yes.  You can do anything you want with
a GPL'd program and it's all yours ...

>(or, to be precise, does it allow me to distribute
> the modified 'gas')?

  ....  unless you want to distribute it.

  If you want to distribute a binary of a program that is GPL'd, you *must*
provide (or offer to provide) sources.  These *must* be the full and complete
sources and the *exact* same ones from which you built the binary because the
end-users of your application *must* have the ability to rebuild the exact
same thing you have distributed, in order that they can be said to be free to
modify that application that you have distributed, rather than some
other/similar/variant of the application you gave them.

> 1) "What is the difference between 'mere aggregation' and 'combining two
> modules into one program'"
> (http://www.gnu.org/licenses/gpl-faq.html#MereAggregation), and

> The "Mere aggregation" section states:

>> If the modules are included in the same executable file, they are
>> definitely combined in one program. If modules are designed to run
>> linked together in a shared address space, that almost surely means
>> combining them into one program.

> So, for a dynamic call to library A, this points to combination rather
> than aggregation. 

  Absolutely so.  You are definitely under GPL obligation here.

  Just to point you to a case in point: Cygwin is a GPL'd POSIX emulation
layer distributed as a windows DLL.  If you write a program that dynamically
links to the cygwin DLL, your program must be GPL'd.

  (Or available under a 'compatible' open source license, or as a third option
that applies specifically to cygwin, which is copyright of RedHat rather than
the FSF, you can pay RedHat for a non-GPL-licensed version of cygwin, that you
can link your application against without having to distribute the source; but
these are beside the point in this particular case). 

> However, 'linked together in a shared address space'
> is not well-defined, and 'almost surely' is not helpful.

  "Linked together in a shared address space":

a) is *perfectly* well-defined, and
b) is *exactly* what ld.so, LoadLibrary, or any other dynamic runtime linker
does.

"Linking" means resolving address references against symbols.  "Shared address
space" means a single process space - i.e. one set of virtual memory PTEs, as
it might be.

> aggregation anyway. In fact, the idea that making a call from a GPL'ed
> program into a library somehow converts the library into an extension of
> the GPL'ed program seems, to me anyway, to be utterly bizarre.

  It does no such thing.  The status of the library does not change; what
happens is that if you cannot apply the GPL to the library, then you MAY NOT
apply the GPL to the program that calls that library.  If you want to use GPL
code in any program - and then distribute that program - you are obliged to
GPL that program; hence you may not link against any library that you cannot
distribute under the GPL in that program.

  In short, the proprietary library does not change, but you cannot use GPL'd
code in some program that calls that library; you must find a free library
that does the same job, or you must write your own code rather than taking
free GPL'd code to use in the app.

> The
> library is an independent entity that is unrelated to the calling
> program. We've all written code that calls, for example, 'fopen' - does
> that mean that we've all extended 'fopen'?

  No, because there is an exception to the GPL in the case of the system
libraries that come with any given O/S.



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]