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:
>>>Dan Sugalski wrote:
>>>>
>>>>At 06:28 AM 9/22/00 -0400, Ben Tilly wrote:
>>>>> THE ARTISTIC LICENSE
>>>>> VERSION 2, SEPTEMBER 2000
>>>>
>>>>Given how this looks, I'm tempted to put forth the alternative license:
>>>>
>>>>"The contents of this archive, except for packages in the ext/ directory
>>>>explicitly marked otherwise, are placed into the public domain."
>>>>
>>>>But I can see how that might not fly... :)
>>>
>>>Heh. One of my goals was to find a way to state what I thought
>>>was the core feeling of the Artistic License in a sound way.
>>>Saying that you are public domain is fine except that it invites
>>>every variant to call itself perl, which is something Larry went
>>>out of his way to avoid.
>>>
>>>I think that was very, very wise.
>>
>>Perhaps. I'm rather fond of keeping at least some level of control myself,
>>but at this point I just don't think that the possible abuses are worth the
>>hassles that putting reasonable limits takes, nor the restrictions it would
>>possibly place on legit usages.
>
>How many versions can you find of diff, awk, sed, etc?
Yeah, but isn't that supposed to be a good thing? :)
Besides, most of the different versions were written independently, so the
AL really wouldn't buy us anything that way.
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... :)
>>You don't, after all, find too many people trying to pass themselves off as
>>Shakespeare or Lewis Caroll... :)
>
>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)
>>>>There is one clause I have some issues with, and that's this one:
>>>>
>>>>> 1.4) Intermediate states of the programs and libraries in this
>>>>> Package during operation shall fall under the copyrights of
>>>>> this License if that is possible after reviewing all
>>>>> applicable licenses, agreements, and laws. In particular
>>>>> binary images produced using "undump", snapshoting internal
>>>>> byte code, or other methods of taking a snapshot of the state
>>>>> during operation are likely to be derivative works to which
>>>>> this License applies.
>>>>
>>>>The "likely" bit is going to give lawyers fits, but that's a minor problem.
>>>
>>>That can easily be changed to "may". The point is that we
>>>cannot say "will" here.
>>
>>No, but what we can state is that if the resulting dumped data *does*
>>contain things covered by our license then, well, our license holds. :)
>>That leaves it up to the users to separate things. (Though we can give
>>technical solutions to aid in that separation)
>
>Ah. So our data structures are works of art and therefore must
>be covered under our copyrights. :-)
A data structure's not a work of art. (And I've aver broad definition of
Art... :)
I'm not talking about data structures, rather bytecode of perl source we've
written.
>>>I included this provision because of the provision in the current
>>>license restricting the use of undump, etc. It is trivial to
>>>create a binary version of Perl by running a script that does
>>>some pre-processing and then "eval". I presume that the current
>>>AL has its language because of fear of exactly that. (A fear that
>>>I would guess is based on actual incidents?)
>>>
>>>Being explicit, the aim is to make 2.8 cover all trivial ways of
>>>writing versions of "perl" in Perl.
>>
>>I'm not sure we need this, at least not this way. Flat-out saying that an
>>binary that contains things covered by the license is covered by the
>>license should be sufficient.
>
>OK. So 1.3 and 1.4 should be reworked to say that input, output,
>etc is not covered by our copyright unless the output contains
>or is based on our internal data structures. And then since any
>interesting binary has to do that...?
Interesting is irrelevant here. This clause reasonably makes claim on
everything, and that's bad.
Besides, if we have piecewise compilation (and I really, *really* want
that) it's not at all unreasonable for the output to have *no* code that's
ours in it. If all you're using is modules that have been pre-compiled, and
you're generating the equivalent of a dynamically linked bytecode output...
>>>I am not sure I follow the example. If you wrote such a module
>>>then the bytecode it spits out is output, not an internal state.
>>>Or do you mean that the byte-code it spits out is meant to be
>>>a working version of the Perl script? Hmm...
>>
>>
>>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.
>>All four parts will be available in all perl binaries, even if in stub
>>form. Now the bytecode compiler will replace the execute unit with a dump
>>to disk function. The JVM compiler will replace it with a conversion to
>>java bytecode unit.
>>
>>Now, since each part is linked together into a single binary, what the
>>execute unit is handed is internal state, and thus it's covered by section
>>2.8. This also means that any output of that unit is *also* covered by 2.8
>>unless that coverage is explicitly waived.
>
>Well if section 1 wanted to it could explicitly waive that.
>The way 1.3 is written could be argued to do that by
>default if you just write a "dump to different format".
>Not what I intended.
I'd like it to waive that claim, yes. I don't think it's enough, but I
can't quite put my finger on the missing piece yet. (But there's still lots
of mail message left... :)
>>It would mean, for example, that the output of B::Deparse, since it was
>>provided with perl, would be covered by the source's original license if we
>>so chose (and I'd hope we would), but the output of B::BetterDeparse off of
>>CPAN would be covered by the AL, since it was *not* explicitly provided
>>with perl and therefore can't waive the license coverage. (The B:: modules
>>access the internal state that 2.8 covers, and therefore their output falls
>>under the AL unless explicitly waived)
>
>The attempted AL would make it easy to grant exemptions. I am,
>though, not sure we would have any reason to. The main
>requirements boil down to: "Mention that Perl is in if if an
>interface from Perl is obvious, and don't give it the same name
>as some piece of Perl."
>
>I think few will find choosing a new name to be a stringent
>requirement.
That's not the main issue, though. The way the clause is written, if
someone writes a new back end, all the output of that backend would be
covered by the AL as well as possibly considered a derivative work owned by
Larry. One could reasonably consider that a bad thing. :)
Also, it brings up some thorny issues, since it would mean that the output
wouldn't necessarily even be legal as an entity in and of itself. If the
code being compiled was GPL'd, for example, I think the output wouldn't be
usable since it would have to be licensed under the AL instead. Or in
addition to. I'm not sure which, but either way it'd be naughty, and likely
legally impossible.
>>For an alternate example, if this clause was in the license for GCC it
>>would mean the output of GCC's normal backend would be owned by you if its
>>your source, but the output from your nifty optimizing backend would be
>>covered by the GPL since it would have to access state this clause covers.
>
>Does the optimized output of GCC contain GCC's internal state?
It doesn't matter. What matters for this example is that code not provided
with the GCC package (our hypothetical optimizing back end) would be
deriving its output from internal state explicitly covered by the license,
which means the output would then be considered a derivative work also
covered by the license.
>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.
>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.
>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.
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.
>>Yes, it is a rather tricky thing to deal with, and I don't know that
>>there's a good way to deal with it.
>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.
>>>If the goal is to keep artistic control over what a standard
>>>implementation looks like then explicit admission of public
>>>domain will be taken as permission to ship any garbage people
>>>want under the name Perl.
>>
>>Well, not in the US at least. That sort of nonsense would be covered by the
>>fraud statutes. You can't sell someone Shakespeare and ship them plays
>>written by Bacon instead, for example. That they're both PD is irrelevant
>>to the misrepresentation.
>
>No, but if it was public domain then oraperl, perlex, sybperl, etc
>could have all been shipped as "perl", causing great pain to those
>who want to get them to co-exist.
Yeah, but that all shakes out quickly enough, and people aren't entirely
stupid. (Regardless of what I may think when woken up at 2 AM to fix
something someone's profoundly busted :) That sort of thing doesn't hold up
long.
>In fact from the point of view of the people implementing, it
>would be *easier* to not change the name of the executable,
>libraries, etc to not conflict with the original.
True, and that's an issue, certainly. I don't think it's a big enough one
to warrant not doing it, but that's just me. Russ' suggestion of an MIT
style license has its merits, as its even less restrictive than the AL,
while still retaining some of the benefits of having a license in the first
place.
>>It's not something I'll push that strongly, though. It's not that big a deal.
>
>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.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
