GMP's license looks Parrot-compatible
Scott Bronson
Parrot will only link to the GMP library, right? Either static or
shared, doesn't matter.
IN BRIEF
If so, then there's no problem. GMP is licensed under the LGPL, the
same license as libc6. Parrot links to libc6 without any problem,
right? (Though thankfully it doesn't use much of it...)
The only hassle comes if the Parrot project intends to distribute
>statically-linked binaries< that include GMP object code. Even this is
easy to do if you add a few extra downloadable packages to your web site
(see section 6).
And, worst case, see section 14. :)
IN DETAIL
I'm working off the text shown here:
http://www.gnu.org/copyleft/lesser.html
Here's my section-by-section crib... Feel free to skip to the
conclusion. :)
-1: Ignore the preamble. All the important stuff is reiterated in
detail below.
0: Describes who "you" refers to: the person using Parrot+GMP, *not* the
Parrot developers or distributors. "Library" refers to GMP. Because
this is the LGPL, just linking against GMP does not make Parrot a
derivative work. If Parrot were to actually incorporate GMP source
code, of course, it would be a derivative work. In particular, "The act
of running a program using the Library is not restricted, and output
from such a program is covered only if its contents constitute a work
based on the Library" (they don't).
1: This section does not apply since the Parrot distribution presumably
won't contain any actual GMP source code.
2: We're not talking about redistributing a modified copy of the GMP
library, so this section does not apply.
3: Nobody is proposing that Parrot be relicensed solely under the GPL so
this section does not apply.
4: The Parrot project will be distributing source code, not object code,
so this section does not apply.
5: The first paragraph is key: "A program that contains no derivative of
any portion of the Library, but is designed to work with the Library by
being compiled or linked with it, is called a "work that uses the
Library". Such a work, in isolation, is not a derivative work of the
Library, and therefore falls outside the scope of this License."
Parrot, since it contains no GMP code, is defined as a "work that uses
the library." This is even more clear since Parrot bignum support can
be enabled or disabled at compile time: "...[that Parrot is not a
derivative work] is especially significant if the work can be linked
without the Library." Which, as far as I can tell, Parrot can.
6: Since the Parrot project will not be distributing binaries that are
statically linked against GMP, this section doesn't apply. However,
let's talk further about this section...
It specifically says that it's fine to distribute a binary that
dynamically links against GMP. However, statically linking merely
requires accompanying the work with an offer for GMP source code for at
least 3 years (why comply with clause (a) when you can comply with
clause (c)?). As I read it, simply including a URL in the README that
points to a downloadable GMP package on the parrotcode web site totally
satisfies clause C.
The last two paragraphs of section 6 are REALLY unclear. I can't even
tell what the FSF is trying to say. It looks like it only applies if
you're distributing GMP with your executable, either statically or
dynamically linked. I assume they're talking about tools required to
build GMP into Parrot. Since Parrot is entirely open source, all these
tools are made available anyway, so I think that Parrot is automatically
in full compliance. Frankly, though, these paragraphs are so unclear
that I'd want to contact the FSF for clarification...
7: Doesn't apply since Parrot is not re-distributing GMP.
8: Parrot intends to comply with the LGPL, so this section's
requirements are met.
9-13: Worries about patents, local restrictions, future versions of the
LGPL, etc. None of which is really relevant to the discussion at hand.
14: If I'm wrong, and the LGPL truly is incompatible with Parrot then,
in their words: "If you wish to incorporate parts of the Library into
other free programs whose distribution conditions are incompatible with
these, write to the author to ask for permission. For software which is
copyrighted by the Free Software Foundation, write to the Free Software
Foundation; we sometimes make exceptions for this. Our decision will be
guided by the two goals of preserving the free status of all derivatives
of our free software and of promoting the sharing and reuse of software
generally."
I believe that the Parrot project would be very likely to receive such
an exemption if it asked for it.
IN CONCLUSION
GMP source code must be kept out of Parrot's source tree. No problem.
To distribute binaries dynamically linked against GMP, well, go right
ahead. They don't contain any GMP object code, so no problem.
To distribute statically linked binaries, the distributor must also make
the GMP libraries and all tools used to compile them into Parrot
available and notify the end user of this in writing. It would take a
tiny amount of extra effort to distribute statically-linked binaries.
So, I don't see much of a problem in Parrot's using LGPL'd code.
EXAMPLE
Worst case, let's say that some for-profit company wanted to include
Parrot pre-installed on a Zaurus.
Ideally, they dynamically link Parrot against GMP and comply with each
package's separate terms of redistribution.
If, for whatever reason, they need to staticalliy link GMP to Parrot,
then they would have to make the source to GMP and the tools they used
to build it into Parrot available on their web site, and include a link
to them in a README file.
If they could not even comply with this simple requirement, then their
statically-linked Parrot executable cannot contain bignum support (or
must provide it using an alternative library).
Am I missing anything?
- Scott
Ion Alexandru Morega
Scott Bronson wrote:
> ASSUMPTION
>
> Parrot will only link to the GMP library, right? Either static or
> shared, doesn't matter.
It would certainly work that way, but there are advantages in including
the source code:
- We could trim down all the functionality we don't use (if there is
any)
- At first glange, GMP seems to handle its own memory allocation. It
would be much better if we did that ourselves.
- GMP's compilation process is aware of the machine's hardware,
making optimisations accordingly. It should be compiled along with
parrot, for better performance.
Therefore I suggest we talk to the authors or the FSF and ask them to
allow us to include the (modified!) source code.
> I believe that the Parrot project would be very likely to receive such
> an exemption if it asked for it.
Agreed. LGPL is, after all, "lesser" in the sense that it has more
limited protection of the end-user's rights (as opposed to GPL). Parrot
on the other hand is distributed under GPL, which is better. :)
> - Scott
alexm
Scott Bronson
> ... there are advantages in including
> - We could trim down all the functionality we don't use (if there is
> any)
On modern architectures, I don't think that this will actually buy very
much. Shared libraries are mmaped, so only the portions that you use
are actually loaded into memory. And that memory is shared by all
processes linking against GMP. In my estimation, merging GMP into the
Parrot code base only makes sense if you can manage to cut out the vast
majority of GMP code (70% or more?). At first glance, this doesn't look
like an easy task...
On the other hand, on an embedded architecture, saving even 20% would
probably be a win. I'm sure this can be solved if it ever proves to be
a problem. But, for now, why solve problems that haven't been shown to
exist?
> - At first glange, GMP seems to handle its own memory allocation. It
> would be much better if we did that ourselves.
Perhaps this would help...?
http://www.swox.com/gmp/manual/Custom-Allocation.html#Custom%20Allocation
If these hooks don't provide everything that Parrot needs, I expect the
GMP developers would be receptive to a patch.
> - GMP's compilation process is aware of the machine's hardware,
> making optimisations accordingly. It should be compiled along with
> parrot, for better performance.
That's a double-edged sword. GMP's compilation process is complex and
includes a large quantity of platform-specific code. Merging this into
the Parrot tree and then trying to maintain it (and continually merge
new changes) sounds like a headache.
As for performance, given the amount of indirection the Parrot
interpreter already incurs, I'm not sure that calling via shared library
would add much. I ran some performance tests to try to answer this.
You can find the test code in funcptrs-0.2.tar.gz on
http://www.rinspin.com/bronson/code/gcc/
(I posted more detailed results to the gcc list -- they should hit the
archives soon)
I discovered that shared libraries are about 15% slower than
statically-compiled code (30% worst case). And my test calls a trivial
8-instruction function. If the shared library function were to execute
800 instructions (still pretty small), the performance hit would be
about 0.15%. So I doubt that statically linking GMP will offer much of
a speedup. There's an easy way to prove my hypothesis, of course...
> Therefore I suggest we talk to the authors or the FSF and ask them to
> allow us to include the (modified!) source code.
Before doing that, I think it would be prudent to first prove that there
actually exists a problem, and further that the problem can be solved by
merging GMP code into the parrot source tree...
> ... LGPL is, after all, "lesser" in the sense that it has more
> limited protection of the end-user's rights (as opposed to GPL). Parrot
> on the other hand is distributed under GPL, which is better. :)
It's also licensed under the Artistic, which is worse! :)
- Scott
Ion Alexandru Morega
>On Wed, 2004-06-30 at 00:14, Ion Alexandru Morega wrote:
>
>
>>... there are advantages in including
>>the source code:
>>
>> - GMP's compilation process is aware of the machine's hardware,
>>making optimisations accordingly. It should be compiled along with
>>parrot, for better performance.
>>
>>
>
>That's a double-edged sword. GMP's compilation process is complex and
>includes a large quantity of platform-specific code. Merging this into
>the Parrot tree and then trying to maintain it (and continually merge
>new changes) sounds like a headache.
>
>
Yeah, it sure would. Maybe we could include it only in release versions,
not in the CVS tree? Or use an unmodified (easy to update) version of
the source?
One of the things I like about Perl (and Parrot) is that they try to be
as independent as possible from the system's libraries. This includes
any shared libraries already installed. Relying on the presence of GPM
as a shared library seems to break that. And building without it gives
you an incomplete parrot, as bignums are part of the core.
alexm
Dan Sugalski
> ASSUMPTION
>
> Parrot will only link to the GMP library, right? Either static or
> shared, doesn't matter.
> 4: The Parrot project will be distributing source code, not object code,
> so this section does not apply.
Well...
The problem is distributing object or executable code.
For example, ponder the person, group, or company distributing a pre-built
parrot. They've put together a distribution for a platform that doesn't
have a compiler commonly availalble (windows, VMS) or has a better but not
free compiler around (basically all the commecial Unices, as well as
Windows and Linux if you grab the intel compiler) and wants to host that.
Or they've embedded parrot in their application (game, word processor,
whatever) as a scripting engine. Or are just nuts and burned Parrot to a
Gameboy Advance cartridge. Or have compiled their parrot program down to
an executable and want to distribute that.
In all those cases you've got a binary-only distribution, and a valid
one. (In fact, one that we want to encourage) Section 4, by my reading,
means you've got to ship source to the LGPL component.
This is not, in itself, a problem--that's the license, it's a fine
license, and we respect people's licenses. Unfortunately adopting it means
putting what I'd consider an unreasonable onus on the middle-level
people/developers/distributors, and I don't want to do that.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Scott Bronson
> In all those cases you've got a binary-only distribution, and a valid
> one. (In fact, one that we want to encourage) Section 4, by my reading,
> means you've got to ship source to the LGPL component.
Well, "provide source" might be a better way of saying it. There's no
need to ship it with your product. You just need to make it available,
and include a note saying so in your README.
> This is not, in itself, a problem--that's the license, it's a fine
> license, and we respect people's licenses. Unfortunately adopting it means
> putting what I'd consider an unreasonable onus on the middle-level
> people/developers/distributors, and I don't want to do that.
So, if I understand, your worry is not so much about the technical
difficulty of complying with the LGPL (which appears trivial), but more
along lines of the BSD Attribution Clause? (Summary: BSD's requiring
attribution seemed perfectly reasonable at first, but it got out of hand
pretty as the number of BSD-licensed packages grew. Heck, half of some
product manuals were nothing but attributions...) It's true,
distributing Parrot would become onerous if it required you to also
manage the distribution of a number of other LGPLed libraries.
Parrot currently links to glibc even though glibc is LGPLed. This is
OK, though, because Parrot is able to link to alternative versions of
the C library when glibc isn't available. Maybe GMP could be handled in
the same way?
It could link to libgmp when it's available, or link to an alternative,
freer library when it's not. I know of a BSD-licensed bignum library,
but apparently it's nowhere near the quality of GMP. Allowing Parrot to
use either library gives either the performance of GMP or the freedom of
a less restricted library -- distributor's choice.
Hypothetically, in your opinion, would this be a reasonable solution?
- Scott
Leopold Toetsch
> It would certainly work that way, but there are advantages in including
> the source code:
> - We could trim down all the functionality we don't use (if there is
> any)
No. Please not another library (like ICU), which we have to update in
our tree as well. I'd like to just link against it, *if* the library is
selected with Configure.
> - At first glange, GMP seems to handle its own memory allocation. It
> would be much better if we did that ourselves.
The memory allocation is overridable at runtime.
> - GMP's compilation process is aware of the machine's hardware,
> making optimisations accordingly. It should be compiled along with
> parrot, for better performance.
GMP *is* already heavily optimized to take advantage of architecture
features.
> alexm
leo
Andy Dougherty
> No. Please not another library (like ICU), which we have to update in
> our tree as well. I'd like to just link against it, *if* the library is
> selected with Configure.
Agreed. This reminds me of the situation we faced in perl5 with database
libraries. The core language had to support dbmopen(), but what database
library to use? Berkeley DB was a high quality possibility, but it wasn't
ported to a number of architectures where we wanted perl5 to run. It was
(and still is) also being actively maintained and developed, so any
version supplied with a perl source kit would likely end up forking from
the standard distribution.
Many systems had other built-in ndbm or dbm libraries, and gdbm was
another fairly widely-available alternative, but no individual library was
as widely available as we hoped perl5 would be.
Our solution was to guarantee at least a minimal implementation by
including the sdbm library, which we ported and maintained so it would
compile everywhere that perl was built. The remaining options were
supported as extensions.
I suspect a similar approach will be appropriate here.
> GMP *is* already heavily optimized to take advantage of architecture
> features.
Yes, and, as such, probably needs considerable ongoing portability
maintenance, and we don't want to wind up maintaining a forked version. (I
note, for example, that I just tried gmp-4.1.3 on my Solaris 8/SPARC
system, and it failed with assembler errors. I suspect results on at
least some of the more unusual places we hope to run parrot will be
similar.)
> > - At first glange, GMP seems to handle its own memory allocation. It
> > would be much better if we did that ourselves.
>
> The memory allocation is overridable at runtime.
In any case, that's a general problem not specific to GMP. Any interface
to an external library is going to have to deal with that issue.
--
Andy Dougherty doug...@lafayette.edu