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.
>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.
>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.
>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...
If we have to choose, my personal preference would be to be more
restrictive here because we sure aren't very restrictive later!
>Are we *sure* we don't want to throw the whole ball 'o wax into the public
>domain? :-)
I am sure I don't want to be saying we should do that!
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.
If that isn't the goal, then OK. But know the likely
implications before taking that step.
Cheers,
Ben
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
