Re: Hopefully last draft of AL

[Dan Sugalski]

At 07:32 PM 9/24/00 -0400, Ben Tilly wrote:

[Major snippage here]

>>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.
>
>Why do you say that back-ends distributed with Perl would have
>AL exemptions that you couldn't get other ways?  If you read
>the license you will see that there is nothing which would stop
>a third party from developing their own fork.  If they want to
>call it Perl they would have to AL it.  (Then Larry can steal
>what he wants back.)
>
>With your nifty optimizing back end as long as they called it
>something different (necessary so it could gently co-exist with
>Perl) they can do pretty much whatever they want.

Okay, this is the crux of the misunderstanding here. The issue isn't what 
the resulting binary with the new whiz-bang optimizer (or 
perl->JVM/PostScript/C/Haskell/Forth/Visual APL++ translator) linked in is 
called. I don't have a problem with the clauses that say "It ain't pure 
perl, don't call it perl."

The issue is we're explicitly claiming full ownership of perl's internal 
state. Because of that anything that is produced based on that state will 
generally be considered a derivative work, and therefore gets the AL tacked 
on. *That* means that if someone writes a new backend (say to link perl 
into GCC's backend, or one that generates Palm code), the output of the new 
perl binary, *even if it isn't called perl*, is now considered a derivative 
work of perl and therefore covered by the AL.

By the clause I don't like, this is the default behaviour. This means that 
any bytecode produced by any backend (perl or Java) is covered by the AL, 
as well as any C code the p2C backend might generate, or any executables 
the mythic perl2exe generator might make.

I'm *assuming* here that we will put some clause in the license that 
explicitly disclaims any rights over that output over and above any rights 
on the source the bytecode came from had. What I want, ultimately, is for 
that disclaimer to be extended to any variant of perl no matter what the 
name is. The clause in question implicitly prevents that, and that's what I 
don't like.

It's certainly possible I'm misreading the license, and if that's the case 
I'll stop. I don't think it is, though.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Hopefully last draft of AL

[Ben Tilly]

Dan Sugalski wrote:
>
>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:
[...]
>>How many versions can you find of diff, awk, sed, etc?
>
>Yeah, but isn't that supposed to be a good thing? :)

Only if you don't have to port scripts between them. :-)

>Besides, most of the different versions were written independently, so the
>AL really wouldn't buy us anything that way.

Those programs are much easier to write than Perl was.

>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... :)

If oraperl had been called perl I think that would have been a
very bad thing in the long run.  One thing that Perl is known
for is portability and I think that Larry making it clear that
he wished to be the only one releasing things called "perl" was
a lot of why that came to be.

OTOH I wasn't here for a lot of that history, I wouldn't mind
being corrected publically or privately if my reading of events
after the fact is mistaken.

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

Exactly.  However my point is that if Larry had used a BSD style
license or made it public domain, I think that one or more of
those would have been named "perl" to bad effect.

The vendor that I am being oblique about is ActiveState's
"perl.exe".  Issues long past now, but at one time the cause
of bad blood.

---

Now as for the output issue, can we take a page from the GPL
and not resolve it?  Their language is:

The act of running the Program is not restricted,
and the output from the Program is covered only if
its contents constitute a work based on the Program
(independent of having been made by running the
Program).  Whether that is true depends on what the
Program does.

Does that sound acceptable?

[Big snippity]

[...]
>>>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.

Let me rephrase that:  "Will it?" :-)

It is a small detail to do it now, but if that information is
not tracked in the bytecode you do not get freedom to play with
that later. :-)

[big snippety again]
>>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.

Note that if GCC supported a language with introspection back
on the implementation of GCC then under the GPL compiled code
would have to be GPLed.  Food for thought.

>>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.

I understand that.  However if the output can trivially lead
to a reimplementation of Perl, that is a nontrivial point.

>>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
>

Re: Hopefully last draft of AL

[Ben Tilly]

Bradley M. Kuhn wrote:
>
>In general, I think this new license is bit more convoluted then it needs 
>to
>be.  I proposal generally the following measures.  I am editing it up 
>today,
>and I will post a version of my proposal tommorrow.

