Dan Sugalski wrote:
>At 07:08 AM 9/26/00 -0400, Ben Tilly wrote:
>>Dan Sugalski wrote:
>>>
>>>On Mon, 25 Sep 2000, Ben Tilly wrote:
>>>
>>> > Is it a conflict with the aims of Perl 6 in general that various
>>> > derivatives of Perl should be licensed under the AL+GPL or GPL?
>>> > (ie Implementations of Perl either are done from scratch or are
>>> > free software.) Until you began talking about your desire to
>>> > see new implementations I had never really wondered at that...
>>>
>>>I'd assumed it would be the way it is now, with the choose your own
>>>license policy. I'd hope that would continue.
>>
>>Either that or a very liberal license. But both licenses that
>>exist now, plus early comments by Tom C, plus my attempted draft
>>all discourage the creation of a proprietary Perl based on the
>>existing code-base.
>>
>>Is that in conflict with the overall direction of the Perl 6
>>effort? To my eyes this is a pretty big decision.
>
>I'm not 100% sure, but I think so. There are a few different scenarios
>here.
Let me state where my draft and the original AL sit on both.
>1) Someone embeds perl in their app, but it's essentially invisible to the
>user. Maybe someone's app is written entirely in perl, or partially in perl
>and partially in something else.
Fine in mine and original AL.
>2) Someone embeds perl in an app to use as the app's scripting language.
>(Imagine StarOffice or Word Perfect with perl as the scripting language
>instead of basic) Perl is not the point, it's just convenient and may match
>well with what needs doing.
Fine in mine but you need to mention it is Perl they are
seeing and say where to get it. Fine in the original version
under item 5 but you must have the complete Standard Version
of Perl installed. Using a mini-perl as a scripting interface
would be a no-no.
>3) Someone embeds perl in an app because they want to provide perl. This
>includes things like mod_perl, for example, or perl embedded in another
>webserver app.
Fine in both but you have to document the change and include
instructions on where to get Perl.
>4) Someone writes a new version of piece X of perl, for example a better
>optimizer or a backend that interfaces into a compiler's back end. (Like
>GCC or Digital's GEM compiler backend) Perl *is* the whole point here.
Not fine in the original AL except by arrangement with Copyright
holders or by giving it back to Perl. In mine you can do this
but you need to re-release under the exact terms that Perl is
released under, and agree to any standard developer agreements.
Or you need to write the replacement components from scratch
without mingling any code from the original version.
In both modifying or replacing versions of Perl itself without
changing the names requires that it be able to be made part of
Perl. (If you change the names of the components you change,
you need to document changes in your source and man pages. All
versions of AL.)
Now there are three solutions that I see. The first is to say
that we want this legal restriction for our protection but make
it easy to replace components of Perl with components with
different names. (Requirement: You may derive versions of Perl
from this but don't conflict with our name.) This is what
happens now with mod_perl, perlex, etc. The second is to say that
we want to allow this and restrict abuse by other means. The
only suggestion on the table now is trademark. The third is to
say that we should state the choice as clearly as we can and put
off a decision.
I am for the third. Which is why I am trying to make it clear
now what the choice is and the consequences that I see.
>5) Perl *is* the only language you can work with on a device.
Fine in both versions.
>Each of these has its own set of licensing issues, and I've listed them
>from least to most visible.
*nod*
>#1 would seem to be the least contentious, and I think we should definitely
>allow it.
Yup.
>#2 is a little dodgier, but I also think we should be all for it. Hell,
>I'd be happy if, because of it, M$ dumped Visual Basic as an embedded
>language for Office and used perl instead. (I think I may be in the tiny
>minority here... :) Regardless, for most of the apps I've had to do
>scripting for, perl'd be a better choice than what's provided.
I have had conversations with people who will use Python for this
because the syntax is easier in their opinions for end users to
pick up. Given the ability to have a different parsing front
end it would be easy to embed Perl for this purpose with a syntax
for the non-Perl programmers or with real Perl for those who want
it. (A group which would include me.:-)
>#3's sort of less contentious than #2. Mod_perl's a keen thing, and it and
>things like it (for example the AS thingie that lets you do the same if
>you've had IIS inflicted on you) are the norm, which folks are used to.
But note that allowing this is why the GPL will not fit the
needs of Perl.
>#4 is the one I'm most concerned with, and odds are the one that'd flip
>people out the most. I *want* to have a perl compiler that spits out highly
>optimized Alpha or Sparc executables. Heck, I'd take mediocre ones (if we
>linked into GCC). This one has two problems. Linking in to the GCC backend
>has GPL issues, and linking in to something commercial like Sun or Digital
>(Sorry, Compaq's) compiler back end has other license issues if they decide
>to distribute the resulting executable.
Ouch.
Well linking into GCC has GPL issues no matter how Perl tries to
disclaim copyrights. Linking into commercial compilers might as
well.
Should an AL type license go forward (my personal preference,
but I am only offering choices here) then I think the GPL
language from section 0 really fits. The output is only
covered if it constitutes a work based on the Package.
Whether this is true depends on what it does.
>#5, oddly enough, is likely to be the one least concerned with the AL,
>since the actual execution engine will probably be custom-written, and just
>take the bytecode the bytecode compiler spits out. Regardless of how we may
>feel about, say, a Furbie's native language being perl (I think it'd be a
>cool thing personally), if they do their own execution engine that takes
>bytecode there's not much we can do except maybe help.
Heh. :-)
>Just to make things even more fun, remember this diagram?
>
>+--------+ +-----------+ +--------+ +-------+
>|Lex/toke|-->|to bytecode|-->|optimize|-->|execute|
>+--------+ +-----------+ +--------+ +-------+
>
>Every place there's an outbound arrow we plan on having a save to disk
>feature, and all the inbound arrows will (hopefully) have a load from disk
>feature. Which means even if we do get really cranky about folks replacing
>the execution engine with their own code, they can completely ignore out
>license by just reading the bytecode off disk, which is pretty much what
>they'd get from the optimizing block there *anyway*.
The GPL language would clearly make the license issues the
same whether or not you go through a save to disk or not. In
fact I think that individual replacement would be fine.
>Given that the license can be so trivially worked around, I'd as soon just
>make it legit so the workaround's not needed.
That is why I am proposing the GPL language. This makes all
paths equivalent.
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.
