Appendix: What you should know about open-source software licenses


Support for extensions using XUL/XPCOM or the Add-on SDK was removed in Firefox 57, released November 2017. As there is no supported version of Firefox enabling these technologies, this page will be removed by December 2020.

Add-ons using the techniques described in this document are considered a legacy technology in Firefox. Don't use these techniques to develop new add-ons. Use WebExtensions instead. If you maintain an add-on which uses the techniques described here, consider migrating it to use WebExtensions.

Starting from Firefox 53, no new legacy add-ons will be accepted on (AMO) for desktop Firefox and Firefox for Android.

Starting from Firefox 57, only extensions developed using WebExtensions APIs will be supported on Desktop Firefox and Firefox for Android.

Even before Firefox 57, changes coming up in the Firefox platform will break many legacy extensions. These changes include multiprocess Firefox (e10s), sandboxing, and multiple content processes. Legacy extensions that are affected by these changes should migrate to use WebExtensions APIs if they can. See the "Compatibility Milestones" document for more information.

A wiki page containing resources, migration paths, office hours, and more, is available to help developers transition to the new technologies.


Appendix: What you should know about open-source software licenses


This page is not complete.


This document was authored by Yutaka Kachi and was originally published in Japanese for the Firefox Developers Conference Summer 2007.

Any discussion of open-source software deserves an explanation of licensing-related issues. In this chapter, I’ll explain some of the basics: what open-source software (OSS) licenses are, what types of licenses exist, and when they’re appropriate.

  • What is an OSS license?
  • What are the different kinds of OSS licenses and what are their key characteristics?
  • Applying an OSS license
  • OSS licensing today and in the future
  • References

What is an OSS license?

An open-source software license is a statement that anyone is free to use your source code in whatever way they want. The Open Source Definition states what conditions the OSS license must satisfy. Perhaps surprisingly, these licenses enforce their terms through the exercise of copyright.

All software licenses, not just open source, enforce their terms based on copyright. It’s easiest to understand if we think of it as being implemented in terms of the copyright framework.

To put it very broadly, copyright is a creator’s right to decide how a work is published and how it is used. In countries that are signatories to the Berne Convention (which is most countries, including Japan, China, India, Australia, the Americas, and all of Europe) this right is automatic, and requires no declaration or registration.

The different meanings of the word “use”

When we talk about the ways an author uses a work, we mean printing or recording and distributing it. An author’s use of a printed piece, like a book or magazine, is printing and publishing it.

Reading a printed piece, while it is a use of it, is a “use” in a much weaker sense of the word. As far as the author is concerned, this is an unrelated application of the work. This is what we might call the reader’s use of the work, and it requires no permission from the author. In some situations, such as education or citation, use in the strong, authorial sense is permitted to readers.

Any discussion of copyright eventually turns to the fact that some uses are prohibited, so it’s useful to understand what uses are unrestricted.

Range of uses
  Restricted to author Unrestricted
Book Print, publish, revise Read
Music Record, perform, revise Listen
Movie Distribute, screen, revise Watch
Software Copy, distribute, modify Execute

Licenses are a use permit

In order to use (in the authorial sense) a copyrighted work, the user must either receive a use permit from the copyright holder, or must be assigned partial rights by the author.

This use permit for a copyrighted work is called a license. When we talk about a driver’s license, we mean a permit to drive a car. When we talk about a license to kill, we mean James Bond.

A license on a copyrighted work is a use permit that says “it’s OK to use this work within this scope, as long as you follow these conditions.” Those conditions could be something like “if you pay me money” or “you can print up to 10,000 copies.”

Software licenses

Software is subject to copyright law. In order to use it (in the authorial sense), you need permission from the copyright holder.

How software licenses work

In order to duplicate, distribute, or modify software, you need a use permit.

Duplicating software would be burning CD-Rs or downloading from the Internet (copying from server to client). Distributing software would be selling that CD-R or publishing the software on the Internet. Modifying software would be changing its functionality or adding new functions.

Duplication: copying a piece of software

Distribution: passing a piece of software to another person

Modification: modifying the software

