Suppose you've written a piece of software that you'd like to distribute -- by "ungoverned" public FTP, or under an open source license, or for profit? This incomplete document tries to provide some guidance.

If the code is totally trivial, blast away. But if it's at all significant, then even if it's "your code" and even if all you want to do is make it available via "ungoverned" public FTP or under the GPL, there are some procedures you need to follow in order to protect yourself. Protect yourself from what?

  • From someone else taking your work and claiming it as his/her own.
  • From liability if the code wipes out some poor schmoe's hard drive.
  • From accusations that you distributed code owned by someone else.
  • From claims that you violated the public trust ("Remember -- We're state employees!") by making money inappropriately.

Please read all this material, and send questions and comments to Ed Lazowska. That's the only way this document will get clarified and expanded.

Always insert a copyright notice / license in your code!

If you are an "open software" kind of person, then read the debian free software overview and the debian "social contract,", and consider using the " BSD license."

Various alternatives are discussed below, and I am counting on the Office of Technology Transfer to provide us with some UW-specific "standard forms" for our use.

Who "owns" software?

A separate web page is devoted to this question; see here.

It's normally the case that code authored by students belongs to them. But don't stop here -- read on! For example, even if it's pretty clear that you own the code, you'll want to obtain a letter from the Office of Technology Transfer verifying this fact.

Basic procedures

  • Obtain the permission of your advisor (if the code resulted from research), or of your course instructor (if the code resulted from a course project).
  • Working with your advisor/instructor, "disclose" the code to the Office of Technology Transfer (fill out an invention disclosure form, which precisely identifies the item, describes any sources of funding, names any collaborators, etc.).
  • OTT will scope things out. Suppose, for example, that you have some code that you would like to distribute via "ungoverned" public FTP or under the GPL. OTT will either give you a letter that says UW does not have an ownership position, or a letter that says UW has an ownership position and allows distribution under the license that you select.
  • Insert appropriate licensing language in the software and/or on the download web page.

"Open software"

The debian web provides a nice description of the pros and cons of various "open software" licenses.

Above, I recommended the "Modified BSD license." While the GNU Public License (GPL) is popular, it's not necessarily what you'd want to use if, e.g., your goal was just to encourage tech transfer. Because the GPL requires that source code which includes GPL code be distributed, many companies won't allow the use of GPL'd code, which effectively stops researchers in those companies from experimenting with your code. The Debian page discusses these issues clearly.

License terms

An appropriate license should appear in the code, and also included in the download web page in a way that the person downloading the software must take action to move through it as a condition of access to the code. Think about how commercial licenses work when you download software from the web.

Licensing involves granting of permission within the scope of the licensor's rights. A license is a contract, and to be valid for more than a year, must be in writing and involve consideration for the grant of permission. Consideration means some benefit provided to the licensor in exchange for the permission, and may include, for instance, money, services, or obligations the licensee is willing to undertake to meet the licensor's goals. A license may grant rights narrowly or broadly under the licensor's intellectual property rights. In the case of a patent, a licensee may gain the right to make and use, but not to sell a product covered under the claims of the patent. In the case of a copyright, a licensee may gain the right to make copies and distribute a work, but not to change the work in any way. When a licensor gives up all rights to the licensee in a given area, the license is said to be "exclusive" in that area. When a licensor is able to license others the same set of rights, the license is "non-exclusive." When a licensor agrees to license but once in a given area (such as, licensing rights to only one commercial publisher, but allowing multiple non-commercial redistributors of a software application), the license is "sole." A license can be as simple as a single sentence permission statement and as complex as is necessary to establish a full account of the rights, the scope of permission, the consideration, diligence, reporting, liability, communication, governing law, and other elements that the licensor and licensee require to protect their respective interests in the relationship.

Below we have included reproductions of several license contracts that have been used by members of the department in consultation with OTT. While there are great similarities between the documents (e.g. disclaimers of liability) each is slightly different owing to the particular context in which it was written. OTT promises to help me explain the differences among them at some point!