I am waiting for this before trying to draw up any proposals
for RFCs.

>First, in a couple of different places, it unnecessarily makes restatements
>of what is already true about copyright law anyway.  For example, saying
>"distribution outside your company or organization" isn't actually
>necessary, and is in a way, problematic.  First, "distribution" is already
>defined by copyright law, so we don't have to be that specific---copies 
>made
>inside a single organization aren't distribution.  Plus, what if it is an
>individual who is redistributing the software?  We likely want to cover all
>different types of distribution.

Unnecessary, but meant for people who didn't know that about
copyright law.  You will find a lot of that in the GPL if you
go looking as well.

>As another example, there is no need to say: "To redistribute, modify, or
>derive from the Package you must satisfy all copyright and license
>obligations on it."  That's already true, by nature of the fact that's a
>copyrighted work.

Ditto, see above.

>Second, I think many of the goals can be reached with much simpler
>language. Chris' point is valid; non-lawyers should be able to read this
>license and be able to understand it.

My tendancy is to be verbose..I think having more people put
input would be a good thing.

>I will modify Ben's version, and will post my draft today or tommorrow
>morning.
>
I am looking forward to seeing it.

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.

Re: Hopefully last draft of AL

[Russ Allbery]

Ben Tilly <[EMAIL PROTECTED]> writes:

> I think that you actually can have trademarks on the same name in
> different areas as long as there is no possible confusion...

Correct, at least in the US.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: Hopefully last draft of AL

[Bradley M. Kuhn]

In general, I think this new license is bit more convoluted then it needs to
be.  I proposal generally the following measures.  I am editing it up today,
and I will post a version of my proposal tommorrow.

First, in a couple of different places, it unnecessarily makes restatements
of what is already true about copyright law anyway.  For example, saying
"distribution outside your company or organization" isn't actually
necessary, and is in a way, problematic.  First, "distribution" is already
defined by copyright law, so we don't have to be that specific---copies made
inside a single organization aren't distribution.  Plus, what if it is an
individual who is redistributing the software?  We likely want to cover all
different types of distribution.

As another example, there is no need to say: "To redistribute, modify, or
derive from the Package you must satisfy all copyright and license
obligations on it."  That's already true, by nature of the fact that's a
copyrighted work.

Second, I think many of the goals can be reached with much simpler
language. Chris' point is valid; non-lawyers should be able to read this
license and be able to understand it.

I will modify Ben's version, and will post my draft today or tommorrow
morning.

-- 
Bradley M. Kuhn  -  http://www.ebb.org/bkuhn

 PGP signature

RE: Hopefully last draft of AL

[Ben Tilly]

Garrett Goebel wrote:
>
>From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> > At 05:18 PM 9/22/00 -0500, Garrett Goebel wrote:
[...]
>It doesn't look like Larry'd have a good chance of trademarking "Perl"
>anyways. Then again, I don't know much about trademarks.

I think that you actually can have trademarks on the same name
in different areas as long as there is no possible confusion...

>Current PERL trademarks
>(http://trademarks.uspto.gov/access/search-bool.html):
>
>Name   | Owner
>===
>PERL   | PERL, INC.
>[Camel Logo] w/ Perl   | O'Reilly and Associates
>[Book Logos] w/ Subject| O'Reilly and Associates
>PERLEX | ACTIVESTATE TOOL CORP.
>The PERL DEVELOPER NETWORK | ACTIVESTATE TOOL CORP
>THE PERL CLINIC| ACTIVESTATE TOOL CORP
>VISUALPERL | Activestate Tool Corp.
>PERLCOM| Activestate Tool Corp.
>PERLSCRIPT | ACTIVEWARE INTERNET CORP.
>UNIPERL| Activestate Tool Corp.
>
>Perl, Inc. is a classified under goods and services:
>- CANNED MEATS
>- DATE OF FIRST USE: 1977.02.18
>
>So everything that isn't chopped liver appears to be owned by O'Reilly and
>ActiveState. That appears to be the state of things.

Think chopped liver and a computer language will be confused?
I don't. :-)

> > >Isn't there (or couldn't there be) a "Perl Foundation" to
> > > provide such services?
> >
> > Hey, we could set up an Institute! Yeah, that's the ticket! :)
>
>We could all be institutionalized ;-)
>
>Actually, it looks like O'Reilly and ActiveState are the defacto Perl
>Institute.
>
>If Larry is happy the O'Reilly's integrity and use of the Camel Logo...
>Could we not release Perl into the public domain, and then use the Camel
>Logo to qualify it as the offical "Core Perl" distribution?
>
If Larry is happy, he can probably take out a trademark and
have O'Reilly take care of the details.

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.

