Jump to content

FOSS Licensing/Scenarios

Add links
From Wikibooks, open books for an open world

Different stakeholders will have different uses for FOSS. A developer might use a program more intensively than an end-user, which means that the developer’s activities might be subject to more restrictions than an end-user. The following section tries to provide some scenarios as examples to explain the different legal issues that may arise for different stakeholders.

End-user (Individual/Business/Government)

[edit | edit source]

Abul is a public high school teacher. His school cannot afford expensive license fees for proprietary office applications. Although proprietary software companies offer special rates for schools, Abul wanted to find an alternative solution to reduce students’ dependence on proprietary software. His friend, Nazlee, a programmer who has participated in FOSS projects, introduced him to a FOSS office application. Abul and his colleagues then downloaded FOSS office solutions and taught students both proprietary and FOSS applications. He is satisfied with the performance and introduced Nazlee’s program to his colleagues. Gradually, the school administrative body began to use the FOSS solution for administrative work.

In this case, neither Abul (an individual) nor his school (a public government body) made any modification to the software that they downloaded from the Web. They were simply end-users.

The situation for end-users is relatively simple. The end-user of a software program may be an individual, a government body, or a business entity. These individual persons or legal entities may have different reasons to use FOSS. Some may be trying to find a cheaper solution or a solution that suits their needs better; others may wish to use FOSS for better customization; still others may wish to reduce their dependence on proprietary companies.

Legal issues involved
The way end-users use FOSS solutions might not be very different from the way they use proprietary solutions. They download a copy of a FOSS solution or purchase a copy (usually in exchange for some support and services), install it in the computer (thus making a copy on the hard disk), run the program, and have its functions serve their needs. The rights that are of concern here are the right to make copies of the program and to run it. (The act of running a program may also count as an act of making copy, but it is stated differently in some FOSS licenses. For example, the GNU GPL has no restrictions on the running of the GPL-ed program but does regulate the act of making a copy.) These rights are granted by all FOSS licenses. Thus there are fewer legal disputes involving end-users. However, end-users do need to consider some issues.
  • Issue 1: Technical Support Since an end-user might not be a computer whiz, she might have concerns regarding technical support when choosing a FOSS solution. Thus, instead of simply downloading a copy of the FOSS solution for free, she might choose to purchase a box of FOSS in a shop where a proprietary solution is also available, sometimes at approximately the same price. The difference is that when purchasing, let’s say, a commercial Linux distribution in the store, the end-user is not paying for the license fee, but for the service and support. Additional copies of the software and FOSS documentation may be distributed freely, e.g. to pupils, or installed on other computers; such additional users or installations are usually not covered by the support, unless explicitly included in the agreement. When the term of service expires, the end-user can choose to pay for another term of service, or ask other available providers for similar services.
  • Issue 2: Customization When existing FOSS solutions do not fit their needs, end-users might need to ask individual developers or vendors to customize the solutions. In such cases, since end-users may not be technically savvy enough to detect possible infringements, they may wish to have a written clause in the contract ensuring that the vendor or developer will take on the entire responsibility for any possible copyright infringement, and will compensate for any possible losses that may be caused by allegations of infringement. The buyer is free to add these clauses to the contract when negotiating with the vendor or developer.
  • Issue 3: Government Procurement Since FOSS licenses are different from traditional software licenses, governments should be particularly aware of the differences when they open a bid for software solutions or sign a contract with vendors. Existing government bid and contract templates may have been drafted under the traditional proprietary model of traditional copyright law, and have to be examined, or revised, if they fail to treat FOSS and proprietary software equally.

Developer (Individual, Business)

[edit | edit source]

Developers (individuals and business entities) need to be more careful with the terms and conditions of different licenses while using FOSS. Developers usually not only run and copy the software, but also create derivative works from the software, and distribute these derivative works together with the original program. Therefore, for developers to contribute to the development of a certain FOSS program, it is essential to have the rights to run the program, to make copies, to distribute the program and to prepare derivative works.

