Ben Tilly wrote:
>
>OK, IANAL, nor do I pretend to any amazing expertise. Should
>this hold up legally, I will probably be the most astounded here.
>(I have not even reviewed for typos!) But at least it gives people
>something specific to argue over.
I would have been astounded with good reason. :-)
>I will annotate it later if I get time and energy. For now let
>me note that I would expect this to be used with an including
>statement reserving to Larry Wall the right to release this at
>a later date under a revised AL. Thanks to the dual licensing
>provisions that would say a lot. (At least if I can read my own
>proposed license straight. :-)
Some light annotation follows.
>Feel free to dissect.
That as well.
>
>Cheers,
>Ben
>
>---------------------------------------------------------------
> THE ARTISTIC LICENSE
> VERSION 2, SEPTEMBER 2000
>
> Preamble
>
>The intent of this document is to enable you to use, distribute, modify,
>and borrow from this Package on terms as generous as can be conveniently
>managed without detracting from the ability of the developers of this
>Package to retain a semblance of artistic control over future development
>of this Package. While this license may stand on its own, it is intended
>to be used in a dual-licensing scheme, and may be incompatible with
>other software licenses when used on its own.
>
I do not know if this will be compatible with the GPL, and
thought some statement to that effect would be wise.
>
> Terms and Conditions
>
>1. This License applies to any work containing a notice placed by the
>copyright holder saying it is licensed in whole or in part under the
>terms of this Artistic License. The "Package", below, refers to such a
>work (be it a program, collection of programs, etc) or any derivative
>under Copyright law. The "Standard Version", below, refers to any such
>work which is licensed in its entirety under this Artistic License.
>Each licensee is addressed as "you".
Some rewording may be needed. A lawyer should clarify what
this does or does not apply to.
>2. You may not redistribute or modify except by arrangement with the
>copyright holders. If this Package is a Standard Version then the
>proffered contract attached to this license constitutes an acceptable
>arrangement.
That should be "accepting the proffered contract"...
The structure is a copyright statement that contains an offered
contract. Unlike the GPL I wanted to disambiguate what was and
was not part of the contract.
>3. If this is a Standard Version then you are free to use this Package as
>you see fit. The scripts and library files supplied as input to,
>produced as output from, linked to, or linked from the programs and
>libraries of this Package do not automatically fall under the copyrights
>of this Package, but belong to whomever generated them. If this is not
>a Standard Version then instead no restrictions have been placed on use,
>input, output, or linking by the applicability of this license, but other
>licenses may apply.
In the contract there is additional verbiage about linking to
libraries that redefine the Package and cause it to fail its
regression tests. I don't know whether such language should
be here, or what it would look like.
>4. The names of the contributers to this package may not be used to
>endorse or promote products derived from this software without specific
>prior written permission.
>
>THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
>PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT UNLESS REQUIRED BY LAW OR
>AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER OR CONTRIBUTOR BE LIABLE
>FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
>SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
>INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
>CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
>ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
>THE POSSIBILITY OF SUCH DAMAGE.
>
Both part 4 and the disclaimer were lifted from the BSD license, I
peeked at the GPL, and tinkered to fit. Any lawyer should know
whether more tinkering is needed, but this is all standard
language required by law.
>
> Proffered Contract
> for Distribution, Modification
> and Derivative Works
>
> Preamble
>
>This contract is offered by the copyright holders for your convenience
>should you wish to modify or distribute a Standard Version or some
>derivative of a Standard Version. You are under no obligation to accept
>it, however under Copyright law you will need permission to undertake the
>activities covered.
This begins the contract. Acceptance of the contract must be a
choice, and if it is not then it is not a valid contract.
> Terms and Conditions
>
>1. The definitions in the copyright statement apply to this contract.
>Furthermore "Original Version" shall refer to the Standard Version you
>received that your Package is, is modified from, or derived from. And
>a modification shall be "includable in the Original Version" if it may
>be included free of charge in the Original Version, any derivative of the
>Original Version, or any Standard Version that the Original Version is
>derived from free of charge, without conflicting with any licenses those
>Packages may be under, and without imposing additional licenses or
>restrictions on those Packages.
This is the key to dual licensing. "includable in the Original
Version" is aware of the terms that the Original Version is
licensed under.
After thought I realize that it is necessary that the "any
derivative" condition might need, "any derivative licensed under
the same terms and restrictions as the Original Version". This
detail is very important should the Package follow my suggestion
of including some reserved situation under which a version can
be released under a different license in the future.
Personally I think that it would be a mistake for Perl to be tied
to a new license without such a provision, but the provision is
carries so much power when combined with the existing wording that
there would be no way to guarantee you can keep your end of the
contract.
(Oops.)
>2. The permissions and obligations in this contract only apply to the
>copyrights arising from the Original Version. For instance where this
>contract says "allowed" that means, "We do not restrict." This does not
>rule out the possibility of additional restrictions applying to your
>Package.
A lawyer should look at that. My intent here is to make it clear
that this contract is not intended to restrict derived Packages
from being under radically different licenses. (So long as they
do not conflict with the one right we wish to keep.)
>3. You may apply modifications produced by the copyright holders or
>others so long as they are includable in the Original Version.
Make it simple if you just want to download a bug fix.
>4. You may otherwise modify or derive from your copy of this Package as
>long as you insert a prominent notice in each changed file stating how
>and when you changed that file, and do at least ONE of the following:
This mainly parallels section 3 of the existing license.
> a) Make your modifications includable in the Original Version and
> communicate them to the developers of the Original Version. Either
> directly or by posting them to a public forum known to you to be
> frequented by the developers of the Original Version. Examples of
> public forums you may consider are Usenet, email lists, or web-based
> forums.
After seeing this, I thought about #perl. Chat should not be
allowed?
> b) Reserve the modified version for personal use or use only within
> your corporation or organization.
We don't care unless you can confuse others.
> c) Rename any non-standard executables so the names do not conflict
> with standard executables in the Original Version, and provide a
> separate manual page for each non-standard executable that clearly
> documents how it differs from the Original Version. Furthermore do
> not try to make the non-standard executable available under names
> conflicting with standard executables. (For instance using
> symlinks, shell scripts, etc.)
Try not to muddy the waters and you are fine.
I tightened up the wording quite a bit from the current one.
What brought this to mind is what ActiveState did. To get stuff
to run on Windows they renamed perl to perl.exe which satisfied
this obligation even though you still just typed "perl" to run
it!
> d) Make no overt attempt to make this Package's interfaces visible to
> the end user of your application.
Out of sight, out of mind. I have extra verbiage in 5d), I do
not know if I prefer a shorter or longer version of this.
This is not in the current version, I think it should be. There
is an important detail here I will save for another email.
>5) To distribute you must do at least ONE of the following:
This mainly parallels section 4 of the existing license. I have
added more detailed requirements that should not be onerous.
> a) Have the distributed Package be a Standard Version together with
> instructions (in the manual page or equivalent) on where to get this
> Standard Version and the Original Version on the terms which you
> received it under, and a brief summary of how it differs from the
> Original Version. There is no need to repeat instructions or
> include the summary should this Standard Version be identical to
> the Original Version.
>
> b) Accompany your distribution with machine-readable source of
> the Package with your modifications. The modifications must be
> presented in a way that is includable in the Original Version, and
> you must include instructions (in the manual page or equivalent) on
> where to get the Original Version on the terms which you received
> it under. You must also publically provide, free of charge, those
> instructions and your modifications in a form that is includable in
> the Original Version. Your instructions shall additionally include
> explanations on how to obtain the publically available version.
>
> c) Follow the provisions of 4c), distribute that documentation
> with your distribution, and do not encourage others to make your
> non-standard executables available under names conflicting with the
> standard executables unless they are in a position to do so under
> provisions 4a) or 4b). Additionally you must include instructions
> (in the manual page or equivalent) on where to get the Original
> Version on the terms which you received it under.
>
> d) Have embedded the parts (which could be the whole) of the Original
> Version in your product in such a way that the interfaces to and
> resemblance with the Original Version are not immediately apparent.
> This provision is meant to cover the needs of people who want to
> embed interpreters, link to libraries from this Package, and
> borrow code for other projects.
Added to parallel the new 4c). Which version is better?
Also I wonder if source distributions should include some sort
of requirement to indicate which version this is from, etc. So
a binary may say nothing about Perl, but if you get source you
can track it down...? I am ambivalent about that.
>6) Should you distribute under 5a-c) and the source you indicate for the
>Original Version change or stop distributing it, upon request you must
>promptly find an alternate source of the Original Version or stand ready
>to be that source. Likewise should the distributer of that Original
>Version be distributing under this contract and fail of their
>obligations, you must promptly either locate someone who will discharge
>those obligations or stand ready to discharge them yourself.
There is no provision paralleling this in the current license
and I think there should be. What I am trying to avoid is having
someone release an Original Version with changes, release a
changed version, and then pull the Original 6 weeks later.
This also places an obligation on the distributer to make sure
that their provided instructions work.
However it should not be a significant burden in practice because
everyone should point at http://www.perl.com which can upon
request get past versions out of perforce or CVS or whatever.
>7) You may charge whatever you like for this Package, or the support of
>this package. Additionally you may aggregate this Package with other
>packages of your choice. However you may not advertise the Original
>Version or any Standard Version as a product of your own.
Charge what you like - but if you try to provide something that
conflicts with the Original Version you have to provide your
changes for free in a form that can let someone else duplicate
what you did for free. Given free competition you are not going
to realistically get away with price-gouging.
>8) C subroutines (or comparably compiled subroutines in other
>languages) supplied by you and linked into this Package in order to
>emulate existing parts of this Package (eg for portability) that do not
>cause the Package to fail its regression tests shall not be considered
>part of this Package unless you wish otherwise. However should linking
>them in cause it to fail its regression tests, this shall be counted as a
>modification of the Package.
>
I saw a phrase like this in the current AL, and I think it is an
important point. I don't really know where and how to fit it in
though.
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.