RE: Hopefully last draft of AL

[Garrett Goebel]

From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> At 05:18 PM 9/22/00 -0500, Garrett Goebel wrote:
> > From: Ben Tilly [mailto:[EMAIL PROTECTED]]
> > > Garrett Goebel wrote:
> > > >
> > > > Can't a trademark be used to protect "Perl", even if the
> > > > code is in the public domain?
> > >
> > > Yes..if someone is ready to actively defend it.  Can you picture
> > > Larry sending a ton of "cease and desist" letters over every
> > > little trivial infringement?  It is that or lose it...

It doesn't look like Larry'd have a good chance of trademarking "Perl"
anyways. Then again, I don't know much about trademarks.

Current PERL trademarks
(http://trademarks.uspto.gov/access/search-bool.html):

Name   | Owner
===
PERL   | PERL, INC.
[Camel Logo] w/ Perl   | O'Reilly and Associates
[Book Logos] w/ Subject| O'Reilly and Associates 
PERLEX | ACTIVESTATE TOOL CORP.
The PERL DEVELOPER NETWORK | ACTIVESTATE TOOL CORP
THE PERL CLINIC| ACTIVESTATE TOOL CORP
VISUALPERL | Activestate Tool Corp.
PERLCOM| Activestate Tool Corp.
PERLSCRIPT | ACTIVEWARE INTERNET CORP.
UNIPERL| Activestate Tool Corp.

Perl, Inc. is a classified under goods and services:
- CANNED MEATS
- DATE OF FIRST USE: 1977.02.18

So everything that isn't chopped liver appears to be owned by O'Reilly and
ActiveState. That appears to be the state of things.

> >Isn't there (or couldn't there be) a "Perl Foundation" to 
> > provide such services?
> 
> Hey, we could set up an Institute! Yeah, that's the ticket! :)

We could all be institutionalized ;-)

Actually, it looks like O'Reilly and ActiveState are the defacto Perl
Institute.

If Larry is happy the O'Reilly's integrity and use of the Camel Logo...
Could we not release Perl into the public domain, and then use the Camel
Logo to qualify it as the offical "Core Perl" distribution?

Garrett

RE: Hopefully last draft of AL

[Dan Sugalski]

At 05:18 PM 9/22/00 -0500, Garrett Goebel wrote:
>From: Ben Tilly [mailto:[EMAIL PROTECTED]]
> >
> > Garrett Goebel wrote:
> > >
> > > Can't a trademark be used to protect "Perl", even if the
> > > code is in the public domain?
> >
> > Yes..if someone is ready to actively defend it.  Can you picture
> > Larry sending a ton of "cease and desist" letters over every
> > little trivial infringement?  It is that or lose it...
>
>Isn't there (or couldn't there be) a "Perl Foundation" to provide such
>services?

Hey, we could set up an Institute! Yeah, that's the ticket! :)

This is a place to Just Not Go, generally speaking.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Hopefully last draft of AL

[Dan Sugalski]

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 equivalen

RE: Hopefully last draft of AL

[Garrett Goebel]

From: Ben Tilly [mailto:[EMAIL PROTECTED]]
> 
> Garrett Goebel wrote:
> >
> > Can't a trademark be used to protect "Perl", even if the 
> > code is in the public domain?
> 
> Yes..if someone is ready to actively defend it.  Can you picture
> Larry sending a ton of "cease and desist" letters over every
> little trivial infringement?  It is that or lose it...