These rights are granted by all FOSS licenses, for these essential rights are considered important both in the Free Software Definition and the Open Source Definition. Nevertheless, different FOSS licenses may have different restrictions on exercising these rights, especially on creating and distributing derivative works. Developers should pay particular attention to this, and consult their lawyers on their specific situation when needed.

There are different considerations when a developer participates in different stages of software development.

When Starting a New Project

[edit | edit source]

Abul’s colleague Jolly is the school librarian. The school library is not that large, but it is open to villagers. Jolly sought her friend’s help to write a program that would enable her to keep an accurate record of the books in the library.

  • Legal issues involved — choosing a license of one’s own
Developers
What does this project mean to me and to others? How do I want others to be involved? What do FOSS licenses say? What are the differences between FOSS licenses?
The situation is relatively simple if the developer is starting a new project without using any existing modules, since she will not have to look through the licenses of existing modules that she might have used.
However, starting a new project is not an easy task either. The different characteristics of the FOSS license she chooses will have a significant influence on the possible development path of the project. The developer should define her main concerns before choosing a license.
For example, if the developer is a supporter of copyleft, she may stick with the GNU GPL or the LGPL. If the developer thinks she doesn’t need to require people to license their modified works under FOSS licenses, a BSD-style license would be appropriate. Or when the developer thinks it is better to control the development in a firm and central line, she might not be interested in BSD style licenses. But if forking is preferred in the future development, BSD style licenses may be a better choice.
Developer
Can I change my mind after licensing my project?
The copyright holder of a project can always decide to choose another license for the program, even when the previous versions have already been licensed under certain FOSS licenses. This will not affect the rights of the recipients of the previous versions since license grants are irrevocable. The situation will be more complicated if contributions from the community have been incorporated into the newer version, which means that these other contributors may claim copyright to certain pieces of the code in the newer version. In this case, unless there is prior agreement, the license must be chosen by all contributors.
Developer
I don’t like any of the existing FOSS licenses. Can I start a new one?
Though there are already many FOSS licenses, it is possible that a developer will find that she does not like any of the available licenses. As long as the developer owns the code, she is entitled to choose any license for the project, including a new one that she drafts by herself. However, creating a new FOSS license requires legal knowledge and skill to avoid vagueness and loopholes. Also, there are already many FOSS licenses and the transaction cost for understanding these licenses is high. Creating a new license is not recommended unless a developer has strong reasons to do so.

When Modifying an Existing Module

[edit | edit source]

The office application Abul and his school are using has an English interface. It does not support the local language. Using an English interface might not pose a problem for high school students. However, it is difficult when Abul tried to teach villagers. He consulted Nazlee about the problem. Nazlee has constantly contributed to FOSS programs and is also quite familiar with the source code of the office application. She discussed this with a few friends and, as a team, they began to localize the application.

  • Legal issues involved: Ascertain the license of the program to be modified

When a developer tries to modify an existing module, and when the modification is not solely for her own use but for further distribution (e.g., localizing a project), she needs to first identify the license of the module.

Developers
Under the license, what are the rights I am granted and what are the restrictions in exercising those rights?
For example, on the distribution of a FOSS work, some FOSS licenses (e.g., the GNU GPL, the LGPL) may require distributors to provide both object code and source code, or at least provide the information on how to access the source code. On modifying a FOSS work, some FOSS licenses (e.g., GNU GPL, LGPL, BSD) may require the modifier to provide documentation of the changes being made. On distributing the derivative work, copyleft licenses require derivative works to be licensed under the same license as the original work, while other FOSS licenses allow the modifier to choose a different license (BSD, MIT).
If Nazlee and her friends are trying to localize the dual-licensed OpenOffice, and they decide to use the one under the GNU GPL, then the localized OpenOffice would also be GPL-ed. Using the original license scheme (dual-licensing) the localizations are easily integrated in the original project and can then at least partly be maintained there. Using a more restrictive scheme means that the localizations probably must be maintained locally. Allowing additional licenses (e.g. to later be able to use part of the work in another project) is usually unproblematic.
Some FOSS licenses (e.g., the MIT License) may allow users to sublicense the original work. This means that when distributing the verbatim copy of the original work, within the scope granted by the original copyright holder, the distributor may choose a different license and become a licensor him/herself. In such cases, when a developer creates a derivative work and distributes it together with the original work, he/she can choose to become a licensor of both the original work and the derivative work, which simplifies the legal relations to one that exists only between the two parties. If a sublicense is not allowed, people who receive the modified work would have two licensors for this piece of work. The licensor of the original work will be the author of the original work, while the licensor of the derivative work will be the developer who prepared the derivative work.