A typical software license will grant these permissions in return for a fee, and will still restrict some normally unrestricted uses. The software that Microsoft sells, such as Windows, comes with a license that permits only limited duplication in exchange for a fee, so, although customers can install it on their computers, they cannot modify it. And essential freedoms, such as reverse-engineering, are also restricted.

This use permit is displayed when you install the software. When the user clicks “I agree,” the installation process finishes.

Software range of uses

Restricted to author


Software license >> Usable within permitted scope   Restricted

Use within permitted scope


FIXME: Wow, the table is weird!

So what’s an OSS license?

So now you’re wondering, what conditions does an OSS license place on software? This can be briefly answered by the Open Source Definition, which was determined by the Open Source Initiative (OSI).

This covers three rights and six conditions. What is important to us now is the following three rights:

Open source rights:

  • A user can create and distribute copies of the source code;
  • A user can obtain a program’s source code;
  • A user can modify the source code.

Any OSS license will include these rights. The user is free to use (duplicate, distribute, and modify) the source code, following certain conditions. This means that the author is granting users the use of the work in the strong, authorial sense, and when I write “use” in the rest of this document it is generally in that sense.

These conditions will vary from one license to the next, but the Open Source Definition stipulates the following minimum conditions:

  • The integrity of the author’s source code must be preserved;
  • No discrimination may be made against individuals or organizations;
  • No discrimination may be made based on field of endeavor;
  • No additional licensing can be required when redistributing;
  • License must not be specific to a product;
  • License must not interfere with other software.

The “No discrimination may be made against individuals or organizations” rule means that you cannot prohibit it from any particular country. The “No discrimination may be made based on field of endeavor” rule means that you cannot prevent it from being used in warfare. The “No additional licensing can be required when redistributing” rule means that you cannot prohibit the software’s use from anyone who does not buy a separate license.

Because the OSS license is intended to foster source-code reuse and mutual development, it avoids restrictions on source-code duplication, distribution, and modification to the greatest extent possible.

Types of OSS licenses and their characteristics

The details of OSS licenses vary from one license to the next. I’ll look at three representative licenses here, and explain some of their features and relevant points.

Most attempts at explaining open source start with the GPL. This is the longest, most complicated, and hardest to understand. So instead, I’m going to start with the simplest, the Modified BSD license.

The table below shows a few well-known software titles and their licenses

License Representative software titles
Modified BSD FreeBSD, NetBSD, OpenBSD
MPL Firefox, Thunderbird (also triple-licensed MPL/LGPL/GPL)
GPL Linux kernel, GIMP

Modified BSD license

This license permits free duplication, distribution, and modification provided that a copyright statement and liability disclaimer are included. Modifications to BSD-licensed software can be published under commercial licenses or other different licenses. This is often just called the BSD license.

The MIT/X11 license is similar in substance.

License terms

This license has the following simple terms. It’s short, so read it carefully.

<Program name>

Copyright (c) <year>, <copyright holder>

All rights reserved.

1. Redistribution  and use in source  and binary forms, with  or without
modification, are  permitted provided that the  following conditions are

   1. Redistributions  of source  code must  retain the  above copyright
notice, this list of conditions and the following disclaimer.

   2. Redistributions in binary form  must reproduce the above copyright
notice,  this list  of conditions  and the  following disclaimer  in the
documentation and/or other materials provided with the distribution.

      2. This software is provided "as  is" and without warranty. Use at
your own risk.

   3.  Neither the  name  of the  <organization> nor  the  names of  its
   contributors may be used to  endorse or promote products derived from
   this software without specific prior written permission.

Pros and cons

The Modified BSD license was originally created by the University of California at Berkeley for distributing a Unix-like operating system. Because it has so few restrictions, it is often used by universities and the like for the products of research.

However, the fact that software derived from BSD-licensed code can be redistributed under a different license creates the possibility that it will be wrapped in another proprietary program.

The deleted advertising clause

The original BSD license contained an advertising clause, which stated that “any advertising for software using an modification of this source code must display the name of the original developer.”

This clause has been removed. The Modified BSD license is the version that does not include the advertising clause.

Mozilla Public License (MPL)

This is an OSS license created by Netscape and the Mozilla Organization. Netscape created it for its open-source web browser.