Isn't there (or couldn't there be) a "Perl Foundation" to provide such
services?

Garrett

Re: Hopefully last draft of AL

[Russ Allbery]

Garrett Goebel <[EMAIL PROTECTED]> writes:

> Can't a trademark be used to protect "Perl", even if the code is in the
> public domain?

Probably.  It definitely can still be used in that fashion if Perl were
released under an MIT-style license, which I'd recommend over public
domain, since that's what MIT has done with Kerberos.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: Hopefully last draft of AL

[Ben Tilly]

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 writ

RE: Hopefully last draft of AL

[Ben Tilly]

Garrett Goebel wrote:
>
>From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> >
> > >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... :)
>
>Can't a trademark be used to protect "Perl", even if the code is in the
>public domain?

Yes..if someone is ready to actively defend it.  Can you picture
Larry sending a ton of "cease and desist" letters over every
little trivial infringement?  It is that or lose it...

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.

RE: Hopefully last draft of AL

[Charles Lane]

Dan Sugalski <[EMAIL PROTECTED]> wrote:
>At 02:29 PM 9/22/00 -0500, Garrett Goebel wrote:
>
>>Can't a trademark be used to protect "Perl", even if the code is in the
>>public domain?
>
>Dunno. Probably, but I'm not a lawyer, and that might be taking things to
>places we'd rather not go.

IANAL either, but yes you can.

A quick check on http://www.uspto.gov/web/menu/tm.html shows a bunch
of "Perl" variants registered (incl Perl-win32)...but there's only two
simple "Perl"s, and those are both for some meat product. (Perls of swine?)

Registration might well be a good idea; someone needs to come up with
the ~$1k it takes to register, but it does help deal with the problem
of someone labelling a variant as Perl when it doesn't have Larry's
seal of approval.
--
 Drexel University   \V--Chuck Lane
==]-->*<---[===
 (215) 895-1545 _/ \  Particle Physics
FAX: (215) 895-5934 /\ /~~~[EMAIL PROTECTED]

RE: Hopefully last draft of AL

[Dan Sugalski]

At 02:29 PM 9/22/00 -0500, Garrett Goebel wrote:
>From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> >
> > >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... :)
>
>Can't a trademark be used to protect "Perl", even if the code is in the
>public domain?

Dunno. Probably, but I'm not a lawyer, and that might be taking things to 
places we'd rather not go.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

RE: Hopefully last draft of AL

[Garrett Goebel]

From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> 
> >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... :)

Can't a trademark be used to protect "Perl", even if the code is in the
public domain?

Garrett

Re: Hopefully last draft of AL

[Dan Sugalski]

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 b

Re: Hopefully last draft of AL

[Chris Nandor]

At 11:33 -0400 2000.09.22, Ben Tilly wrote:
>Please see the offered translation.

I did.


>And if still you don't like the way that this layperson wrote
>it, then come up with your own draft that says what you want
>and sounds like what you want.  In case you didn't notice,

No.


>putting together a decent draft is a fair amount of work, and
>to date I have found your input to be extremely unhelpful.

Well, I've found your drafts uninteresting, so I guess we are even.

-- 
Chris Nandor  [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/

Re: Hopefully last draft of AL

[Ben Tilly]

Chris Nandor wrote:
>
>At 11:01 -0400 2000.09.22, Ben Tilly wrote:
> >Dan Sugalski wrote:
[...]
> >>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.
>
>The problem is that the point of having a layperson write it is so that we
>can have it in plain English.  If we are going to resort to legalese, we
>might as well let a lawyer write it, so it actually IS sound.

Please see the offered translation.

And if still you don't like the way that this layperson wrote
it, then come up with your own draft that says what you want
and sounds like what you want.  In case you didn't notice,
putting together a decent draft is a fair amount of work, and
to date I have found your input to be extremely unhelpful.

Regards,
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.

Re: Hopefully last draft of AL

[Chris Nandor]

At 11:01 -0400 2000.09.22, 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.

The problem is that the point of having a layperson write it is so that we
can have it in plain English.  If we are going to resort to legalese, we
might as well let a lawyer write it, so it actually IS sound.

-- 
Chris Nandor  [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/

Re: Hopefully last draft of AL

[Ben Tilly]

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.

Re: Hopefully last draft of AL

[Dan Sugalski]

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... :)

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. 
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.

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.

Are we *sure* we don't want to throw the whole ball 'o wax into the public 
domain? :-)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Hopefully last draft of AL