When Integrating Different FOSS Modules into One Service

[edit | edit source]

Nazlee works in AA Software Inc. To better oversee the many different projects that the company is developing, the team built a project management system by integrating different FOSS modules. The management system is only for internal use now, but since it is pretty handy, the company also plans to distribute it commercially in the future.

FOSS licenses do not impose restrictions on modifications that are made for internal use. But when a public distribution is created based on these modifications, the developer must consider all the licenses of the modules being used.

  • Legal issues involved: Identify the licenses of the programs being integrated, and see if these licenses are compatible.
When publishing something that integrates several different modules, it is essential to ascertain the licenses of each module. If they happen to be licensed under the same license, such as the GNU GPL, then the integrated system would be licensed under that license. The situation is similar when all modules are licensed under the BSD License. But in this second case, because the BSD license is more permissive, AA would be able to choose another FOSS license or a proprietary license for the modified modules and the integrated system. (The permissive nature of the BSD license allows AA to "narrow down" the licence by adding further conditions, while the GPL does not allow this.)
However, if some of the modules have different licenses, then AA will have to look at the compatibility of these licenses. When two licenses are compatible, the two modules licensed under the two licenses can be combined into a larger work while complying with both licenses.[1]
When combining a GPL-ed program and BSD-ed (GPL-compatible) into a larger program, the larger program will have to be GPL-ed to meet both the requirement of the GPL-ed program and BSD-ed program. If some of the modules are GPL-ed but other modules are GPL-incompatible, AA must decide which module is more important for them and replace the other one with a module with a compatible license.[2]
The licenses used in different modules and the way they are combined together would determine how the integrated system can be licensed and distributed.
  • Other considerations – choice of law and choice of venue clauses
Finally, for those who are able to choose licenses for their programs, either because they started their own programs or they are allowed to choose licenses for the derivative works they prepared, they should be aware that many OSI-approved licenses are developed by proprietary software companies. Some are designed to meet their company policy and strategy, and thus might not be a good choice for developers in general. Some technical issues, such as clauses on choice of law and of venue (which could be found in the Qt Public License, the Mozilla Public License, the Common Public License, etc.), may become significant when a lawsuit is brought up.

Vendor/Producer (Business)

[edit | edit source]

Nazlee and her friends have made the localized version of the FOSS office version available. AA Software Inc. is interested in this application. They have also developed some other small but useful programs for administrative work. They package the localized office together with their own programs (licensed under their proprietary license). The package is a big hit. A few months later, AA also decides to commercially distribute the project management system that they had integrated from different FOSS modules.

Mere distribution
In this situation, both FOSS and proprietary programs are distributed in one package. For the FOSS application, AA is merely a distributor, and must distribute it as its FOSS license requires. For proprietary programs, AA holds the copyright and is able to choose the license and ways of distribution. It is all right to put FOSS and proprietary applications into one distribution package, such as one CD-ROM, if the applications function separately and do not link together to create any derivative work.
Distribution of integrated systems
In the case of an integrated system distribution, what is key are the licenses of the different integrated modules and the ways in which the modules are combined. As explained earlier, AA needs to first make sure that the licenses of the different modules allow AA to combine them. These licenses will also determine the ways by which AA can distribute the integrated system.
Other considerations – drivers and certifications
One difficulty that FOSS vendors might encounter is that hardware vendors may not be aware of FOSS software and thus fail to provide drivers that will enable FOSS applications to work on the hardware. It is important to promote the idea of FOSS among hardware vendors. This will be easier when there is a larger group of FOSS users.

Likewise, certification is sometimes needed for FOSS to work properly with specific proprietary software. A larger FOSS user group will encourage proprietary software companies to certify FOSS applications that might be used together with their programs.

Other considerations – FOSS used in embedded systems or devices
FOSS is also used in embedded systems in electronic devices, such as cell phones, hand-held devices, digital cameras and DVD players. The use of FOSS may help device manufactures to lower their cost when developing new products. The distribution of the device is different from the distribution of the FOSS itself. With regard to the latter, the rules of specific licenses still apply.

The GPL version 3 mandates making available not only the source code for embedded devices, but also describing how to install a locally modified version of the software into the device, unless the device cannot be updated (e.g. because of having the software in ROM).

Other considerations – Source code
Many FOSS licenses insist on the source code being available. This must be the actual source code for the compiled program that has been distributed. As changes to the software can introduce subtle bugs making it unusable in the setting where it is used, it is not enough to provide the latest version of the source code. The simplest way not to have to keep track on every version is to always distribute the source code together with the compiled software (or keep them available together, if distributed by offering downloads).

Government-sponsored Projects

[edit | edit source]

FOSS movements and rapid FOSS developments have received attention not just from the FOSS community, but also from academics and policy-makers. In some Asian countries, governments work with PC manufactures/vendors to provide affordable PCs bundled with FOSS operating systems and office applications.[3] Governments also support FOSS development, generate FOSS-related projects and promote FOSS as a national technology and industrial policy.[4] But long before governments began to notice the potential of FOSS and developed a clear position on it, some government-affiliated academic institutes have already been working on FOSS-related projects.

The FSF-maintained FAQs about the GNU GPL also list questions about whether the United States Government could release a program under the GNU GPL or release improvements to a GPL-ed program.[5] Situations may differ from country to country and from case to case under different government regulations in different countries. Most government regulations on government-sponsored projects are usually drafted under their domestic copyright and patent law and might be informed by a more protectionist mentality and thus be unfamiliar, or even unfriendly, to FOSS licensing and development models.

Below are two cases of government-funded FOSS studies. The first one is about FOSS-related studies made in a government research institute without related government policy, while the second one is about a national FOSS project.

Government-funded FOSS Projects: Cases from the Asia-Pacific

[edit | edit source]

A FOSS Project under a Government-affiliated Research Institute: Multi-Lingual Editor, Japan

[edit | edit source]

Emacs is a multilingual text editor first developed by Richard Stallman at MIT. After the GNU project started in 1984, the development of GNU Emacs was started and it was first released in 1985, under the GNU GPL.

The Japanese governmental research institute, Eletrotechnical Laboratory (ETL),[6] began to work on the multilingual information processing and integration of GNU Emacs and Mule (multilingual text editor based on Emacs and later merged into GNU Emacs as MULE) in the mid-1990s, but there were various copyright issues.

ETL was a government research institute, and the licensing model in the GNU GPL is very different from Japanese copyright law, so no one was able to decide whether ETL could assign the code to the FSF and release the code under the GNU GPL. As a result, ETL never officially released the code but released the trial versions instead. More negotiations between ETL and FSF took place later, and resulted in a special agreement. The FSF agreed not to require ETL to assign the copyright of the modified code to the FSF, and ETL agreed to grant FSF the right to use the code. This was the first time that part of the code in Emacs did not belong to the FSF.

In 2001, ETL was reorganized into the National Institute of Advanced Industrial Science and Technology (AIST). Although AIST is still a government-funded institute, it is an independent organization and its assets are not national property. It seemed that AIST would be able to release the code under the GNU GPL officially. But, initially, it was still very difficult for the higher levels of AIST to make a final decision. It took them another year of internal negotiation to decide that AIST was entitled to release their works and choose the licenses of their works. It was also not easy to convince people about the advantage of adopting the GNU GPL. According to Dr Kenichi Handa, a senior researcher in AIST, it was never clear what convinced the AIST management to make the final decision.

This happened before the Japanese Government had formed a clear position on FOSS development. During an open source conference among Asian countries in 2003 where Dr Handa was invited to give a talk on the development of Emacs, Shuichi Tashiro, the leader of the Japanese FOSS project under the Ministry of Economic, Trade and Industry, said that the Japanese Government has made necessary regulatory revisions to give developers of government-funded projects the copyright (and thus the right to choose the license) so long as the law was applicable from the beginning of the project.