The Common Public License (CPL) and Eclipse Public License (EPL) are similar in substance. Because the CPL is written in such a way that it does not mention any software or company by name, you can use the CPL if you plan to use this kind of licensing.

License characteristics

If you modify source code that was published under this license, you are obliged to release it under the same license. However, if you develop an original module as an addition to it, that restriction does not apply. So plug-ins and the like can be released under different licenses.

Also, because source code released under this license may include patented code, that fact must be disclosed.

Pros and cons

I consider the MPL to be an extremely well balanced OSS license. It makes explicit that any modifications of code released under it must also be released under the same license, while setting practical limits.

Also, by requiring patent disclosures, it avoids the problem of submarine patents.

GNU General Public License (GPL) & GNU Lesser General Public License (LGPL)

The Free Software Foundation (FSF) created the GPL and LGPL licenses as licenses applicable to software that can be used freely.

Compared to the GPL, the LGPL applies a narrower interpretation of derivative works. A derivative work is a modified version of the original source code.

At the time of this writing, almost all applications of the GPL were of GPLv2, the revision that was made in 1991. The current version is GPLv3.

License characteristics

The GPL is an application of the “copyleft” principle that derivative works must be distributed under the same terms as the original. In short, any modification to GPL-licensed software must also be released under the GPL license.

The GPL does not state whether linked files and the like are considered “derivative works under copyright law.” The LGPL does make the declaration below. In short, under the GPL, statically or dynamically linked libraries both could be interpreted as derivative works.

When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library.

Under the LGPL, a program that calls a library does not need to be published as a derivative work. Note that the FSF currently does not recommend applying the LGPL to libraries.

Pros and cons

Programs that have been released under the GPL mandate that any derivative works also be released under the GPL, so the code cannot be wrapped in a proprietary program. However, compared to the BSD license, its terms are complicated, and can be difficult for users to understand.

Points to understand about OSS licenses

I’ll explain some important aspects of OSS licensing that you should be aware of.

You don’t have to give it away

There’s nothing in an OSS license that prevents you from charging money for software. One of the advantages of OSS is that it emphasizes that software can be distributed for free, but it can also be distributed for money.

Of course, customers who buys the software can then redistribute it themselves, so unless you provide some added value, you’ll have a hard time building a business.

Scope of modifications

In the open-source world, “copyleft” is when you require that any modifications to your source code must also be released under the same terms.

The following tasks can be considered modifications

Revision: rewriting the source code;

Addition: Adding new code, or adding parts of it to other code;

Linkage: Creating static or dynamic links.

Depending on what kind of modifications you envision, you can choose your license as follows.

Table: What tasks are considered modifications?

License Revision Addition Static link Dynamic link

If you release software under the GPL, LGPL, or MPL, any modifications to it must also be released. However, if the modified version is never distributed, it need not be released.

Copyleft is not required

A common misconception regarding open source is that any modification made to open-source code must also be released as open source.

This condition only applies under some open-source licenses (such as the GPL). This condition, which is commonly referred to as “copyleft,” mandates that any modification to the source code, or any new code combined with the source code, must be released under the same kind of license.

If copyleft is not one of the conditions (as is the case with the Modified BSD license), the modified program can be released under a different license, and can even be sold without any open-source license at all.

Dual licensing

Some open-source software uses “dual licensing.” In this situation, the software is released with multiple licenses, and the user decides which one to apply. In most cases, this means GPL and another license with looser restrictions. For example, MySQL is published under a dual license: GPL and a commercial license.

OSS license

Can duplicate

Can distribute

Can modify

Commercial license

Install on one machine only

Unauthorized copies prohibited

No modifications

Payment required

Certain uses are permitted depending on which license you choose

English version is the official text

Nearly all OSS licenses take English as their official texts. Japanese versions, for example, are mentioned only as reference translations. Thanks to the Internet, published source code can be used all over the world, so the language that the most people will be able to understand is chosen as the language for the license (although this may reflect a Western bias).

Applying an OSS license

In this section, I will explain practical details of applying a license when you are using OSS source code, and participating in open-source projects.

Circumstances of application

First I’ll explain what kind of license to use depending on whether you are modifying existing OSS source code or writing original software.

Check the license

If you are working from existing code, first check its license. If you have the source code at hand, open it and take a look. Almost all module files will give the license text or license declaration at the top. Source code using Modified BSD or MPL will give the text of the license at the top; if it’s GPL or LGPL, there will be a license declaration. The full text of the license should also appear packaged in the same archive as the source code.

If you’ve modified existing source code

If you are modifying existing source code, you need to judge whether or not to publish your revised version at all. See the previously mentioned “scope of modification.” Using the same license as the existing work is a straightforward option.

If you are not going to be distributing the modified software at all, and will only be using it within your own organization, you need not release it. For example, if you are using an modified version of Linux as the operating system for a web server, it’s fine if you don’t release it.

Picking a license for original works

If you are releasing source code you have developed yourself, you need to pick a license. But what kind of license? Yukihiro Matsumoto, the developer behind the Ruby scripting language, published a “free software license diagnostic” in his personal blog. It asks a series of questions, and your responses help you pick the right license. In brief, it goes like this:

  1. Best not to even try: Creating a new license for your own use → Support is a nightmare.
  2. Do you hate the idea of your software ever being embedded in a commercial package? → Choose the GPL.
  3. Do you enthusiastically support the Free Software movement? → Choose the GPL.
  4. Do you want your code to be embedded in a certain OSS project? → Choose the same license as that project.

None of the above: Choose the Modified BSD license.

The title hints at Matsumoto’s diagnostic approach, since it mentions “free software.” This is slightly different from open source. (Matsumoto updated his free software license diagnostic for a special open-source section in the January 2007 edition of Softbank’s Open Source magazine.) If a company is considering releasing its own software as open source, it should consider dual-licensing or the CPL.

Applying a license to original works

If you want to release your own code as open-source, here’s what you do next.

  1. Insert the license declaration in the top of every file in your source code;
  2. Include the full text of the license in your source-code archive;
  3. Place the source code on a website or otherwise make it accessible;
  4. Tell all your friends.

If you are using the Modified BSD License or MPL, place the full text in the top, not just the license declaration. If you are using the GPL or LGPL, use the declaration at the end of the license’s full text as a template and insert that. See below.

GPL License Declaration Template

If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software that everyone can redistribute and change under these terms.

To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.

<one line to give the program's name and a brief idea of what it does.>

Copyright (C) <year> <name of author>

This program is free software: you  can redistribute it and/or modify it
under the  terms of the GNU  General Public License as  published by the
Free Software Foundation,  either version 3 of the License,  or (at your
option) any later version.

This  program  is distributed  in  the  hope  that  it will  be  useful,
but  WITHOUT  ANY  WARRANTY;  without   even  the  implied  warranty  of
Public License for more details.

You should have received a copy  of the GNU General Public License along
with this program. If not, see <>.

Caveats on license selection

Be aware of the following points whether you’re modifying existing source code or selecting a license for the first time.

You cannot rewrite an existing license

If you select any existing OSS license and rewrite any part of it on your own, you should not use the same license name as the original. This would be a source of confusion for users and may be prohibited by the terms of the license.

Can you change the type of license?

Depending on what type of license you choose in the first place, you can change it as follows:

  • GPL → GPL
  • LGPL → GPL or LGPL
  • MPL → MPL
  • Modified BSD → other license
  • Dual license → either one or both sides of a dual license

Beware of mixed licenses

When using existing source code, check to see whether there is a different license mixed in the source. Depending on the license, mixing them may be prohibited.

For example, source code with a plain GPL or MPL license cannot be linked to or amended with other source code using any other kind of license. This is because the MPL and GPL include provisions contradicting this. However, source code that is dual-licensed with either the MPL or GPL allows additions or linkages with GPL source code.

OSS licensing today and in the future

Finally, let’s look at the current state of affairs in OSS licensing and some of the issues it faces.

Non-licensing factors

When we consider the application and upkeep of a license, there are some non-license factors to consider as well.

When giving feedback on a project

If you want to contribute modified source code to an existing project, you need to familiarize yourself with that project’s procedure for submitting modified code.

Let’s consider the case where you’ve discovered a bug in some OSS code. You don’t just want to patch the instance of the program you’re running, you want to publish the patch to benefit other people. And you don’t want each person using that code to be forced to apply the patch individually—that would be a lot of duplicated effort. Instead, you want to roll the patch into the source code being maintained by the OSS project team.

