Dan Sugalski wrote:
>At 04:58 PM 9/22/00 -0400, Ben Tilly wrote:
>>Dan Sugalski wrote:
>>>At 11:01 AM 9/22/00 -0400, Ben Tilly wrote:
>>How many versions can you find of diff, awk, sed, etc?
>Yeah, but isn't that supposed to be a good thing? :)

Only if you don't have to port scripts between them. :-)

>Besides, most of the different versions were written independently, so the
>AL really wouldn't buy us anything that way.

Those programs are much easier to write than Perl was.

>Granted, full PD status would make it far easier for someone to make a
>modified version in ways that aren't a problem currently. I'm still not
>sure it's a bad thing. (Not that I'm arguing against the AL--I'm all for
>Larry getting full ownership of all the code, and except for the clause
>I've got an issue with, the AL you've built seems fine. IANAL, though... :)

If oraperl had been called perl I think that would have been a
very bad thing in the long run.  One thing that Perl is known
for is portability and I think that Larry making it clear that
he wished to be the only one releasing things called "perl" was
a lot of why that came to be.

OTOH I wasn't here for a lot of that history, I wouldn't mind
being corrected publically or privately if my reading of events
after the fact is mistaken.

>>True.  But over the years we have had oraperl, sybperl, perlex,
>>mod_perl and friends.  Plus at least one port to a new OS which
>>caused some debate and took work to integrate.  Vendors do have
>>an incentive to just go their own way.
>So? I know about most of these (I'm not sure which vendor you're being
>oblique about) and I think they were all community mods of one sort or
>another. None were touted as the one true perl, and all would've been OK
>with the AL as you've rewritten. (And as it existed at the time)

Exactly.  However my point is that if Larry had used a BSD style
license or made it public domain, I think that one or more of
those would have been named "perl" to bad effect.

The vendor that I am being oblique about is ActiveState's
"perl.exe".  Issues long past now, but at one time the cause
of bad blood.


Now as for the output issue, can we take a page from the GPL
and not resolve it?  Their language is:

    The act of running the Program is not restricted,
    and the output from the Program is covered only if
    its contents constitute a work based on the Program
    (independent of having been made by running the
    Program).  Whether that is true depends on what the
    Program does.

Does that sound acceptable?

[Big snippity]

>>>Well, it works like this.
>>>Perl the 'interpreter' (or at least core system) will be made up of four
>>>separate parts, like so:
>>>+--------+   +-----------+   +--------+   +-------+
>>>|Lex/toke|-->|to bytecode|-->|optimize|-->|execute|
>>>+--------+   +-----------+   +--------+   +-------+
>>(Question: Can the bytecode keep track of the lex/toke that was
>>used?  Being able to swtich could help in debugging new lex/toke
>>engines, and it would be nice to be able to write a new
>>language by just writing a new lex/toke but still be able to
>>load modules from Perl...)
>I don't see why not.

Let me rephrase that:  "Will it?" :-)

It is a small detail to do it now, but if that information is
not tracked in the bytecode you do not get freedom to play with
that later. :-)

[big snippety again]
>>Hmm...gotta think about that.
>>OK, after two moments here are my initial reactions.
>>1. C does not support introspection, Perl does.  Implementing
>>   your own basically working GCC using GCC takes serious
>>   work.  In Perl it is as easy as "eval".
>True, and the analog breaks down here somewhat. However, it still rears its
>head if eval isn't used.

Note that if GCC supported a language with introspection back
on the implementation of GCC then under the GPL compiled code
would have to be GPLed.  Food for thought.

>>2. With GCC if you want your nifty optimizing backend you have
>>   to put it under the GPL.  Nothing would stop people from
>>   doing that with Perl.  (So what protection did I try to
>>   build in for artistic control in this AL that is not in the
>>   GPL?  Just not lying and not using people's names for
>>   endorsements.  Oh, and the ability to have unspecified other
>>   agreements covering the Original Version.)
>The licensing of the back end's not an issue. It's the licensing of the
>*output* of the backend that's an issue.

I understand that.  However if the output can trivially lead
to a reimplementation of Perl, that is a nontrivial point.

>>3. I don't see the obligations of this license as being very
>>   stringent.  If it covers a few extra things and requires
>>   nothing beyond basic politeness, oh well.
>That the license places any obligations or exercises any level of control
>over the output (the equivalent of the .o file) is a *big* issue. It would
>mean in many cases that back ends not distributed with perl (with
>corresponding AL exemptions) wouldn't be usable in a lot of places.

Why do you say that back-ends distributed with Perl would have
AL exemptions that you couldn't get other ways?  If you read
the license you will see that there is nothing which would stop
a third party from developing their own fork.  If they want to
call it Perl they would have to AL it.  (Then Larry can steal
what he wants back.)

With your nifty optimizing back end as long as they called it
something different (necessary so it could gently co-exist with
Perl) they can do pretty much whatever they want.

>It'd really suck to have a whizbang third-party bytecode optimizer that I
>couldn't actually dump bytecode from at work because it would place all the
>work code I wrote under the AL and the ownership of Larry.

Your original code would not be covered, only the output.  If
the phrase from the GPL were used, then the license on Perl
would have a chance of covering that output whether that license
was GPL, AL, or BSD.  (The obligations that go with the license
would differ of course.)

And the output would only be covered under certain circumstances.
Circumstances which (however that section is phrased) should not
differ between Perl itself and derivatives of Perl.

Oh, and if your work code uses this binary output embedded in
some product, you would have essentially no obligations other
than not to call your product perl, s2p, etc.

>>Good is likely to be in the eye of the beholder...
>No doubt. "Unpalatable to a large section of perl's target audience" would
>be a better phrase, I expect.

Yes.  GPL is fine for a lot of people.  Dual licensing under
the AL is meant to satisfy those who cannot get along with the

>>Perl has lived so far with a license that is complete garbage...
>Not complete, no. In some ways its issues are a good thing, since the holes
>in it allow people to generally do what they want.

I beg to differ in private on how completely...

Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 

Reply via email to