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.
You don't, after all, find too many people trying to pass themselves off as
Shakespeare or Lewis Caroll... :)
>>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)
>>If we're going to claim this, we need to draw an explicit line between the
>>insides and the outsides of the program. There's likely to be very little
>>difference between the internal and external states in a bunch of places.
>>We really can't claim ownership or license coverage for the bytecode
>>emitted by the bytecode compiler.
>
>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.
>>This also has a number of interesting implications for perl, since the
>>internals are moving to a more modular architecture. This clause, for
>>example, would mean that if someone wrote a module that took the output
>>from the optimizer and spat out Java bytecode without having the optimizer
>>output frozen to disk we would own the output. I don't think we really mean
>>that, nor do I think we really want to draw a stark line between output
>>produced by code provided with the main distribution and output provided by
>>code linked in after the fact.
>
>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|
+--------+ +-----------+ +--------+ +-------+
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.
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)
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.
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.
>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.
It's not something I'll push that strongly, though. It's not that big a deal.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
