The Artistic (or Perl Artistic) License is named because of its stated intention to allow the initial developer to maintain "artistic" control over the licensed software and derivative works created from it. The Perl License is substantially identical to the Artistic License, but it includes an additional paragraph, which provides another option for commercial distribution.
Developed by Larry Wall in the late 1980s, Perl is a ubiquitous programming language, based on C (among other languages) and is found frequently in UNIX and UNIX-based systems. It is omnipresent on the World Wide Web, with thousands, if not millions, of web sites running combinations of Perl scripts over Apache web servers. Part of Perl's strength as a language is its ability to tie together different programs and languages that were not initially intended to work together.
Because of Perl's ubiquity and because Perl is licensed under both the Artistic License and the GPL, programmers and users are as likely to come across the Perl License as any other open source or free software license except the GPL, BSD, or LGPL. The core, the standard Perl libraries, the optional modules, and the documentation that make up Perl were initiated by Larry Wall but have involved the contributions of thousands of people, making Perl one of the most successful open source projects to date.
Unfortunately, the Artistic License is notoriously vague and confusing. This description and commentary will, hopefully, dispel at least some of that confusion.
Like the MPL and the QPL already discussed, the Artistic License was designed for use in connection with a particular program—Perl—and not as a generally applicable license, like the BSD or MIT Licenses, or the GPL, although it certainly could be used apart from Perl. (The Artistic License is frequently used for Perl modules, including many of those on the Comprehensive Perl Archive Network at http://cpan.org.)
The first section of the Artistic License is its preamble.
The Artistic License
August 15, 1997
The intent of this document is to state the conditions under which a Package may be copied, such that the Copyright Holder maintains some semblance of artistic control over the development of the package, while giving the users of the package the right to use and distribute the Package in a more-or-less customary fashion, plus the right to make reasonable modifications.
The Artistic License was designed in substantial part to allow Larry Wall and his group to maintain control over the Perl project, while encouraging both participation in the project and innovation outside the project.
Like the MPL, the Artistic License begins with a list of definitions.
"Package" refers to the collection of files distributed by the Copyright Holder, and derivatives of that collection of files created through textual modification.
"Package" is used in place of "Software" or "Covered Code" or "Program," but it means the same thing: the code originally issued under the applicable license and its modifications and derivative works.
This refers to the unmodified, original version of the code and to the versions modified following certain restrictions identified by the Copyright Holder. Like the initial developer in the MPL and QPL, the Copyright Holder retains certain additional rights above those of other contributors or users of the code.
As already noted, the Copyright Holder retains certain additional privileges with regards to the Package.
"You" is everybody other than the Copyright Holder.
"Reasonable copying fee" is whatever you can justify on the basis of media cost, duplication charges, time of people involved, and so on. (You will not be required to justify it to the Copyright Holder, but only to the computing community at large as a market that must bear the fee.)
This term adds nothing to the license. As the definition itself notes, the licensee is permitted to charge only "market price"—i.e., whatever the market will bear. As noted in Chapter 1, however, the fact that any distributee can freely distribute source and executable code tends to keep such fees low, at least for software in which the market has some interest.
As used in the license, this definition embodies the generational limitation of the Artistic License. Code that is "freely available" can be distributed under the same terms that the unmodified code was received—i.e., under the terms of the Artistic License.
Section 1 of the license provides for distribution of the source code of the Standard Version of the Package, as long as the license is distributed with it.
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.
Section 2 in substance permits the user to "update" a given version of the Package so as to incorporate code that is part of the Standard Version.
2. You may apply bug fixes, portability fixes and other modifications derived from the Public Domain or from the Copyright Holder. A Package modified in such a way shall still be considered the Standard Version.
The question of modifications from the "Public Domain" is somewhat unclear. As written, it means that any bug fixes, portability fixes, or other modifications to the Package—as to which copyright and other intellectual property rights either have been expressly disavowed or have lapsed through the passage of time—may be incorporated and the code will still be considered the Standard Version. This introduces a substantial element of uncertainty into what "Standard Version" means. Any one of many different programs (depending on what fixes or modifications have been applied) can equally be described as the Standard Version.
Section 2 does protect the Standard Version against the encroachment of copyright claims of persons other than the Copyright Holder; the Copyright Holder at least can feel confident that the Standard Version (assuming that all users and contributors adhere to the terms of the license) does not contain any code that the Copyright Holder does not have the power to modify, relicense, or distribute.
Section 3 addresses modifications that are not part of the Standard Version. Such modifications must be clearly marked, and, in addition, the modifier must take additional steps if the modifications are distributed outside the modifier's own use or that of his organization.
3. You may otherwise modify your copy of this Package in any way, provided that you insert a prominent notice in each changed file stating how and when you changed that file, and provided that you do at least ONE of the following:
Clear notification of the fact that this version has changed is a precondition for any modification of the licensed work. In addition, the modifier must conform to one of the following options:
a. place your modifications in the Public Domain or otherwise make them Freely Available, such as by posting said modifications to Usenet or an equivalent medium, or placing the modifications on a major archive site such as ftp.uu.net, or by allowing the Copyright Holder to include your modifications in the Standard Version of the Package.
This is somewhat confusing. The first "sub-option," placing the modifications in the public domain, should not be difficult. The modifier would simply be required to make the modifications publicly available and to place a notice on them that no copyright or other forms of intellectual property rights will be enforced with regards to that work.[4]
The second "sub-option" presents substantially more difficulties. "[O]therwise making [the modifications] Freely Available" would seem to require complying with the definition of "Freely Available" given earlier, requiring that the item itself be given without charge and that the persons receiving it have the right both to use the modifications and to redistribute them on terms no more restrictive than those under which they themselves received the work. Complying with these requirements would not be particularly difficult: a contributor could license the modifications under, for example, the BSD or MIT Licenses described earlier, and put them in a publicly available place for download without charge, other than for the costs of transmission or copying. In such an event, the original work, the Standard Version, would still be licensed under the Artistic License, even though the modifications would be under another license that fell within the definition of "Freely Available."
While this course of action would be in compliance with the requirement of this "sub-option," it is not clear that this is in fact what is required by the terms of the license. This is because the illustrative examples given after the expression of this requirement actually undermine it. "[P]osting said modifications to Usenet or an equivalent medium, or placing the modifications on a major archive site such as ftp.uu.net" by themselves will not permit any person to copy, distribute, or modify those modifications, except as permitted by the doctrine of fair use, as described in Chapter 1. Simply placing a work in a public place does not waive any protections of copyright that might otherwise be attached. As already noted, a work need not even carry a copyright notice to be protected by copyright. Without an explicit disclaimer of copyright protection (such as a public domain dedication) or a licensing agreement, prudent users will assume that such work is still protected by copyright and substantially unavailable for use. Accordingly, this part of the license could create a potentially awkward situation where a modifier, who does in fact want these modifications to be publicly available as the Artistic License seems to require, publicly posts those modifications but does not provide a license that would allow for their free use.[5]
The third "sub-option" permits a modifier to comply with the license by entering into a separate arrangement with the Copyright Holder. The purpose of this is to permit the Copyright Holder to include the modifications in the Standard Version. While having the same immediate effect as placing the modifications in the public domain, by using this "sub-option," the modifier may be able to retain additional rights, such as the right to license exclusively the modifications for use in another application. Obviously, this depends on the arrangement with the Copyright Holder.
The second of the options prevents public distribution of the modifications but may be appropriate for many situations in which the modifier wants to have the benefit of the modified code for his own (or his own organization's) use but does not want to surrender intellectual property rights that are associated with the modifications.
b. use the modified Package only within your corporation or organization.
The third option allows for technical modifications that will likely limit the compatibility of the modified code with the Standard Version.
c. rename any non-standard executables so the names do not conflict with standard executables, which must also be provided, and provide a separate manual page for each non-standard executable that clearly documents how it differs from the Standard Version.
This variation reflects the Artistic License's association with Perl, with its use of programming language-specific terms, such as "standard and non-standard executables" and "manual pages." Using this variation permits a "fork" in the development of the underlying software, with the modified version developing separate and apart from the Standard Version. In essence, modifiers are free to "take their ball and go home" but at the cost of splitting off from what is likely to be the most popular version of the underlying code, the Standard Version.
The fourth and final option is one inherent in any license: negotiating separately with the original licensor.
d. make other distribution arrangements with the Copyright Holder.
Section 4 governs the distribution of both the Standard Version and any modified versions of the Package in executable form or object code. The rights to distribution it grants are in addition to the rights granted by Section 1 to distribute the source code of the Package.
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:
These requirements apply any time any part of the Package is distributed in executable form, whether modified or not.
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.
The license appears to allow each of the forms of distribution to be used no matter whether the Standard Version itself is being distributed—a Standard Version with user modifications (for example, with modifications the user has issued into the public domain)—or a modified version under Section 3(c). Accordingly, a distributor could lawfully distribute a modified version and remain in technical compliance with the license by providing only the executables and libraries of the Standard Version together with instructions on where to get the (source code presumably of the) Standard Version. This is so, even though it seems clear that distribution of a modified, nonstandard version of the code should be made under Section 4(c). This is another of the ambiguities of the license.
b. accompany the distribution with the machine-readable source of the Package with your modifications.
This option seems intended for distributions of the Standard Version where the code has been modified under the first "sub-option" described in Section 3(a)—i.e., where the modifier has placed his modifications in the public domain. This would be the most sensible way for such a distribution to be done, although, as already noted, the distributor may exercise any of the options in distributing the executable form of the Package.
accompany any non-standard executables with their corresponding Standard Version executables, giving the non-standard executables non-standard names, and clearly documenting the differences in manual pages (or equivalent), together with instructions on where to get the Standard Version.
The third option clearly mirrors Section 3(c) governing the creation of modified, nonstandard versions of the program. While not required, modifications of the Package created under Section 3(c) should be distributed under the terms of Section 4(c) to best support the purposes of the license.
Finally, as was the case with the licensing of modifications, a distributor can always negotiate a separate, permissible manner of distribution with the Copyright Holder.
d. make other distribution arrangements with the Copyright Holder.
Section 5 governs the charges that may be imposed by a distributor in connection with the distribution of the Package, whether in the Standard Version or a modified version.
5. You may charge a reasonable copying fee for any distribution of this Package. You may charge any fee you choose for support of this Package. You may not charge a fee for this Package itself. However, you may distribute this Package in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution provided that you do not advertise this Package as a product of your own.
As already noted, "reasonable copying fee" has no enforceable meaning, as the way it is defined makes reference only to the price that the market will bear. Because the license permits anyone to distribute the source code and the executable form of the Package, competition will likely impose its own limits on any fees charged by distributors, as is typically the case for open source and free software licensed programs. As is the case with the GPL and all of the other licenses already examined, this license does not prohibit agreements to support the use of the Package, which presumably would include warranties or other comparable guarantees of functionality. Finally, this section also permits distribution of the Package as part of a distribution unit with commercial (or non-commercial) software, so long as the distributor does not claim to be the author of the Package and, implicitly, so long as the other requirements of Section 4 are complied with. This last permission is subject to an important limitation in several variations of the Artistic license, including the Perl Artistic License. This limitation is described in more detail later.
Section 6 also reflects the Artistic License's connection to Perl, a programming language, and makes explicit that programs in Perl do not fall within the scope of the license but belong to whoever generated them.
6. The scripts and library files supplied as input to or produced as output from the programs of this Package do not automatically fall under the copyright of this Package, but belong to whomever generated them, and may be sold commercially, and may be aggregated with this Package.
Section 6 further permits the distribution of libraries or scripts with the code that is so generated. Obviously, such libraries or scripts may be necessary for the code to function. This is described in the optional Section 8.
Section 7 excludes from the scope of the license C or Perl subroutines linked by the user with the Package.
7. C or perl subroutines supplied by you and linked into this Package shall not be considered part of this Package.
Section 8 of the Artistic License contains the non-endorsement clauses typical in open source and free software licenses and prevents the use of the Copyright Holder's name in connection with the sale or distribution of modified versions of the Package or code developed from the Package under Section 6.
8. The name of the Copyright Holder may not be used to endorse or promote products derived from this software without specific prior written permission.
There is another optional Section 8 that also appears in variations of the Artistic License, most importantly, the Perl Artistic License.
8. Aggregation of this 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.
Although not stated explicitly, this section is meant to address the same situation as governed by Section 6: where what is at issue is not the Package itself (i.e., the Perl scripts and libraries) being modified and distributed, but code that relies on the Package in order to properly function (i.e., software written in Perl). This Section 8 accordingly limits the generally free distribution of the source and executable codes under Section 1 and 4 respectively when that distribution is part of a commercial aggregate with the Package. In those situations, the Package may be utilized as part of the commercial program, but its interfaces (and, correspondingly, the ability to write new scripts in Perl) must be blocked from the end user. This section is presumably included to prevent commercial distributions of programs written in Perl from competing with the parallel open source distributions of Perl that are intended to encourage innovation and contributions to Perl itself. While commercial distributors are free to employ Perl's functionality in their commercial programs, such commercial programs are shut out from Perl's own development cycle.
Finally, Section 9 of the Artistic License contains the standard disclaimers of warranty found in most open source and free software licenses.
9. THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
The Artistic License is designed for centralized projects, much like the QPL and the MPL. Because of this and the license's emphasis on the rights of the Copyright Holder, it is probably not suited for freeform software development projects. In addition, it has ambiguities in key terms governing modification and distribution of the licensed code. Nonetheless, it is worth taking the time to understand because of Perl's ubiquity. Moreover, as discussed, it is not difficult for contributors to Perl (or other projects licensed under the Artistic License), despite the license's ambiguities, to comply with both the letter and the spirit of the license.
[4] The public domain is discussed in more detail later. A sample Public Domain Dedication can be found at http://creativecommons.org/licenses/publicdomain/. There is some uncertainty about the effectiveness of such public domain dedication, however.
[5] The fact that this happens all the time in open source development does not eliminate the possibility of a misunderstanding that could lead to a legal dispute. A contributor may actually not know that he is "licensing" work that he submits to an open source or free software project, or he may think better of it after having done so, and take some action to claw his submission back. This situation seems to rarely, if ever, arise. Nonetheless, those considering taking leadership positions in such projects should take reasonable efforts to make sure that contributors are aware of the licensing terms applicable to the project.
Get Understanding Open Source and Free Software Licensing now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
