Software Garden

COPYRIGHT, OPEN SOURCE, AND WHY A LAWYER IS A DEVELOPER'S FRIEND
Version 0.2

Introduction and overview

An introduction to some basics about copyright and software licensing from a developer's viewpoint with special emphasis on open source software issues so that you have a better understanding of what is required of a software developer in that area and why. This does not cover patents, trademarks, and other Intellectual Property issues, nor philosophical issues.

Who is this for? Software developers, corporate management and corporate counsel (internal and external) as a catalyst for discussing these issues with developers.

Disclaimer: Dan is not a lawyer. Talk to your own lawyer for legal advice.

Outline of the video.

Access to source code

Having access to source code of an existing program is important in software. You learn by looking at previous work, both general learning about an area or language as well as how to achieve specific functionality.

In addition to learning, you reuse existing code. Sometimes the reuse is as a component and sometimes it is the basis for building upon.

Examples of using the code of others range from books and magazines to entire open source applications.

Copyright law

Copying is regulated by Copyright Law. It defines special rights held by the author that are not automatically given to others. They include the exclusive rights to: make copies, create derivative works, and distribute copies (including of the derivative works).

Copyright applies to “expression” but not ideas. There is a fuzzy line between them sometimes, which is where lawyers come in. There are concepts you may have heard of such as Fair Use and the Public Domain. For software copying of any substance in a corporation Fair Use probably doesn’t apply. Unless you have specific proof otherwise you should also assume that any given piece of software is not in the Public Domain -- lack of a copyright notice does not automatically place something in the Public Domain.

Combinations of works and additions of new code result in more than one author with rights. The new person’s rights do not overrule the first person’s.

Author’s can assign their rights to others.

Variety of licenses

Without the author’s permission you can’t do much with a work. They can stop you from making copies, getting monetary damages, and there could even be criminal penalties. Don’t assume that you can get away with it and that nobody will find out in today’s world.

The author gives you permission through what’s known as a license. The license is a bargain with the author. The author will allow you to do certain specific things that you wouldn’t otherwise have permission to do under copyright law. In return you have to take specified actions and abide by specified conditions.

The things they allow you to do may include running the program on a particular computer or perhaps distributing copies of a runtime module. The conditions may include paying money or displaying a particular notification on copies.

There are a wide variety of licenses with a wide variety of terms in them. Examples of traditional licenses are some on prepackaged software that have different criteria for which computers you can install your copy on. They also sometimes have seemingly unrelated terms that meet the author’s business needs.

One class of licenses consists of what are called open source licenses. In some respects these may have terms similar to other licenses, such as disclaimer of warranties. In other respects they are different. They are often called “free” as in “unconstrained”. The freedom is usually meant in respect to the source code. There is software without access to source code that has no fee and some open source software is often purchased for a fee along with support or other additional benefits.

Common attributes of open source licenses include access to the source code, free redistribution (both without fee and without restrictions), and permission to create derivative works. Additional elements of the bargain may include keeping the author's name with any modifications, indicating changes, and restrictions on the terms of licenses put on derived or collected works that include the original code.

Terminology

Be careful with terminology with regards to open source. Many people distinguish between "Open Source" and "open source". The former often refers to licenses that meet all the terms of the Open Source Initiative, a non-profit organization. Other licenses might still meet your needs.

There is "Open Source" vs. "Open Standards" and "Open Formats". One refers to the program source code, the others to data formats and the method of communication between programs.

While much open source uses open standards and open formats, there are a lot of proprietary software products that support them, too.

Many licenses

There are many licenses to keep track of, and there are new licenses coming about all the time, each a bit different, to meet the needs of certain authors. Examples are Sun with some of their software and Microsoft with various file formats and how you can examine their source code. There are also cooperatives with corporate or government membership that have agreements on how they share code.

Dual licenses

Owners of the copyrights can release their software under multiple licenses with different terms to give you a choice if one doesn't meet your needs. Licensors have always made special deals with certain purchasers, such as large corporations or governments, but the restrictions of some open source licenses, and the desire of some companies to easily avoid those terms (and being willing to pay for it), is bringing this to the fore.

License compatibility

When you have collections of works or new and old code combined in a project you have to be careful that you don't have any conflicting requirements between the different licenses of the components. For example, the GPL license does not allow code licensed under it to be redistributed with any further restrictions in a license. Those disallowed restrictions could be adding a special notice or having additional restrictions on copying.

New emphasis on licenses