[Ben Tilly]

Ben Tilly wrote:
>OK, here is what I hope is the last draft of the AL before I
>send out an RFC.  I will send humorous commentary around
>shortly.

OK, here is the "translation" as well.  If people like it my
goal is to make the structure of the legalese a little easier.

One comment I have received is that there are a lot of
don'ts.  Well there is a simple reason.  You know how a good
firewall that wants to deny everything spends its time saying
what it will accept?  I am doing the same thing, only in
reverse.  The fact that the original did not is why it missed
things Larry wanted to allow and is the cause of some of its
problems.

Cheers,
Ben

>THE ARTISTIC LICENSE

 THE ARTISTIC LICENCE

>VERSION 2,  SEPTEMBER 2000

  (Yeah, we tried to say this before)
>
> Preamble

   The Short Version
>   The intent of this License is to state terms 
>under which the
>developers of a free software project may allow use and borrowing
>from the project while retaining a semblance of artistic control
>over future development.  This license may be used on its own
>but is intended to be used in a dual-licensing scheme and is
>incompatible with other widely used free software licenses when
>used outside of a dual-licensing arrangement.

These are the rules to, "We will share if you don't screw us."
We probably are playing, "Let's all be nice" as well, but this
isn't where we tell you that.

>1) What is covered.

1) The scope.

>   1.1) This License applies to any work or derivative from a work
> or collection of works containing a notice placed by the
> copyright holder or holders licensing it in whole or in part
> under the terms of this Artistic License.  The "Package"
> refers to some package which this license applies to.  A
> "Standard Version" is any such work which falls entirely
> under this Artistic License.  Each licensee is addressed as
> "you".

  1.1) If we say its ours and the government agrees, it's ours.
The "Package" has some of our stuff.  A "Standard Version"
would be totally ours.  And Bubba, you're you.

>   1.2) To redistribute, modify, or derive from the Package you
> must satisfy all copyright and license obligations on it.
> The proposed agreement contained in section 2 of this
> license may be used to satisfy any and all copyrights on
> the Package which have been placed under this License.

  1.2) The Feds say you gotta listen to us before copying,
changing, or borrowing from our stuff.  But section 2 tells
you how to get us to play nice.

>   1.3) The copyrights placed under this License in no way
> restrict your use of the Package.  Similarly programs,
> libraries, files and the like used as input, output, or
> linked to the programs and libraries of the Package remain
> the property of whoever produced them unless required
> otherwise by applicable laws and agreements.

  1.3) If we didn't do it, we don't want to claim it unless
the Feds say we gotta.

>   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", saving 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.

  1.4) The running state of our stuff is ours unless the Feds
disagree.  That includes "undump", dumping byte code, or any
other snapshot technique you think of.

>
>2) This section is an agreement offered by the copyright holders
>   for the convenience of those wishing to distribute, modify, and
>   create derivative works.  You are under no obligation to accept
>   the terms presented here, however the activities covered are
>   otherwise prevented by law.

2) Here is how to get us to play nice.  You don't have to get us
  to play nice, but we got the Feds on our side.

>   2.1) The definitions in section 1.1) apply to this agreement.
> In addition "Original Version" shall refer to a Standard
> Version that the Package is modified or derived from.  You
> may choose which Standard Version is the Original Version,
> but you may only choose the Package itself if no previous
> candidates exist.  "Licensed Section" refers to any and all
> files or portions of files in the Package that fall under
> copyrights arising from the Original Version.  And a
> modification shall be called "includable in the Original
> Version" if it may be applied to any Standard Version
> within the existing terms of development for the Original
> Version.  Specifically it must be able to be freely licensed
> under all licenses