For most practical purposes, it is — sort of. This is a complicated question, so please read on.
"Public domain" is a technical term in copyright law that refers to works not under copyright — either because they were never in copyright to begin with (for example, works authored by U.S. government employees, on government time and as part of their job, are automatically in the public domain), or because their copyright term has finally lapsed and they have "fallen into" the public domain.
Not all jurisdictions have a public domain, and it doesn't always mean exactly the same thing in the jurisdictions that do have it. Furthermore, even where it is clear what it means, it's still not a license. To be subject to a license, a work must still be in copyright. That means there is no way for the "public domain", as a concept, to go through the OSI evaluation and approval process. We wouldn't be evaluating a license text. Instead, we would have to somehow evaluate the laws themselves, in different jurisdictions, and say which jurisdictions have a public domain that meets the Open Source Definition and does not create problems for software authors and users. This would be very difficult, because it would mean evaluating not just the statutes but various bodies of case law (for example, open source licenses usually have a strong disclaimer of liability for the copyright holder — but we don't know how or whether the author would be protected from liability for software released into the public domain in various jurisdictions). This approach would not be useful to the OSI's mission, because open source is an international phenomenon and we only want to approve licenses that meet the Open Source Definition everywhere.
Thus we recommend that you always apply an approved Open Source license to software you are releasing, rather than try to waive copyright altogether. Using a clear, recognized Open Source license actually makes it easier for others to know that your software meets the Open Source Definition. It also enables the protection of attribution, and various other non-restrictive rights, that cannot be reliably enforced when there is no license.
There are certain circumstances, such as with U.S. government works as described above, where it is not easy to apply a license, and the software must be released into the public domain. In these cases, while it would be inaccurate to display the OSI logo or say that the license is OSI-approved (since there is no license), nevertheless we think it is accurate to say that such software is effectively open source, or open source for most practical purposes, even though it is not officially released under an open source license. (This is assuming, of course, that in the laws of releasing jurisdiction the meaning of "public domain" is compatible with the Open Source Definition.) After all, the freedoms guaranteed by open source licenses are still present, and it is possible for the familiar dynamics of open source collaboration to arise around the software.
For a detailed discussion of the complexities of the public domain and open source, search for the words "public domain" and "PD" in the subject headers of the January 2012, February 2012, and March 2012 archives of the OSI License Review mailing list. And if the thought of reading all those conversations is daunting, please take that as more evidence that it's just better to use an approved Open Source License if you can!
See also the CC0 question. For a different viewpoint than the one presented above, see unlicense.org.
by Chris Shiplett
Attorney, Erik M. Pelton & Associates
Re-usable code is a key component of any developer's toolkit, and creating and owning re-usable code is a critical step in the process of creating a profitable software development business. Whether the code consists of web-site management scripts, "black box" modules or self-contained classes contributed to larger projects, re-usable code is the centerpiece of modern object-oriented and rapid-prototyping design principals. To fully leverage the power of re-usable code, however, you must understand the legal framework that defines who owns that code.
I assume for the purposes of this article that the code at issue is copyrightable. Some of the most basic code fragments, for example a simple "for" loop to iterate through an array of objects and perform some action on each object, may not be copyrightable at all. Most larger code segments, however, are copyrightable.
Copyright Law Creates A Framework For Software Ownership
Ownership of the copyright in software code is important because the copyright owner controls the ability to copy, distribute, sell, or modify the code, and generally controls the ability to profit from the code. Under copyright law, the author of a line of software code is the owner of the copyright in that code. That is, the person who physically puts fingers to the keyboard and types out the sequence of words and symbols that constitutes a line of software code is the "author" and owns the copyright to the code. A copy-right is created by federal law and consists of six rights the owner of a "work" has to the exclusion of any other person or business. Four of these rights are applicable to software code. Those are:
- The right to reproduce the code
- The right to create "derivative works" based on the code, such as the screen display that the code generates, future versions of the software, or other software programs into which the code is integrated
- The right to distribute copies of the code
- The right to "display" the code, for example by posting to a web site. (17 U.S.C. § 106)
Applying the basic law of copyright to software development, if you personally write a class or a module, you own the copyright to that class or module. If you write a website in html, or a website display script in a scripting language like PHP or ASP.NET, you own the copyright to those lines of code you wrote. You are free to re-use that code in any way you like, and no other person or entity can legally use that code without your permission.
The basic rule is subject to several exceptions. In the software world, there are three exceptions so common they swallow the rule. A more nuanced and practical understanding of the role of copyright in re-usable code requires as much understanding of the exceptions as the basic rules. The three exceptions to the basic rule of copyright ownership most prevalent in the context of software development are the "work-made-for-hire" rule, the "License or Assignment" clause in a development contract, and the unique situation encountered when developing on an "Open Source" platform.
The "work-made-for-hire" doctrine generally defines the relationship between a software developer and his or her client.
A segment of software code is a "work-made-for-hire" if it is either:
a) A work prepared by an employee in the scope of his or her employment; or
b) a work specially ordered or commissioned for use as  a contribution to a collective work,  as a part of a motion picture or  other audiovisual work,  as a translation,  as a supplementary work,  as a compilation,  as an instructional text,  as a test,  as answer material for a test, or  as an atlas, if the parties expressly agree in a written instrument signed by them that the work shall be considered a work made for hire. (17 U.S.C. § 101)
In either situation, the author of the code does not own the copyright in the code, as would be expected under the basic copyright framework. Rather, the person or business that employs the author or that commissioned the software owns the copyright in the code.
When a developer creates software as an employee, determining ownership of that software under the "work-made-for-hire" rule is relatively straightforward. Any work a developer creates within the scope of his or her employment is owned by the employer. Analysis of whether work is "within the scope of employment" can be extremely complex. However, at its most basic, if a developer writes a particular piece of software for work, his or her employer owns the copyright to that software.
When a developer creates software as a contractor, analyzing who owns the copyright in code created as a result of that relationship becomes both more complex and more important. Courts and legal analysts use a three-part test to determine whether the developer or the client owns a particular segment or module of code. First, the work must have been specially ordered or commissioned. Second, the work must specifically fall within one of the ten categories enumerated in part (b) of the "work-made-for-hire" rule. If the work at issue does not fall within one of the enumerated categories, it cannot ever be a "work-made-for-hire." Almost all software code is consumer-facing code and will fall under category three, audio-visual work, although some software without a human-readable interface may not fall under any of the ten enumerated categories. Third, and most significant, a commissioned and copyrightable work will only be considered "work-made-for-hire" owned by the client if the parties have a written agreement signed by the developer that explicitly states that the work is "work-made-for-hire."
If a particular piece of software is a "work-made-for-hire," the employer or client that commissioned the code owns the copyright in it. In order for the developer to have any right to use the software later or in different projects, the developer must negotiate a license to the software in the same way any third-party would.
Outside of "work-made-for-hire," almost every development engagement includes some arrangement for the ownership, assignment, or licensing of the software.
The original author or any other owner can also transfer or share copyright rights to or with others through an assignment of the copyright or a license of the copyright. These two concepts should not be confused. An assignment is a grant of all of the rights of the author in the copyright to another party. If the developer assigns his rights to code he or she has written, the developer no longer has any right to the code, and must license the code from the new owner to have the right to re-use it. Additionally, for an assignment to be binding, it must be made in writing, and must be signed by the developer. Any alleged verbal assignment of copyright rights will be considered a license of those rights and not an assignment.
A license, in contrast, is a grant of permission to use the code without giving up ownership of the code. If assigning copyright in software is like selling your house, licensing copyrighted software is like renting your house. A license can range from a mere right to use the software, module, script, or class in the completed software, to granting rights to re-write the software or create derivative software from it, all the way up to all of the rights to the code that the original creator has. A license can be exclusive in the sense that the author agrees not to license the code to anyone else in a particular geographic region, industry, for a period of time, or at all, or it can be non-exclusive in the sense that the licensee is only one of several concurrent licensees, each with the same or overlapping rights. Importantly, the terms of licenses are interpreted according to the contract rules of your local jurisdiction. Therefore it is extremely important that the parties understand exactly what they are agreeing to before coming to an agreement.
Licenses and assignments are the two building blocks of software development agreements, and should be a part of every software development contract. If software is not a work-made-for-hire, or the software copyright is not either expressly assigned to the client or licensed to the client at the end of the development project, then the client will infringe the developer's copyrights in the code every time the client uses that code. Therefore, every well written software development contract will contain a clause designating the code a work-made-for-hire, assigning the code to the client on completion, or granting the client a license to use the code on completion.
Putting it Together, A Sample Contract Clause
It is not uncommon for contracts to have a clause or series of clauses addressing all three of the above ideas, work-made-for-hire, license, and assignment. Below is an example of a typical section addressing copyright partitioning:
The copyright in all works of authorship created pursuant to this agreement are owned by Client. All such works or portions of works created by Developer are "works made for hire" as defined in 17 U.S.C. § 201. Developer assigns to Clients all right, title, and interest in:
(a) The copyright to all works of authorship ("Work") and contribution to any such Work ("Contribution") created pursuant to this agreement;
(b) Any registrations and copyright applications, along with any renewals and extensions thereof, relating to the Contribution or the Work;
(c) All works based upon, derived from, or incorporating the Contribution or the Work;
(d) All income, royalties, damages, claims and payments now or hereafter due or payable with respect to the Contribution or the Work;
(e) All causes of action, either in law or in equity, for past, present, or future infringement of copyright related to the Contribution or the Work, and all rights corresponding to any of the foregoing, throughout the world.
Developer may use the Work only until Developer delivers a final product to Client, and may use the Work only insomuch as such use is necessary to the creation of the final product. Client grants no license to developer for any use of the Work other than as expressly described herein. Developer must request a separate license from Clients for any use of the Work other than as expressly described herein. Such license must be explicitly granted in writing, signed by Client, or it is void. Should a court of law with jurisdiction over the parties and the subject matter of this contract deem the Work not a "work for hire," and should a court of law with jurisdiction over the parties and the subject matter judge the above assignment of copyright void, Developer grants Client an exclusive, royalty-free, irrevocable worldwide license to use the Work without limitation in any manner Client deems appropriate.
This clause attempts to cover each of the bases for the client to control the work, first by asserting that the work is a work-made-for-hire, then, by assigning the work to the client, and licensing back only the rights to the code necessary for the Developer to work on the project at issue, and finally, by granting the client an unlimited license for use of the work, in the event a court deems the code neither a work-made-for-hire, nor lawfully assigned. This particular example gives all of the rights to the code to the client. Of course, each of the component parts of this clause can and should be negotiated beforehand. Under a contract containing the clause above, the developer would not be allowed to re-use the code developed for the project. In negotiations, the savvy developer must understand each of the components to the above clause, and understand the ownership interest in the code each clause represents.
Open-source software platforms complicate the ownership of code
Open-source software is ubiquitous today, and it is impossible to develop software without encountering some form of open-source code, either as a platform on which to develop your software or as a component of your software. The key to understanding the implications of open source software on development is the understanding that open-source software, while free, is not in the "public domain." Open-source software is copyrighted software, the proper use of which is mandated according to the particular terms of the license. Importantly for developers, derivative software that is based on open-source software must generally conform to the terms of the original open source license, while software written to perform on an open-source platform need not. For example, if you write a flavor of Linux for use with a particular hardware suite, you must grant access to your source code in the same way you have been granted access to the Linux source code. Conversely, if you write a program to run on the Linux operating system, you need not conform to the GPL 2 open source license under which Linux is released, because in that case, Linux, while necessary for your software to function, is not a component of your software. In copyright terminology, your software is not a "derivative work" of Linux.
On the distribution side, if you choose to release your software under an open-source license, be aware that there are different flavors of open-source licenses. (See, for example, the Wikipedia entry on "Open Source Licenses" describing, comparing and contrasting many of the licenses.
Each flavor allows users of the software to do slightly different things, places slightly different restrictions on the user's use of your software, and grants slightly different remedies in the event a user breaches the open source agreement.
What It All Means
There are a number of things you can do while negotiating a development agreement to ensure that you can fully leverage the power of re-usable code, and that your interests in the code you write are protected. The following are a sample of the most important things you should consider before you write a single line of code:
Get agreement in writing on ownership of the code before you write a line of code: In almost every aspect, copyright law defers to the agreement between the parties. Before you start writing code for a project, make sure that both you and the client completely understand each other's expectations for who will own the copyright in the code and what rights the respective parties will have to use the code when the project is over.
Clearly define what pre-built code you are bringing to the engagement versus what code you are writing to the specifications of the client: Often projects are a mix of pre-created code and custom written code. Make sure that the agreement spells out what components you created prior to the engagement, and what components you will write specifically for this project. While you will own the copyright to anything you wrote before beginning the engagement, you do not want the question of ownership of your entire software toolkit left open if there is an eventual conflict. Spell it out beforehand.
If possible, retain ownership of the code and license it to the client: Your code is valuable. It may be that the client only wants the security of knowing you will not revoke their right to use the code and walk away from a half-completed website, or they may be concerned about you re-selling an idea they feel they have an ownership interest in to a direct competitor. All of this should be part of your negotiation. If you can satisfy your client's desire for security and assurances of a well-built, sophisticated web site, script, class, or module, without assigning the code to them, try to keep ownership of the code and license it to the client, rather than assigning it to them, or having them own the copyright outright under the work-made-for-hire doctrine.
Use ownership of the code as a negotiating point: A developer generally owns the code he or she creates. If the client insists on ownership, or an exclusive license to that code, use that to negotiate. You can ask that the client pay a premium for exclusive rights to the code, or ownership of the code. You can ask for a license back to create derivative software based on the code, and grant the client ownership of the code, again for a premium rate. Whatever you and your client decide, however, make sure that both sides are clear on the terms of the agreement, on what the words, such as "ownership," "license," "author," or "work-made-for-hire," actually mean, and, of course, abide by the agreement once it's completed.
Be aware of open source restrictions: "Open-source" does not mean free for everyone to use in any way they like. Open source contracts are binding, and will be enforced. If you write code on an open source platform, read the license and abide by its terms. Make the client aware of any restrictions in their use of your code that may flow from use of an open-source platform.
Write it all down and sign it: Each of the key components of copyright law require a written agreement, signed by the parties. Without a written agreement, and without the parties' signature, copyright law defaults to the basic rule described above. While it may seem advantageous as a developer to leave an agreement unsigned, because the default rule typically grants ownership to that developer, remember that your work for a client and their satisfaction is based on your performance against their expectations. If the client expects sole ownership of a code segment, and you have agreed to it, don't use the signatory requirements of copyright law as leverage after the fact to change the agreement.
When in doubt, consult a lawyer: Lawyers in this situation act as insurance. Like buying insurance, hiring a lawyer to review your contract can seem like an unnecessary up-front expense. However, the up-front cost of consulting with a lawyer before you negotiate an agreement can save a huge amount of frustration, wasted effort, and money in the long term by ensuring that any agreement you sign reflects your understanding of the agreement you negotiated, and that both parties understand the terms that they have agreed to. The price of not having a properly negotiated and signed agreement could mean losing all copyright rights and control of the code.
About the Author: Chris Shiplett is an associate with Erik M. Pelton & Associates, PLLC, and specializes in software development contracts, trademark and copyright, and domain name disputes. He can be reached at email@example.com.
Copyright 2008 Erik M. Pelton & Associates, PLLC.