People with experience in programming may comment that there didn't used to be such attention to licenses and copyright as there is now. Why?

In the old days, the copyright licenses were quite short. There are lots of examples to show that. Now they are much longer with many more terms and details of exactly what you can and can't do.

I think that many things have made people more sensitive, such as the SPA/BSA software anti-piracy campaigns, Napster and the RIAA, and the SCO lawsuit against IBM involving Linux. In that last case, first people worried about Linux, and then with the good defense so far by IBM and the Linux community corporations wondered "If somebody sued me, can I trace the pedigree of all the pieces of my software that well?" Corporate ethics issues and Sarbanes/Oxley have made corporations more sensitive to doing the "right thing".

Finally, the success of Linux and open source has made people sensitive to the fact that licenses do matter and can have great effects.

The GPL

Many open source licenses come as templates that authors just copy and use with their software. Some like the Apache and MIT licenses have very few restrictions on what you can do with the software. They are compatible with many other licenses.

There are a set of licenses, especially version 2 of the GPL, that are different. The GPL is probably the most popular license for many reasons. In addition to letting you use the code and make copies, it requires that modified versions be licensed as a whole at no charge to third parties under the GPL. This is a "reciprocal" or "viral" license.

The word "viral" conjures up an image of a jungle disease where you just breathe on someone and they catch it and then pass it on to others -- that you just "touch" a GPL program to another and it becomes covered by the GPL and you can't undo it. That's not exactly the case. The GPL says that code you write yourself does not become GPL automatically when distributed by itself. What is says is that without following the terms of the GPL and releasing your derivative works, etc., under the GPL you have no right to distribute code covered by the GPL, so you'd have a copyright infringement. It doesn't force your code into the GPL, but if you were sued by the author for copyright infringement, then turning around and releasing it under GPL would be a defense. You could also make a deal with the author (as the GPL suggests may be possible in some circumstances, depending upon the author) or perhaps retrieve all the copies and remove the GPL code.

Different authors have different interpretations of the terms in the GPL, such as what a work "based" on another means. Some are narrow and some are very broad.

It matters who the author is, since the author needs to be involved in asserting rights against you. By my reading, a third party who isn't the author can't assert that you mixed your code with GPL and therefore all of your program is now automatically under the GPL.

Many companies have figured out how to use open source software in their work, even GPL code, and still coexist with proprietary and other licenses. You can't always do it, but it's worth looking into. Don't panic and have a blanket prohibition against GPL, but also don't ignore its terms.

What have we learned so far?

Need to know fine points of each license. Need to know the licensor and license for each piece of software you use. You may need to make separate deals with authors. Code architecture needs to take into account legal and business issues, not just technical and usability issues.

The law, lawyers, and corporate executives

While we'd like "bright lines" separating things like whether or not your new program is "based upon" another piece of code or not, or whether something is an idea or expression, in reality things are often fuzzy and you need the advice of experts. You look to case law -- what judges have decided in the past. That is a lawyer's job, as well as to understand all the legal terms in the licenses. They can help you work things out, and lay out the risks where things aren't certain. They can also help draft deals and modified licenses. They can be your friend in working these things out.

The company executives have to decide the business models under which the company makes money and which risks it takes. They also can help with making the deals with outsiders.

Corporate software license policy

You need to have one. What's in one? Defining the meaning of terms. Listing which risks to take and which not to take. Listing decisions to be made and how to make them, including how much to participate in the community around a product, if at all. Listing the records to keep. Auditing.

Dealing with licenses with software you distribute

You need to decide under which license you release your software. If it includes other software you have to deal with any requirements and restrictions of the licenses for that software. There are cases where you may need to avoid reciprocal licenses like the GPL. The uncertainty may be too great for your company or the ways you need to isolate the GPL code just may not work for your product. If it can't work, it can't work. The authors who decide to put their software under the GPL do it for a reason and you have to respect that part of the bargain for access to their code.

How does this change the job of a developer?

You have to keep track of many things. You have to understand intellectual property issues. You have to understand corporate policy. You have to work with the corporate control (accounting) people. You have to work with the legal people to identify problems and work them out.

In closing

These issues are not just about open source software, but apply to many different licenses. Using the code of others is an important part of software development. Open source software products and reading the code of others is part of the software ecosystem and we get great benefit from it.

Dealing with intellectual property issues are part of being a software developer today, much like other things you have to deal with like usability, internationalization, source code control, or shipping to a schedule.