In this case, we can see that when the government is not familiar with the FOSS licensing and developing model, related government regulations may create unnecessary difficulties for government-affiliated research institutes seeking to participate fully in FOSS development. It took AIST, formerly ETL, years to finally be able to officially release the code under the GNU GPL. Even though now there is a special regulation to facilitate the use of FOSS licenses for government-funded open source projects, as they are still considered exceptions.

A National FOSS Project: Free Software Industrial Development Project, Taiwan

[edit | edit source]

Under pressure from Congress, the Taiwanese Government began the planning of a national FOSS project in 2002, and in 2003 a significant budget had been allocated to a five-year FOSS project. The Ministry of Economics Affairs (MoEA) was assigned to structure, sponsor and oversee all of the sub-projects.

Under general government regulations administered by the National Science Council (NSC), although the results can be copyrighted by the entity which carries out government-funded projects, applications of such results are still subject to certain regulatory principles. Unless it would be more beneficial for the national development of science and technology, the results have to be:

  1. Licensed for a fee.
  2. Licensed to Taiwanese institutes or firms.
  3. Used or manufactured within Taiwanese jurisdiction.

Though exceptions might be made for FOSS projects, the law had not been officially interpreted in this way, and no one wanted to risk violating the regulation.

In addition, the national FOSS project was assigned to the MoEA, which has the more important task of protecting national interest and economic competitiveness. Thus their regulations are more protectionist/ restrictive than the general rule. These restrictive regulations were applied to the national FOSS project. Under MoEA regulations, only the third principle (used and manufactured within Taiwanese jurisdiction) can be exempted. This meant that the outputs of the national FOSS project had to be licensed for a fee, and it can be licensed only to Taiwanese institutes or firms. Such principles are inconsistent with the FOSS licensing model, making it difficult for all sub-projects under the national FOSS project to release their code.

This issue was raised as soon as the five-year FOSS project started. Different government bodies met several times to find a solution. Because the FOSS licensing model was so alien to the models they were used to, the problem was not solved until mid-way into the second year (2004) and the code developed in the first year was not officially released in time.

This was particularly problematic since one of the sub-projects under the national FOSS project was integrating an existing FOSS program. At the same time, the sub-project intended to participate in and contribute to this particular FOSS project. When the community was about to incorporate all of the recent developments and release its newer version under the GNU GPL in March 2004, they found it difficult to incorporate the code developed under the government-funded sub-project in Taiwan.

It was not until after a negotiation held in May 2004 that different government bodies finally came out with a solution. The MoEA submitted the case to the Administrative Yuan (highest administration body) to obtain an official interpretation from the Government regarding whether FOSS projects meet the exception clause and are thus exempt from the principles. Meanwhile, the MoEA began to look into the possibility of revising its restrictive regulations.

The official interpretation was finally made by the Administrative Yuan in July 2004, 18 months after the official launch of the national FOSS project. Under the new interpretation, government-funded FOSS projects met the exception clause of the general NSC rule and can be exempted from the principles that conflict with FOSS licenses. Although the MoEA regulation has not yet been modified, some code-generating FOSS projects are assigned to NSC and the general NSC rule, rather than the more restrictive MoEA rules . It is hoped that FOSS projects will be able to release the code under FOSS licenses thereafter.

This case shows that while the government has started to recognize the importance of FOSS development, its regulatory and administrative structure might not be ready to accommodate FOSS. In the case of the Taiwan National FOSS Project, with the combined efforts of related government and project personnel, the problem was finally solved to a certain extent. But it had already caused some serious problems, especially in collaborating with international and local FOSS communities. As many countries now also recognize the importance of FOSS development, and are starting or planning to start their governmental FOSS projects, it is critical that the related legal structures are examined and updated to facilitate FOSS development.

Footnotes

[edit | edit source]
Retrieved from "https://en.wikibooks.org/w/index.php?title=FOSS_Licensing/Scenarios&oldid=3324899"