[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: "Clarified" Artistic License



On Sat, Dec 09, 2000 at 01:00:10PM -0600, Chris Lawrence wrote:
> ncftp 3.0.2 comes under something called the "Clarified" Artistic
> License.  It looks DFSG-free, but I'm not certain.  Here's the text:

This looks like a tremendous improvement over the original Artistic
License.  I see nothing that conflicts with the DFSG in either spirit or
detail.

To whom can I address my questions and suggestions below?

What is the license on the text of this license itself?  The GNU GPL
forbids modification of its terms even for application to works which
aren't already covered by it (in other words, a claim of copyright over the
text of the license itself).

> 1. You may make and give away verbatim copies of the source form of the
> Standard Version of this Package without restriction, provided that you
> duplicate all of the original copyright notices and associated disclaimers.

I think "retain" would be more accurate than "duplicate".

> 4. You may distribute the programs of this Package in object code or
> executable form, provided that you do at least ONE of the following:
> 
>     a) distribute a Standard Version of the executables and library files,
>     together with instructions (in the manual page or equivalent) on where
>     to get the Standard Version.
> 
>     b) accompany the distribution with the machine-readable source of
>     the Package with your modifications.
> 
>     c) give non-standard executables non-standard names, and clearly
>     document the differences in manual pages (or equivalent), together
>     with instructions on where to get the Standard Version.
> 
>     d) make other distribution arrangements with the Copyright Holder.
> 
>     e) offer the machine-readable source of the Package, with your
>        modifications, by mail order.

Shouldn't the Standard Version (source) be required to be Freely Available?

> 5. You may charge a distribution fee for any distribution of this Package.
> If you offer support for this Package, you may charge any fee you choose
> for that support.  You may not charge a license fee for the right to use
> this Package itself.  You may distribute this Package in aggregate with
> other (possibly commercial and possibly nonfree) programs as part of a
> larger (possibly commercial and possibly nonfree) software distribution,
> and charge license fees for other parts of that software distribution,
> provided that you do not advertise this Package as a product of your own.
> If the Package includes an interpreter, You may embed this Package's
> interpreter within an executable of yours (by linking); this shall be
> construed as a mere form of aggregation, provided that the complete
> Standard Version of the interpreter is so embedded.

One may not embed a modified version of the interpreter into a proprietary
program?  (I'm not saying one SHOULD be able to, I just want to be clear
that I'm understanding this clause correctly.)  It looks like section 8 may
act as further clarification of this section, perhaps the two should be
combined?

> 6. The scripts and library files supplied as input to or produced as

I would say "Any" instead of "The".  Yes, a really minor point.

> output from the programs of this Package do not automatically fall
> under the copyright of this Package, but belong to whoever generated
> them, and may be sold commercially, and may be aggregated with this
> Package.  If such scripts or library files are aggregated with this
> Package via the so-called "undump" or "unexec" methods of producing a
> binary executable image, then distribution of such an image shall
> neither be construed as a distribution of this Package nor shall it
> fall under the restrictions of Paragraphs 3 and 4, provided that you do
> not represent such an executable image as a Standard Version of this
> Package.

I am concerned that mentioning "undump" and "unexec" is a bit too technical
for a license document.  What you really want to cover is any method of
aggregating the Standard Version with additional material, right?

> 7. C subroutines (or comparably compiled subroutines in other
> languages) supplied by you and linked into this Package in order to
> emulate subroutines and variables of the language defined by this
> Package shall not be considered part of this Package, but are the
> equivalent of input as in Paragraph 6, provided these subroutines do
> not change the language in any way that would cause it to fail the
> regression tests for the language.

I would suggest that "language" be promoted to a defined term; if I
understand the intent of this section correctly, then it isn't just a
programming language specification that you want to protect, but, for
Artistically-Licenses libraries, the API or even ABI itself.

If I misunderstand the intent of this section, and it is designed only to
protect the specification of a programming lanuage per se, I would suggest
that this section be made optional for authors who wish to license
something other than a compiler or interpreter under the Clarified Artistic
License, since it could be confusing and unnecessary.

Regression tests are undefined and not likely to be a familiar topic to
non-computer scientists reading the document.  I would suggest either
defining Regression Tests at the top of the license, or broadening the
language a bit, or simply saying something like "provided these subroutines
or variables do not function in any discernibly different manner when used
in a manner that is syntactically correct with the Standard Version."

This way people get to add to, but not subtract from, the defined
interface.  What is legal perl (for instance) remains legal perl.

> 8. Aggregation of the Standard Version of the Package with a commercial
> distribution is always permitted provided that the use of this Package
> is embedded; that is, when no overt attempt is made to make this Package's
> interfaces visible to the end user of the commercial distribution.
> Such use shall not be construed as a distribution of this Package.

Logically, I think this paragraph belongs with 5.

-- 
G. Branden Robinson             |           Measure with micrometer,
Debian GNU/Linux                |           mark with chalk,
branden@debian.org              |           cut with axe,
http://www.debian.org/~branden/ |           hope like hell.

Attachment: pgphDfiIYTPdP.pgp
Description: PGP signature


Reply to: