Package licensing

As time goes on, more and more of GAP's development is devoted to packages and non-kernel functions. Therefore, you, as a package author, have an important role to play as to how GAP is used and distributed. For this reason, package authors should be made should be aware of the legal issues regarding the distribution of your packages. (For those really interested in a laywers' take on licensing, you may start by reading the excellent article Understanding Open Source Software by RedHat's General Counsel Mark Webbink.)

We strongly recommend that you (the copyright holder of your software) choose how to license your package. This will help others decide how they may use and distribute your package. By submitting a package to GAP, you are giving implicitly permission for the the GAP website to store your package on its website for others to download. If you wish to allow others to redistribute your package, a license will be very helpful.

A list of open source licenses is at opensource.org, including the license GAP uses, the GNU GPL.

As a package author, we ask you to choose between:

• GNU GPL (or some other free open source license),
• some custom-made license (e.g., anyone else may distribute but no changes or modifications are allowed),
• some other distribution license (e.g., the BSD license).

Notes on choosing a License for the Distribution of Your Package

When you write a GAP package (or any other software), you generally own the copyright to that software. (Exceptions are ``work-for-hire'' situations.) Copyright law is complicated, and I am not a laywer, but the basics world-wide appear to be fairly uniform (at least for most countries). For example, under US copyright law, the rights controlled by the copyright holder are (section 1-106, Title 17, U.S. Code):

• The exclusive right to copy the work;
• The exclusive right to make derivative works;
• The exclusive right to distribute the work;
• The exclusive right to perform the work; and
• The exclusive right to display the work.

Presently, the GAP Council advises all package authors to make clear in the documentation of their package the legal basis on which it is being distributed to users, i.e., a license. It is possible that GAP will soon require all package authors to license their code. As indicated, these are the terms which you give others to copy, modify and redistribute your software (of which you presumably own the copyright) for their purposes.

Some possibilities are listed below.

• Public domain. This essentially means you give up your copyright and allow anyone to do anything with your code. including publishing it under their own name (which would be unethical, of course, but not illegal).

  To do this, simply say:

  I  hereby release all code in my  package into the public domain. 
  

  Technically, this is not a license, since you are simply giving up the legal rights mentioned above.

• New (or "modified") BSD: This allows redistribution and use in source and binary forms, with or without modification, provided that the copyright notice is preserved and the author(s) are not used for endorsement purposes. To do this, under your copyright notuce, simply copy and paste the BSD template and fill out the appropriate blanks.
  If you wish to make it easy for companies to use your code, this is a good license to choose.

• The GPL: GAP itself is distributed under the Gnu Public License version 2 or later, a popular "free software" license which allows users to redistribute it under the same terms, and requires that any software which incorporates GAP or a modified version of GAP (technically, any "derived work") also be distributed under those terms.

  We would encourage you to consider the GPL for your packages, and in fact "GPL version 2 or later (at your preference)" is the most flexible. This allows usrs of your package (e.g., GAP) to relicense under GPLv3 without worrying about compatibility issues.

  To do this, under your copyright notice, place the following:

  This code is released under the GPL version 2 or later (at your preference). 
  For the text of the GPL, please see http://www.gnu.org/licenses/.
  

  Of course, this assumes that that link will be valid years from now, which may or may not be the case. To be more legally precise, you should also place a file called COPYING in your package containing GPL version 2 and GPL version 3.

  GPLv3 is incompatible with version 2, and no GPLv2-incompatible code can be distributed with GAP. However, you can release a (separately distributed) GAP package under GPLv3 if you wish.

  Technically, companies can still use your code for a commercial product under the GPLv2 or GPLv3 (think of SuSE or other commercial linux distribution companies), but in practical terms it appears to be relatively rare (at least, at the time of this writing in 2007). If you want to restrict your code fom being used commercially, choosing the GPL will practically do that, if not legally.

• You might wish to be more restrictive (for instance, forbidding redistribution for profit, or allowing for any redistribution but forbidding any modifications). The SmallGroups library is an example of a package with such a custom-made license. You can add a custom-made license to your README or to a file called {\tt license.txt}, for example.

A legal opinion about GAP packages

• Here is a quotation from the GPL FAQ on the Free Software Foundation website which is relevant to this issue.

  What is the difference between "mere aggregation" and "combining two modules
  into one program"?
  
  
  Mere aggregation of two programs means putting them side by side on the
  same CD-ROM or hard disk. We use this term in the case where they are separate
  programs, not parts of a single program. In this case, if one of the 
  programs is covered by the GPL, it has no effect on the other program.
  
  Combining two modules means connecting them together so that they form a
  single larger program. If either part is covered by the GPL, the whole 
  combination must also be released under the GPL--if you can't, or won't, 
  do that, you may not combine them.
  
      What constitutes combining two parts into one program? This is a legal 
  question, which ultimately judges will decide. We believe that a proper 
  criterion depends both on the mechanism of communication (exec, pipes, rpc, 
  function calls within a shared address space, etc.) and the semantics of the 
  communication (what kinds of information are interchanged).
  
      If the modules are included in the same executable file, they are 
  definitely combined in one program. If modules are designed to run linked 
  together in a shared address space, that almost surely means combining them 
  into one program.
  
      By contrast, pipes, sockets and command-line arguments are communication 
  mechanisms normally used between two separate programs. So when they are 
  used for communication, the modules normally are separate programs. But 
  if the semantics of the communication are intimate enough, exchanging 
  complex internal data structures, that too could be a basis to consider 
  the two parts as combined into a larger program. 
  
  - http://www.gnu.org/licenses/gpl-faq.html#MereAggregation
  
  

  (this FAQ entry is copyright the FSF)

• This is a (slightly edited) quote from an email a licensing advisor Yoni Rabkin (licensing@fsf.org) on GAP package licensing questions.

  It is my understanding that a GAP package is intended to be a
  component of GAP, and should be considered a derivative of
  GAP. Therefore, GAP packages should be licensed under the terms of the
  GNU GPL regardless of if it is distributing with GAP or not.
  
  Another issue is that according to the terms of the GPL, distributing
  a GAP package alongside GAP is not mere aggregation and is in-itself a
  problem for downstream recipients since they do not receive all the
  freedoms the original distributor of GAP has.
  
  For reference, see the last paragraph of section 2 of GPL version 2, and
  the last paragraph of section 5 of GPL version 3 (I mention both
  versions of the GPL since GAP is licensed under version 2 of the GPL
  with the "...or (at your option) any later version" clause.
  

  This is from an email to me (David Joyner) dated Oct 11, 2007. (Yoni's signature is careful to say "I am not a lawyer, the above is not legal advice.") You may disagree with this opinion. (For example, you might argue that your GAP package is really a standalone program or database which you are happy to allow GAP users to make use of and is not intended to be a component of GAP.) However, if you agree then this email suggests that you should choose "the GPL version 2 or later" for your package.

• The Open Source Initiative has investigated free licenses. A list of OSI-approved licenses can be found at OSI.

• Mark Webbink, Senior Vice President and General Counsel of Red Hat, Inc, has written an excellent article explaining the basics at: "Understanding Open Source Software" New South Wales Society for Computers and the Law Journal, March 2003, article.

• The Free Software Foundation has a lot more information about the GPL and other licenses: FSF.