This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
The Artistic License Must Be Changed
=head1 VERSION
Maintainer: Bradley M. Kuhn <[EMAIL PROTECTED]>
Date: 12 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 211
Version: 1
Status: Developing
=head1 ABSTRACT
The Artistic License, as it currently stands, is legally ambiguous, and as a
copyright license, it does not appear to legally achieve the goals set forth
in the Preamble. In addition, similar legal ambiguities in the license make
it impossible for the Artistic License to be declared a free software
license with complete certainty. Many open source and free software
organizations (such as OSI and the Debian Developers) that I<have> accepted
the license have done so only with the greatest trepidation. Other
organizations have sadly rejected the license entirely.
Therefore, we must rewrite the Artistic License.
In this RFC, a number of opinions on why the Artistic License is problematic
are stated, and some common arguments from keeping the Artistic License as
is are refuted.
Finally, two separate paths for proceeding with changes to the Artistic
License are proposed.
=head1 DESCRIPTION
=head2 The General Problem with the Artistic License
The Artistic License does currently have some wording ambiguities that make
it difficult for some lawyers to approve of it. In addition, these legal
ambiguities make it impossible to be sure that the Artistic License is
unequivocally a free software license. This has caused problems for various
free software and open source entities who need to ensure clarity in
licenses.
Entities like the Open Source Initiative and Debian Developers (authors of
Debian Free Software Guidelines) have long had some trepidation about
accepting the Artistic License. Some members of these groups only accepted
the Artistic License with severe reservations. In fact, some of these
organizations have seriously considered removing the Artistic License from
their list of approved licenses.
Finally, while some legal departments appear to have accepted the Artistic
License on face value, other lawyers feel that the Artistic License does not
work well as a copyright license.
=head2 Specific Analyses of the Artistic License
This section presents various analyses of the Artistic License that call for
a change in the license. Some of these analyses are new, and some are taken
from historical opinions made by prominent members of our community.
=head3 Bruce Perens
Bruce Perens, while a member of Open Source Initiative (OSI), stated:
"It [the Artistic License] is, in my opinion, a sloppily-worded license, in
that it makes requirements and then gives you loopholes that make it easy to
bypass the requirements.
Section 5 of the Artistic License prohibits sale of the software, yet allows
an aggregate software distribution of more than one program to be sold. So,
if you bundle an Artistic-licensed program with a 5-line hello-world.c, you
can sell the bundle. This feature of the Artistic License was the sole cause
of the "aggregate" loophole in paragraph 1 of the Open Source Definition. As
use of the Artistic License wanes, we are considering removing the
loophole. That would make the Artistic a non-Open-Source license. This isn't
a step we would take lightly, and there will probably be more than a year of
consideration and debate before it happens.
The Artistic License requires you to make modifications free, but then gives
you a loophole (in section 7) that allows you to take modifications private
or even place parts of the Artistic-licensed program in the public domain!"
(Source: F<http://www.perens.com/OSD.html>)
=head3 Free Software Foundation
The Free Software Foundation, who maintain a working definition of a free
software, have not been able to declare the Artistic License as a free
software license, due the ambiguities in the wording. They state:
"We cannot say that this [the Artistic License] is a free software license
because it is too vague; some passages are too clever for their own good,
and their meaning is not clear."
(Source: F<http://www.gnu.org/philosophy/license-list.html>)
=head3 Comments From Lawyers
Comments concerning the current Artistic License are being solicited from
Eben Moglen, a prominent law professor from Columbia University. Comments
from Eben, when available, will be included in future revisions of this RFC.
Other members of the Copyright and Licensing Working Group are encouraged to
get additional opinions from copyright lawyers on the current Artistic
License. Those opinions will be included in future versions of this RFC (or
perhaps an opposing RFC, if these lawyers argue that the Artistic License
needs not be changed).
=head3 Bradley M. Kuhn
I also wrote my own assessment of the problems with the current Artistic
License.
It is clear to me that the Artistic License was intended to be a free
software license. However, there are problems with its wording that leave
many ambiguities about what a redistributor can and cannot do. Some of the
passages have consequences that are not clear. I will attempt to frame at
least some of them.
One problem is the definition of "Reasonable Copying Fee" given in the
license. It is possible the definition means: "You can charge any amount as
copying fee, if people will pay it". If this interpretation is correct,
there is no real legal limit on the fee at all.
However, there is another interpretation that also seems legally valid. The
definition given of "Reasonable Copying Fee" could actually intend to place
a limit on copying fees that prohibits charging enough to make a profit.
So, if some entity were to sell a CD with Artistic-licensed software on it,
that entity might be in violation of the license if they charge even $1 more
than someone in "the computing community at large" thinks they should.
Also, the definition of "Freely Available" is not completely clear, with
regard to the charging of a "handling fee".
For example, if I were to press a CD of an Artistic-Licensed software
program, and offer to give you a copy if you give me one dollar, would that
be permitted or not? Most people would call that charging a fee for the
item, which is prohibited; but if I simply called it a "handling fee", would
that make it permitted?
What if a large computer store wanted to distributed this same CD of
Artistic-License software? Would that be permitted, or prohibited? In
principle, nothing would stop a store from saying they are charging a
"handling fee" for that item, but computer stores are not accustomed to
doing this, and might have trouble reprogramming the cash register to print
"Handling Fee" instead of "Price" for this particular CD.
=head2 What About Simply Contacting the Copyright Holder?
Some have argued that Section (4d) of the Artistic License solves all the
possible problems with the Artistic License, since anyone can contact the
copyright holder for special arrangements. Indeed, even without Section
(4d), it is always the case under copyright law that the copyright holder
has the right to relicense the work at will to anyone as long as the
copyright remains valid. So, some might argue: "Why should we worry about
confusions in the Artistic License, since everyone who gets a copy can just
ask the copyright holder for special permission, and likely the copyright
holder would give it anyway?"
The problem here, I believe, is one of scale. Consider John Q. Hacker, who
got a copy of thirty Artistic-licensed programs (each with a different
copyright holder). He got his copy of these programs on a CD, which he got
from a local user group, who in turn got their first copy from a large
redistributor of free software (such as CheapBytes). CheapBytes got their
copy directly from each author's website.
Now, John Q. Hacker wants to run a side business installing these software
programs for his clients, charging a "copying fee". He does not plan to
modify the software at all, so he must only charge what the license calls a
reasonable copying fee.
He isn't able to justify his fee to the entire computing community at large,
just to his client. So, he's left with section (4d); he has to email each
of the thirty copyright holders, and ask them for permission to do what he
wants. They will likely give it, but it is a lot of work for him to do
that.
Think back though, through all those copies before it got to John. The
local user group had the same problem, and they had to contact the same
thirty copyright holders and ask the same questions, since, as fund-raising
drive, they were charging their members a fee much greater than CheapBytes
charged. CheapBytes, for their part, had to also ask the same questions, so
they could make a profit selling their CDs.
That totals to the same question being asked ninety times. Even if the
answer was "yes" every time, that is still a lot of wasted effort, simply
because some wording of the original license was confusing.
=head2 Dual Licensing and the Artistic License
Some might argue that the Artistic License need not be changed, since, as
Larry has declared, it should only be used as part of a dual licensing
(Larry Wall, 21 August 2000). So, some might argue: "If the Artistic
License is only intended to be used as a dual licensing scheme, what's the
problem?"
The problem is that the authors of the Artistic License (be it this working
group or Larry himself) can probably not reasonably control how the license
will get used. Indeed, consider the fact that many modules on CPAN, and
even some files in the perl5 core are under Artistic-License-only, despite
Larry's encouragements to use the Artistic License I<only> as part of a
dual-license scheme.
I believe that we have a responsibility to make a sound, clear, concise
software license that is easily dubbed free software and open source, and
that does not cause headaches for redistributors. The license should
legally do what it says it does in the Preamble, without loopholes and
without confusing language.
This is important, because many people I<are> seeking a license that
achieves the goals stated in the Preamble of the Artistic License. Sadly,
the current Artistic License simply does not live up to the task. So, it is
worth fixing it, even if the intent is for it to be used in a dual-licensing
scheme.
=head1 IMPLEMENTATION
There are basically two approaches to repairing the problems in the Artistic
License:
=over 8
=item
Assume that the Artistic License correctly represents what is wanted, and
simply fix the minor legal ambiguities and confusing language.
=item
Start from scratch, define what the Artistic License should have in it, and
develop a completely new "Artistic License: The Next Generation" that
corrects the problems.
=back
It is hoped that RFCs that use both approaches are published the Copyright
and Licensing Working Group for Larry's perusal. In either case, opinions
from as many copyright attorneys as possible should be solicited so that we,
as software hackers, don't miss any legal problems that the trained eye can
spot more easily.
=head1 REFERENCES
F<http://www.perens.com/OSD.html>
F<http://www.gnu.org/philosophy/license-list.html>
Larry Wall, Email communication, Message
<[EMAIL PROTECTED]> of 21 August 2000, posted to
[EMAIL PROTECTED]
