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.
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.
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.
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.
5) Perl *is* the only language you can work with on a device.
Each of these has its own set of licensing issues, and I've listed them
from least to most visible.
#1 would seem to be the least contentious, and I think we should definitely
allow it.
#2 is a little dodgier, but I also think we should be all for it. Hell,
I'd be happy if, because of it, M$ dumped Visual Basic as an embedded
language for Office and used perl instead. (I think I may be in the tiny
minority here... :) Regardless, for most of the apps I've had to do
scripting for, perl'd be a better choice than what's provided.
#3's sort of less contentious than #2. Mod_perl's a keen thing, and it and
things like it (for example the AS thingie that lets you do the same if
you've had IIS inflicted on you) are the norm, which folks are used to.
#4 is the one I'm most concerned with, and odds are the one that'd flip
people out the most. I *want* to have a perl compiler that spits out highly
optimized Alpha or Sparc executables. Heck, I'd take mediocre ones (if we
linked into GCC). This one has two problems. Linking in to the GCC backend
has GPL issues, and linking in to something commercial like Sun or Digital
(Sorry, Compaq's) compiler back end has other license issues if they decide
to distribute the resulting executable.
#5, oddly enough, is likely to be the one least concerned with the AL,
since the actual execution engine will probably be custom-written, and just
take the bytecode the bytecode compiler spits out. Regardless of how we may
feel about, say, a Furbie's native language being perl (I think it'd be a
cool thing personally), if they do their own execution engine that takes
bytecode there's not much we can do except maybe help.
Just to make things even more fun, remember this diagram?
+--------+ +-----------+ +--------+ +-------+
|Lex/toke|-->|to bytecode|-->|optimize|-->|execute|
+--------+ +-----------+ +--------+ +-------+
Every place there's an outbound arrow we plan on having a save to disk
feature, and all the inbound arrows will (hopefully) have a load from disk
feature. Which means even if we do get really cranky about folks replacing
the execution engine with their own code, they can completely ignore out
license by just reading the bytecode off disk, which is pretty much what
they'd get from the optimizing block there *anyway*.
Given that the license can be so trivially worked around, I'd as soon just
make it legit so the workaround's not needed.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
