Overview

Suppose you decide you want to distribute your Project 3 tile game to others - perhaps commercially, perhaps not. What is it that you actually distribute? What can other people do with it? Can you, in fact, distribute your program if it includes code written by other people? Since the Java Virtual Machine (the executable java on our Unix machines) is required to run your program, can you package it along with your class file as a single thing you distribute to your users? Can people take your program and use it in their own projects? Can they distribute these projects?

All of these (and many more) are questions that force us to confront the software licenses, which is the subject we'll look at in this lesson.

A little bit of history

In 1974, US Commission on New Technological Uses of Copyrighted Works determined that software was subject to copyright. Originally this meant source code was copyrightable, but subsequent legal rulings established that object code was covered by copyright as well.

What do you distribute?

First of all, we need to think about what it is that we are actually distributing. There are at least the following four options:

• source code - this would mean sending out the actual .java files
• object code - this could mean sending out the .class files but, more likely, it would mean sending out a .jar file
• everything needed to run the game - this could mean a VM image (or docker image, if you are familiar with that) that contains not only your .jar file, but also the Java Virtual Machine and any other software needed to fun you game

  In this case, you have to look at the licenses of all the things you are shipping along with your program and comply with all of their licenses. This is outside the scope of what we will cover in this lesson.

• nothing - this could mean that you made your game part of a website, for example, so that anyone with an account on the website could play the game. This approach is an example of Software as a Service (SaaS), and is the approach taken by a lot of software that users subscribe to. In essence, Netflix is SaaS.

  SaaS brings up interesting issues of its own, but they are outside of what we will cover in this lesson.

For this lesson we will restrict ourselves to the situation in which we are either distributing source code or object code (probably as a .jar file for Java).

Closed source/Open source and Proprietary vs. non-Proprietary

Roughly speaking, we have two separate issues:

• Closed source/Open source - do the recipients of the distribution have access to the source code?
• Proprietary vs. non-Proprietary - are the recipients of the distribution restricted in what they can do with the code? This is often described as "proprietary" vs. "free", often with the clarification that the word "free" is meant as in "free speach" as opposed to "free beer". For example, supposing recipients are given access to the source code? Are they "free" to modify it to suit their needs, fix bugs, whatever?

It is important to note that proprietary programs may allow source code access, and a program may be non-proprietary and yet only distributed as object code. In the former situation, you may be using the software and be able to see the code, but not allowed to modify the code yourself. In the latter situation, you may have an executable program and be allowed to bundle it with other code to redistribute, but not have access to the original source code.

Software licenses - "Open Source"

A software license is a document that describes who can do what with the software, more formally, it describes the rights that the recipients of the software have and what rights the copyright holder has. We are going to focus on non-proprietary, open-source licenses, but first, let's look at the license for Oracle JDK 21, which is proprietary and open source (note that there is also the OpenJDK, which is what we use on our VMs and lab machines, which has an open source license). This license is not very restrictive, by the way. Don't make the mistake of thinking that's what all proprietary licenses are like!

Open source software usually refers to a license that guarantees access to the source code as well as the freedom to modify, extend and redistribute, and which, moreover, does not restrict what the software is used for. There are a variety of commonly used licenses, which we will look at later. Old-school practice was to include a license statement at the top of each and every source code file, though today many projects just contain a single file, named something like "LICENSE", in the root directory of the distribution. OpenJDK is an open source project providing, among other things, the Java API. You can take a look at the source code for, for example, ArrayList on the github page: ArrayList.java. In this case, you see that old school practice. You can check out the github repo for pulsar, a new fork of the now-defunct Atom editor, where you see the license in the file LICENSE.md, located in the project root directory, and not in the source code .js files in directory src.

It is not necessarily the case that Open Source licenses don't include restrictions. As we will see below, there is kind of a spectrum to them in terms of conditions. The most interesting restriction, I think it's fair to say, is the restriction established in the "GNU Public License" (GPL), which is (roughly) that any work that includes or builds upon GPL'd code must itself be released under the GPL. This technique is often referred to as "copyleft".

A small group activity

The site choosealicense.com has a nice summary of a variety of Open Source licenses (all of which can be automatically added to a github project, if you select it). Your job is to break up into groups of three, pull up that page, read through the different licenses, and answer a few simple questions:

1. Suppose your Project 3 uses, but does not modify, the two files I wrote: DrBrownUtil.java (for methods like getRandomColorIdAssignments) and Pos.java (for perhaps deriving some new class).
   1. If I release these files with the GNU GPLv3 License, what are the implications for you releasing your Project 3?
   2. If I release these files with the GNU LGPLv3 License, what are the implications for you releasing your Project 3?
   3. If I release these files with the MIT License, what are the implications for you releasing your Project 3?
2. Suppose your Project 3 modifies and uses the files I wrote: DrBrownUtil.java Pos.java.
   1. If I release these files with the GNU GPLv3 License, what are the implications for you releasing your Project 3?
   2. If I release these files with the GNU LGPLv3 License, what are the implications for you releasing your Project 3?
   3. If I release these files with the MIT License, what are the implications for you releasing your Project 3?
3. Suppose your Project 3 modifies and uses the files I wrote: DrBrownUtil.java Pos.java, but you never distribute it to anyone else, preferring to keep this fabulous game purely to yourself. Assuming I realease my two files under the GPLv3, what are your obligations?
4. Suppose in writing your Project 3 you looked at the source code for the two files I wrote: DrBrownUtil.java Pos.java, and drew inspiration from them, implementing something with similar functionality, but with different code, which you wrote yourself. Assuming I realease my two files under the GPLv3, what are the implications for you releasing your Project 3?
5. Suppose your Project 3 uses, with very minimal changes, the two files I wrote: DrBrownUtil.java Pos.java. Under what license could I release my two files that would allow you to release your Project 3 as if you had written the whole thing entirely on your own? Note: we are only talking about licenses here, not academic honesty!

Warning! There will be at least one final exam question similar to these!