| Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
The Artistic License Must Be Changed
Maintainer: Bradley M. Kuhn <bkuhn@ebb.org> Date: 12 Sep 2000 Last Modified: 29 Sep 2000 Mailing List: perl6-licenses@perl.org Number: 211 Version: 2 Status: Frozen
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 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.
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.
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.
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: www.perens.com)
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: www.gnu.org)
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.
Sadly, Eben was not able to find the time to comment on this RFC in time for the 1 October 2000 freezing deadline.
No other comments from other lawyers were submitted; neither for nor against the Artistic License.
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.
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.
Some might argue that the Artistic License need not be changed, since, as Larry has stated that it is really intended for use 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 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 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.
There are basically two approaches to repairing the problems in the Artistic License:
Assume that the Artistic License correctly represents what is wanted, and simply fix the minor legal ambiguities and confusing language.
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.
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.
Larry Wall, Email communication, Message <200008211818.LAA22675@kiev.wall.org> of 21 August 2000, posted to perl5-porters@perl.org.