But the team may not permit just anyone to contribute additional code whenever they want—if they did, then viruses and back-doors could wind up being distributed in the official version.

So OSS gives you the freedom to duplicate, distribute, and modify source code, but if you want to contribute those modifications back to the core project, the project’s acceptance is an entirely different matter.

Developers who contribute to the free office suite are requested to enter into a joint copyright assignment with Sun Microsystems, the initial developer. Despite the fact that different modules have different copyright holders, and overall license management is complicated, by taking this contract as a kind of proxy letter, Sun is able to make changes to the license by itself.

Trademarks and patents

Software is treated as a copyrighted work under copyright law, but the rights that attend software are not limited to copyright: software is also covered by patent and trademark law. While you can freely duplicate, distribute, and modify copyrighted open-source software, it’s typical that with trademarked or patented works, you can’t do whatever you want with them. There are companies that have built businesses on open source by taking advantage of this fact.

Red Hat Enterprise Linux (RHEL) cannot be copied or distributed with the Redhat trademark in place. A number of RHEL clones have appeared, such as CentOS, where the trademarked parts have been scrubbed away by a community effort.

The Firefox web browser, developed by the Mozilla Foundation, does not permit modifications of its name or trademarked icon. For this reason, the Debian project, which distributes free software as a volunteer effort, has a browser based on Firefox, but with a different name and logo.

Document licenses

As open-source software grows in popularity, people have begun thinking about applying its principles to content other than software, to allow anyone to duplicate, distribute, and modify it freely.

Because OSS licenses aren’t directly applicable to these other media, a number of other licenses for documents and other resources have appeared, such as the following:

  • GNU Free Documentation License (GFDL)
  • Creative Commons

The GFDL is a license for documents and was created by the FSF, the same people behind the GPL and LGPL. Wikipedia uses this license. The Debian project, however, considers its terms too harsh, and that it does not allow for the free distribution of documents.

Creative Commons is a flexible copyright licensing scheme that applies not just to documents but other creative works, including music, pictures, video, etc. It has the following characteristics:

  • Gives creators flexibility when selecting and applying terms;
  • Terms of use stated in easy-to-understand language;
  • Licensing conditions conform with current copyright laws;
  • Also has an RDF schema for attaching metadata.

It is particularly convenient in the way that it allows creators to decide whether to permit commercial uses or not, whether to enforce copyleft or not, etc. This is easy to use when you are releasing new documents.

The future of GPL

Despite being buffeted by circumstances, open source is becoming more and more solidly established. But the computer ecosystem is changing in fundamental ways, with software patents, DRM, internationally applied licenses, and other new challenges coming into focus.

To respond to these challenges, the Free Software Foundation has revised the GPL to Version 3. Draft 1 was first circulated in September 2006, and after four drafts, it was published in June 2007. Linus Torvalds, a developer behind the Linux kernel, raised objections to GPLv3 in the draft process, and Linux continues to useGPLv2.

In any case, the choice of license is up to the copyright holder—the developer. It’s important to thoroughly understand the license you choose and make a choice that strikes a good balance in terms of utility to the creator and the user.


The Open Source Definition

The FreeBSD Copyright

Mozilla Public License


Common Public License

GNU General Public License (GPL)

GNU Lesser General Public License (LGPL)

Various licenses and comments about them

The BSD License Problem

The free software license diagnostic (in Japanese) Joint Copyright Assignment (JCA)

GNU Free Documentation License (GFDL)

Creative Commons

GNU GPLv3 Second Discussion Draft

GNU GPLv3 Third Discussion Draft

GNU GPLv3 "Last Call" Discussion Draft

Official support for OSS

Japan’s Ministry of Economy, Trade, and Industry has issued “Guidelines when Considering Deploying Open-Source Software.” This report, which was prepared by the Software Information Center study group as part of the Information-Technology Promotion Agency’s (IPA) “Platform-technology development and businesses relating to electronic commerce” project. This report is available online (in Japanese) at

The IPA has also established an Open-Source Software Center to promote and cultivate OSS