On Fri, 5 Jan 2001, Bradley M. Kuhn wrote:
> I personally think that the relying on LGPL'ed code is completely
> reasonable. Some will disagree, so we need to come to a consensus on this
> as a community.
There are actually a couple of different mostly-independent issues, but
yes, we'll need to face them seriously fairly early on, I think. (Not just
yet, perhaps, but probably soon.)
1. What are the consequences for those who redistribute software based on
or including perl6? This is a licensing issue that I do not feel
competent to address, and hence won't.
2. How do we handle build/install issues?
a. Do we insist that users install the package first? If so, what do we
do about portability problems? For example, gmp (the GNU multiprecision
arithmetic library that's at issue here) hasn't been ported to VMS (at
least last time I checked) while VMS is a supported platform for perl.
b. Do we package our own version of the differently-licensed software
along with perl6 and add our own portability and bug fixes at the perl6
release schedule almost inevitably resulting in a fork? [I have argued
strongly against doing this with Berkeley DB in perl5, for example, for
just such reasons.]
c. Maybe we can do both -- supply a not-necessarily-particularly-good-
but-at-least-portable version (maybe even in pure perl) with perl6, but
have Configure (or its successor) detect the other package if already
installed and offer to link with that instead. This is effectively what
we do with sdbm/[gno]dbm/db. It is also possibily a possibility with gmp,
since there's the public domain fgmp partial re-implementation (as well as
the existing perl5 pure perl package).
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
