UnixLib and the GPL
peter at chocky.org
Tue Jun 8 12:57:00 PDT 2004
In message <5c40f4bb4c.Jo at hobbes.bass-software.com>
John Tytgat <John.Tytgat at aaug.net> wrote:
> In message <40C589C2.8060509 at dsvr.net>
> Nick Burrett <nick at dsvr.net> wrote:
> > In the last 4 years, UnixLib has gained an increasing code base licensed
> > under the GPL (note that this is not the LGPL). The problem is that
> > UnixLib is not a shared library and in effect a user is linking their
> > non-GPL binary application with a GPL application. This therefore
> > affects the distribution terms of the non-GPL binary and potentially
> > forces it to be GPL.
> > [...]
> I don't see it reasonable to replace the GPL code by BSD or other
> licensed code in order to let commercial programs link in UnixLib. At
> least, I personally don't want to put any effort in this.
I didn't get the original of this, unhelpfully, although I did read it
in the archives. I wasn't actually aware that any of UL's code was GPL
(rather than LGPL) - can you point out some examples?
> Where I do want to put some effort in, is to have UnixLib as shared library
> which would create a couple extra fun opportunities. If that really would
> solve your point (IANAL), I think that is a no brainer way-to-go.
The only commerical app I'm aware of that uses Unixlib is Natter. Given
that RISC OS has no shared library system per se, it could be argued
that the LGPL is ok in this circumstance, and certainly I've not seen
any strict point either way that says it's ok or not from GPL
authorities. Anyone who is seriously concerned about this point might
be encourged to do a proper shared library system.
> Slightly related to this, I think it wouldn't be bad if the current
> GCC/UnixLib contributers could agree on a "what's next" agenda. Feedback
> of the GCC/UnixLib users would be appreciated. Personally I would like
> to see the "APCS-32 & 'float' argument" issue resolved and get GCC 3.3
> out. Some work on GCC 3.4 has already been done. I would like to do
> code contributions concerning iconv and multibyte support. Any other items
> we will tackle ? ELF ? Shared libraries ? GCC producing RISC OS modules ?
Well, my main concern currently is making Unixlib work with as much code
as possible, which mainly means compiling it against literally hundreds
of applications. There are still some holes, but there is significant
I would argue that we should not consider a shared library system until
we have proper ELF support. In turn, practical ELF support requires
inclusion of AOF/ALF support in bfd, so we have seamless (in
theory) integration with existing RISC OS binaries.
As for iconv et al - does this really need to be in UL? It is easily
compiled any linked when needed. I've compiled many applications that
use multibyte stuff without issue - the only problem I have currently is
with gettext, which requires a little prodding.
Peter Naulls - peter at chocky.org | http://www.chocky.org/
The RISC OS Browser Issue - http://www.chocky.org/unix/browser.html
More information about the gcc