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?
>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.
>>>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. :-)
[...]
>>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...?
[...]
>>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...)
>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.
>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.
>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?
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".
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.)
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.
>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...
>
>>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.
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.
>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...
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.
