On Tuesday, September 26, 2000 12:54 PM, Dan Sugalski [SMTP:[EMAIL PROTECTED]]
wrote:
> At 07:08 AM 9/26/00 -0400, Ben Tilly wrote:
> >Dan Sugalski wrote:
> >>
> >>On Mon, 25 Sep 2000, Ben Tilly wrote:
> >>
> >> > Is it a conflict with the aims of Perl 6 in general that various
> >> > derivatives of Perl should be licensed under the AL+GPL or GPL?
> >> > (ie Implementations of Perl either are done from scratch or are
> >> > free software.) Until you began talking about your desire to
> >> > see new implementations I had never really wondered at that...
> >>
> >>I'd assumed it would be the way it is now, with the choose your own
> >>license policy. I'd hope that would continue.
> >
> >Either that or a very liberal license. But both licenses that
> >exist now, plus early comments by Tom C, plus my attempted draft
> >all discourage the creation of a proprietary Perl based on the
> >existing code-base.
> >
> >Is that in conflict with the overall direction of the Perl 6
> >effort? To my eyes this is a pretty big decision.
>
> I'm not 100% sure, but I think so. There are a few different scenarios here.
>
> 1) Someone embeds perl in their app, but it's essentially invisible to the
> user. Maybe someone's app is written entirely in perl, or partially in perl
> and partially in something else.
This is not perl, and not marketed as perl.
> 2) Someone embeds perl in an app to use as the app's scripting language.
> (Imagine StarOffice or Word Perfect with perl as the scripting language
> instead of basic) Perl is not the point, it's just convenient and may match
> well with what needs doing.
This is not perl, and not marketed as perl.
> 3) Someone embeds perl in an app because they want to provide perl. This
> includes things like mod_perl, for example, or perl embedded in another
> webserver app.
This is not perl, and not marketed as perl.
> 4) Someone writes a new version of piece X of perl, for example a better
> optimizer or a backend that interfaces into a compiler's back end. (Like
> GCC or Digital's GEM compiler backend) Perl *is* the whole point here.
I'm not familiar with this particular issue. However, this is not perl. If it
is not marketed as perl, I personally don't have an issue with it. If it
markets itself as perl itself, then I consider it a violation of conscience.
Perl is on CPAN. Anything else, any variation of it, is not perl, and should
not claim to be perl. If Company X wants to add to Perl, let them put it into a
separate download, or at least _admit_ that this is not a standard perl and is
a variation of it that may have problems (such as a crippled embedding and
extension system). I don't even like the idea because that could cause
fragments, as previously noted, but the alternative is a purposely deceived
community using a crippled perl with a stamp of approval from our licenses.
I thought this discussion was ended yesterday with a "lesser of two evils".
What did I miss out on? I didn't realize we were talking about the same issue.
(Are we?)
I publish a version of perl, which I've called PerlMagic. I don't name it that
because of trying to avoid license issues. Actually, it is, or was during
5.005, the only publically available uncorrupted true core perl available, with
every right to call itself "perl". It wasn't altered from the original. This is
hugely different from taking perl, corrupting it, crippling it, modifying it,
distributing the resulting monstrosity as "perl", and claiming to be 100% pure
perl, and claiming that it's the same as what's on CPAN when any grunt VB
programmer can tell it isn't.
How can you license 1, 2, and 3, and forbid the bad parts of 4? There is
clearly a difference there.
