MODULE 4
ENFORCEABILITY OF OPEN SOURCE SOFTWARE
AGREEMENTS
4.1 WHAT IS AN OPEN SOURCE SOFTWARE?
An open source software is a type of software whose source code is freely
accessible to its users, and they have the right to study, review, modify the
source code, and/or creative derivative works as well the freedom to use it
for any purpose, and redistribute it to anyone in either modified or
unmodified form.
As per the Open Source Initiative (OSI), an organization founded by Eric
Raymond and Bruce Perens in 1998 to educate, advocate, promote, protect
and encourage the open source software movement (open source software,
projects and communities), any software that complies with the ‘Open
Source Definition’ is an open source software.1 This definition provides
ten criteria (in the form of ten principles), derived from the Debian Free
Software Guidelines2, which must be fulfilled by a software in order to
qualify as open source.
The Open Source Definition as propounded by OSI is reproduced ‘as is’:
1 ‘What is Open Source Software?’ (Open Source Initiative) https://opensource.org/faq#osd accessed 31 January
2019
2 The Debian Free Software Guidelines is part of the Debian Social Contract, which forms the basis for Open
source definition by OSI. https://www.debian.org/social_contract#guidelines accessed 31 January 2019
“Introduction
Open source doesn't just mean access to the source code. The distribution
terms of open-source software must comply with the following criteria:
1. Free Redistribution
The license shall not restrict any party from selling or giving away the
software as a component of an aggregate software distribution containing
programs from several different sources. The license shall not require a
royalty or other fee for such sale.”3
This criterion highlights the requirement of an open source software to be
freely redistributed, without any charges or licensing fees. The free
redistribution requirement reflects the ethos of genesis of the open source
software movement – how it was created in response to the proprietary
software system, based on the belief that ‘software should not have
owners’4, and that software was meant to be freely accessible by all.
“2. Source Code
The program must include source code, and must allow distribution in
source code as well as compiled form. Where some form of a product is
not distributed with source code, there must be a well-publicized means of
obtaining the source code for no more than a reasonable reproduction
cost, preferably downloading via the Internet without charge. The source
code must be the preferred form in which a programmer would modify the
3 ‘The Open Source Definition’ (Open Source Initiative) https://opensource.org/osd accessed 31 January 2019
4 Richard Stallman, ‘Why Software should not have owners?’ (Free Software, Free Society: The Selected Essays
of Richard M. Stallman) https://www.gnu.org/philosophy/why-free.en.html accessed 31 January 2019
program. Deliberately obfuscated source code is not allowed.
Intermediate forms such as the output of a preprocessor or translator are
not allowed.”5
One of the primary goals of the open source software movement is to
facilitate rapid evolution of high quality software programs, which is
possible only through modification of the source code. Hence, it is
essential that an open source software ‘opens’ its source code to the users
and enable them to read, review, modify and enhance such source codes.
“3. Derived Works
The license must allow modifications and derived works, and must allow
them to be distributed under the same terms as the license of the original
software.”6
In order to support a rapid and continuous evolution of open source
software, the mere ability to study, analyse and review the source code is
inadequate. Open source users need to be able to modify the source code
and produce derivative works; and such modified/derived work should be
redistributable.
“4. Integrity of The Author's Source Code
The license may restrict source-code from being distributed in modified
form only if the license allows the distribution of "patch files" with the
source code for the purpose of modifying the program at build time. The
5 The Open Source Definition (n 4)
6 ibid
license must explicitly permit distribution of software built from modified
source code. The license may require derived works to carry a different
name or version number from the original software.”7
The rationale behind this criterion is to protect an author’s professional
reputation and integrity. As per this provision, an open source license may
require distribution as original base source code plus modified patch files,
so that the modifications or changes are readily distinguishable from the
pristine base source.
“5. No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of
persons.”8
In order to stay true to its openness, an open source software must be
accessible to any and all groups and diversities of persons, and they should
be allowed equal freedom to access and use the open source software for
any purpose.
“6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a
specific field of endeavour. For example, it may not restrict the program
from being used in a business, or from being used for genetic research.”9
7 ibid
8 ibid
9 ibid
The rationale behind this clause is to ensure that open source software is
open to users from all fields of endeavour, including commercial users.
However, ‘commercial’ use should not be confused with ‘proprietary’ use.
“7. Distribution of License
The rights attached to the program must apply to all to whom the program
is redistributed without the need for execution of an additional license by
those parties.”10
This criterion ensures that open source licensing grants the same legally
enforceable rights to subsequent generations of users.
“8. License Must Not Be Specific to a Product
The rights attached to the program must not depend on the program's
being part of a particular software distribution. If the program is extracted
from that distribution and used or distributed within the terms of the
program's license, all parties to whom the program is redistributed should
have the same rights as those that are granted in conjunction with the
original software distribution.”11
This criterion is intended to prohibit license traps, wherein individual
components/extracts of an aggregate software are distributed under a
different license other than the licensing of the original software package,
which is open source. That is, individual extracts of an open source
software package, cannot be distributed under a ‘closed’ license.
10 ibid
11 ibid
“9. License Must Not Restrict Other Software
The license must not place restrictions on other software that is distributed
along with the licensed software. For example, the license must not insist
that all other programs distributed on the same medium must be open-
source software.”12
This provision grants freedom of open source software distributors.
“10. License Must Be Technology-Neutral
No provision of the license may be predicated on any individual
technology or style of interface.”13
This criterion provides a safeguard measure against web contracts such as
click-wrap contracts which require an explicit affirmative action (such as
clicking on an “I agree” button) to assent to the contract (license) between
a licensor and the licensee. Contracts such as click wrap contracts operate
on a specific technological platform, and as such, they limit the free
distribution of the license through other modes of software distribution
like web mirroring, CD ROMs and FTP download. This provision
guarantees that such situations prohibiting free transmission and reuse of
the source code, do not occur in cases of redistribution of open source
software.
12 ibid
13 ibid
4.2 TYPES OF OPEN SOURCE SOFTWARE
Open Source Softwares are mainly of the following categories:14
4.2.1 Public Domain
a software which has been explicitly released in the public domain, is
known as public domain software. This implies that a public domain
software is not restricted by any intellectual property ownership rights
such as copyright, patent or trademark; or, usage rights. A public domain
software can be modified, redistributed, sold without attribution, and even
converted into a proprietary software.
4.2.2 Copyleft
An open source software license which requires the derivative works
(meaning, modified or extended versions of the original software) created
from modifying, changing or enhancing its source code, to be redistributed
under the same license as the original open source license, is termed as
copyleft license. The GNU General Public License (GPL) is the most
popular example of a copyleft license. This means that, if a software
programmer develops a software and releases it under the GNU GPL
license, and subsequently, another open source user modifies or changes
the source code of the original software, or enhances the existing source
code by adding any new code, then the modified version along with the
new code, must also be released under a GNU GPL license. Thus, both the
14 M. Jouvin, J. Harvey, A. McNab, E. Sexton-Kennedy and T. Wenaus, ‘Software License Agreements: HSF
Policy Guidelines’ (The Hep software Foundation, 16 February 2016)
https://hepsoftwarefoundation.org/notes/HSF-TN-2016-01.pdf accessed 31 January 2019
original and the derivative work remain open source. The rationale behind
a copyleft license is to ensure that the open source principles are
perpetuated to all subsequent derivatives. The most important attribute of a
copyleft license is that it prevents or ‘protects’ users from converting the
open source software into proprietary software. Hence, copyleft licenses
are also known as ‘strongly protective’ licenses.
4.2.3 Permissive / Non-copyleft
An open source software which is not copyleft, that is, it ‘permits’ users to
redistribute an original or modified open source software under a different
license other than the original license, including under a proprietary
license besides copyleft and other non-copyleft licenses, is called a non-
copyleft or a permissive license. Licensees, however, must provide
requisite attributions (meaning, a copy of the license terms and copyright
notice) when associating with other licenses. Therefore, the most
important difference between a copyleft and a non-copyleft license is that
a non-copyleft license permits the software to become proprietary. Popular
examples of non-copyleft licenses include the Apache, MIT and BSD
licenses.
4.2.4 Weak Copyleft
Weak copyleft licenses fall somewhere in between a copyleft and a non-
copyleft/permissive license. Meaning, a weak copyleft prevents
redistribution of the ‘modified’ work under a different license other than
the original open source license (that is, if it is modified, then the
modified work must be released under the same license terms, thereby
bearing the characteristics of a copyleft license), whereas, it permits using
the ‘unmodified’ component of an open source software in a larger
software which is licensed under different terms, including proprietary
(thereby bearing characteristics of a permissive license). Example includes
the GNU Lesser General Public License (LGPL).
4.3 BENEFITS
Open source software has several benefits. Some of them are as follows:15
4.3.1 Freedom
The source code of an open source software is freely accessible to users,
and they have the freedom to study, analyse, modify, change or upgrade
the source code and create derivative work, plus the freedom to freely
distribute such software. These features of open source software benefit
users by providing a highly adaptive software to suit their changing
business needs; flexibility and freedom to upgrade to a newer version of
software as per their (users’) requirements and schedule; and quicker
detection and repairment of software bugs. In contrast, a proprietary
license does not make its source code available to users, and they are not
permitted to distribute it. Users cannot thus change or modify a proprietary
software and are dependent on the software vendor for support, bug-fixes
and upgrades.
15 ‘The Benefits and Challenges of Going Open Source’ (ThinkSys, 1 May 2017)
https://www.thinksys.com/development/benefits-and-challenges-open-source-software/ accessed 15 January
2019
4.3.2 Avoiding vendor lock in
A vendor lock in is a situation where a customer is dependent on a
particular vendor for products or services, and cannot switch to another
vendor without incurring high switching costs, or due to incompatible
technology platform. Using an open source software license helps a
software user avoid vendor lock in. In proprietary software, where the
source code is closed, customers are required to pay (often exceedingly
expensive) additional charges to the software vendor for software
functionalities like security, maintenance, support and upgrades, over and
above the licensing fee. However, an open source software, with its ‘open’
source code, eliminates these risks, as its source code can be modified and
altered by programmers to make improvements as per their needs, without
having to rely on any software vendor for the same.
4.3.3 Creative collaboration
The open source software community fosters creative collaboration.
Individuals and organizations collaborate to create new and innovative
software solutions or improve existing ones on a common platform driven
by openness, meritocracy and transparency, without any organizational or
command hierarchy.
4.3.4 High quality code
An open source software is continuously and rapidly evolving, as a
growing open source software developer community is constantly and
proactively studying and reviewing the source code, and modifying it to
improve its performance, plus identifying and eliminating bugs and other
software defects on a real-time basis. Thus, this process of constant
customization and a strong peer review process enables generation of a
superior quality code.
4.3.5 Security benefits
Since the source code of an open source software is publicly accessible, it
is open for any number of users and programmers to read, inspect and
review the code. As a growing number of professionals study and evaluate
the source code, any bugs, security threats or other types of vulnerabilities
become easily detectable and reportable, thus enabling software
developers to quickly fix the problems and improve the software quality,
either by releasing software patches to the public, or the entire source code
after modifying and repairing it. In a proprietary software where the source
code is closed, customers/users have no option but to rely on the official
software developers of the vendor to fix the security bugs, and release their
official patches after a long and complex testing and review procedure.
Whereas, in an open source software, due to its open source code (that is,
its availability to the users), bug-fixes can be performed by any user in the
open source community and software patches released promptly which can
further be peer-reviewed by others. Another major security benefit of open
source software is that it allows customization of security measures, unlike
in a proprietary software where users are left without any choice to
enhance the existing security measures and bound to accept the security
level provided by the software vendor which, at most times, can be
inadequate for a particular organization. On the contrary, an open source
user may add extra security features as required, and strengthen its
security.
4.3.6 Software viability
Using a proprietary software license does not always guarantee its
survival. If the software vendor of a proprietary software chooses to render
an older version of a software ‘redundant’, and accordingly not support
that particular software format version, software users of such product will
suffer huge losses and inconvenience. Similarly, if a software vendor goes
out of business or is acquired by another company, it may not continue
supporting its existing software products, or release timely updates and
provide maintenance support. Such a scenario demands users to inevitably
switch vendors, which is an expensive process. However, with the use of
an open source software, such risks are avoidable, since the source code is
open to the public, thus allowing them to modify or alter the code
according to their specific requirements and/or create derivative works
without relying on one particular software vendor or vendor partner/s.
4.3.7 Zero license costs
Unlike a proprietary software license, using an open source software does
not require payment of a licensing fee, or any additional costs for
adding/altering features, and does not involve payment of extra charges for
support, maintenance or upgrades. Thus, an open source software reduces
the procurement barrier.16
4.4 ISSUES
Common legal issues relating to an open source software are as follows:17
4.4.1 Ownership
Determining ownership rights of an open source software is a complex
question. Generally, author of the source code who subsequently licenses
the program under an OSI certified open source license, is the copyright
owner. However, questions may arise as to whether the open source
software was developed pursuant to a employment agreement, a software
development agreement or under a work for hire arrangement. If indeed
the software was developed pursuant to one of these agreements, then it
precludes the individual software programmer from licensing it, and grants
the employer the authority to release such code under open source
licensing terms. Further, disputes may arise relating to ‘project
ownership’, meaning disputes regarding what constitutes official version
of the software, release of new version/s of the software and the release
dates, standards of programming, among other software development
disputes. The ownership issue leads to another major issue, which is
copyright enforcement of open source software.
16 Yogi Schulz, ‘The Evolving Benefits Offered by Open Source Software’ (IT World Canada, 7 September
2018) https://www.itworldcanada.com/blog/the-evolving-benefits-offered-by-open-source-software/408582
accessed 15 January 2019
17 Dennis M. Kennedy, ‘A Primer on Open Source Licensing Legal Issues: Copyright, Copyleft and Copyfuture’
http://www.cs.miami.edu/home/burt/learning/Csc322.052/docs/opensourcedmk.pdf accessed 18 January 2019
4.4.2 Enforcement of copyright
It is a general misconception that due to the nonexclusive nature of open
source licenses, they are not enforceable; or, by releasing its source code
to the public, licensors of an open source license give up their remedies in
copyright infringement. However, that is not true. Many open source
licenses subject their redistribution and/or modification rights to proper
copyright attribution and source code access obligations, such as,
including names of authors, reference to original source codes, including
the copyright notice, and/or disclosing how the altered source code differs
from the original source code, and as such, they are entitled to copyright
enforcement. However, with open source licenses without such express
obligations, doubts remain as to who may enforce the license, as an open
source license includes contributions from several developers each of
whom has licensed their work under open source terms.
4.4.3 Interpretation
Open source licenses are often loosely worded, straightforward and
simple, devoid of any legalese, since they are composed and written by the
open source community. This often leads to ambiguity regarding
compliance, as the licensing terms do not always coherently convey about
actions which are permissible and which are non-permissible under such
licenses, which, in turn, leads to copyright interpretation issues.
4.4.4 Commercial exploitation
With the increasing popularity of the open source model, and their
increased commercial exploitation, important issues need to be dealt with.
For instance, if a licensee receives a software under an open source
license, and s/he uses that software for commercial purposes, can s/he
place further restrictions on such software; rights of a commercial software
developer to use open source software to develop a proprietary software;
whether commercial developers will find a way to circumvent open source
obligations in order to generate more revenues from commercialization of
such licenses and how; or implications of a commercial developer
adopting an open source approach such as releasing its source code to the
public, like in Apple Mac OS X.
4.4.5 License management
It is essential to understand the meaning, consequences and intent of an
open source license in order to avoid licensing disputes at a later stage. For
instance, whether a particular open source license binds ‘downstream
licensees’ of such software, like the GPL copyleft license; the impact of
including or using an open source program or a part of it, in a commercial
or proprietary software; or whether an open source license can be
permitted to be redistributed under a different license, and if so, the
conditions that accompany such conversion. To sum up, licenses should be
chosen and applied after adequate consideration of its terms, conditions
and implications.
4.4.6 Patents
Sometimes, software patents might be claimed over a software component
or an entire open source software, thus restricting its usage and
distribution, in clear contradiction with open source principles. Patenting
an open source software or a portion of it, would result in limited rights of
users to freely use and control the software; paying a license fee prior to
using such a software; and no distribution rights over either verbatim
copies of the software, or a modified version. This completely defies the
vision and goals of an open source software, and likens it to a closed
source software. The GPL license attempts to avoid this issue by requiring
licensees to agree to any patent, or not to apply for any patent which would
be detrimental to the integrity of the open source software.
4.4.7 Security risks
An open source software faces various security threats. The publicly
accessible source code of an open source program is also available to
cyber attackers. Unlike in proprietary software where the source code is
‘closed’, hackers need to expend great effort and time in bringing about
their desired outcomes (attacks) by selectively feeding input data and
observing the output, but it becomes much easier and more convenient to
attack an open source program due to its ‘openness’. Further, even the
discussions regarding bugfixes and the software patches to rectify any
security threats are available in the open source community, which helps
attackers expedite the cyberattack. Also, mere availability of the source
code does not guarantee a peer review of the same, since software
developers are usually motivated to review the source code to reuse in
some other projects or to customize the open source code in their
environment. Thus, bug fixing is not necessarily a priority, and they may
remain undiscovered and unfixed for a long period of time. Further, it is
conceivable that open source users are focused on studying, assessing and
fixing functionality bugs over security bugs. Also, fixing a security
vulnerability requires adequate proficiency and comprehensive knowledge
of software security, which software users may lack. The security issue is
further made worse when an open source software lacks adequate
vulnerability/threat notification mechanism, and the only way to discover
any new reports on bugs is by frequent monitoring of the websites and/or
mail lists.18
4.5 ENFORCEABILITY OF OPEN SOURCE SOFTWARE
The issue of enforceability of open source software can be understood
from the following case laws.
In Jacobsen v. Katzer19, Jacobsen was the copyright holder of a computer
software called DecoderPro available for public download from a website
(called SourceForge) for free, but its usage, distribution and modification
rights were licensed under Artistic License (an OSI approved open source
license). Under an Artistic License, redistribution of the unmodified source
code is subject to copyright attribution, while redistribution of the
modified version is subject to a documented disclosure detailing how the
modified version differs from the original source code. DecoderPro
18Oskari Rantala, Hu Chan and Huang Jiao, ‘Security Issues of Open Source Software – Will Open Source
Affect Security?’ (2 June 2013)
https://wiki.oulu.fi/download/attachments/34308420/ossd_2013_rantala_hu_huang.pdf?version=1&modificatio
nDate=1384799272000&api=v2 accessed 18 January 2019
19 535 F. 3d 1373 (Fed. Cir. 2008)
permitted model-train enthusiasts to program decoder chips to control such
model trains. Jacobsen alleged that the defendant, Matthew Katzer through
his company Kamind Associates, downloaded and modified the open
software, without due credit (that is, without mentioning the author’s
name, copyright notices, reference to the original source code, or
identifying SourceForge as the original source of DecoderPro) or
disclosing how the code was altered/modified. In doing so, Katzer violated
the licensing terms under Artistic License, and thus, Jacobsen brought a
copyright infringement suit against Katzer. Katzer argued that Jacobsen
had surrendered any remedy in copyright infringement by making
DecoderPro available to the public at large, under an open source license,
despite any further obligations in exercise of rights in the Artistic license;
and thus, it gave him no economic rights.20 The District Court for the
Northern District of California found for the defendant and concluded that
the copyright notice and attribution requirements of the license were not
conditions to the grant of the license itself, since an Artistic License was
an ‘intentionally broad’ non-exclusive license, with an unlimited cope.
Therefore, Katzer’s non-compliance with the license obligations did not
amount to an infringement of copyright, but to a breach of contract.
However, the appellate court rejected the lower court’s ruling, and decided
that the central issue for determination was “the ability of a copyright
holder to dedicate certain work to free public use and yet enforce an ‘open
source’ copyright license to control the future distribution and
modification of that work”21. In doing so, the higher court emphasised on
the importance of ‘creative collaboration’ facilitated by open source
20 ibid
21 ibid
licensing, and stated that the copyright notice and source code access
obligations form an intrinsic part of open source licensing terms. The court
observed that, “Through [open source] collaboration, software programs
can often be written and debugged faster and at a lower cost than if the
copyright holder were required to do all of the work independently. In
exchange and in consideration for this collaborative work, the copyright
holder permits users to copy, modify, and distribute the software
code subject to conditions that serve to protect downstream users and to
keep the code accessible. By requiring that users copy and restate the
license and attribution information, a copyright holder can ensure that
recipients of the redistributed computer code know the identity of the
owner as well as the scope of the license granted by the original owner”22.
Further, the court rejected Katzer’s argument on grounds that economic
benefits do not only mean ‘traditional license royalties’, but also includes
“increased market share, reputational benefits, and rapid product
development and improvement”.23 The US Court of Appeals for the
Federal Circuit also clarified that the phrase ‘provided that’ in the Artistic
License terms proved that the requirements of copyright attribution and
source code access obligations were indeed conditions to the grant of the
license. It recognized the importance of enforcing open source software
obligations in the following words, “Copyright holders who engage in
open source licensing have the right to control the modification and
distribution of copyrighted material. … Copyright licenses are designed to
support the right to exclude; money damages alone do not support or
enforce that right. The choice to exact consideration in the form of
22 ibid
23 ibid
compliance with the open source requirements of disclosure and
explanation of changes, rather than a dollar-denominated fee, is entitled
to no less legal recognition. Indeed, because a calculation of damages is
inherently speculative, these types of license restrictions might well be
rendered meaningless absent the ability to enforce through injunctive
relief”24.
The case of Versata Software Inc. v. Ameriprise Financial25 involved two
contracts between three companies – a master license agreement by means
of which Versata granted a non-exclusive, non-transferable, and perpetual
license to Ameriprise for using Versata’s Distribution Channel
Management (DCM) software; and an agreement by which XimpleWare
Corporation permitted Versata to use its VTD-XML software, an open
source software governed by GPL licensing terms. Versata claimed that
Ameriprise violated the licensing terms of the MLA by permitting use of
the DCM software to unauthorised third-party users, whereas Ameriprise
countered by claiming that since Versata incorporated the GPL licensed
VTD-XML into DCM, it was required to make the source code of DCM
freely available to all users including Ameriprise and third-party users.
Subsequently, XimpleWare accused Versata of copyright infringement
since it incorporated the open source VTD-XML in DCM without
obtaining XimpleWare’s permission to use its products, a commercial
license or without complying with the GPL requirements. Additionally,
XimpleWare also sued Ameriprise for violating GPL licensing
requirements in the following ways – Ameriprise distributed DCM
24 ibid
25 Texas case: Case No. D-1-GN-12-003588; 53rd Judicial District Court of Travis County, Texas (May 3,
2013)
software without ‘opening’ its source code to users, and without adequate
copyright attribution or reference to XimpleWare’s source code in the
DCM software. Further, XimpleWare filed a patent infringement case
against Versata and Ameriprise, along with several other customers of
Versata. Although Versata and XimpleWare subsequently reached a
settlement, the court provided useful guidance on interpretation of GPL
licensing terms, the most important being that “even if the original
licensee—[here, Versata]—breaches its license for whatever reason, third-
party customers of that original license retain the right to use
XimpleWare's software so long as the customer does not itself breach the
license by 'distributing' XimpleWare's software without satisfying [any]
attendant conditions”26.
In 2017, a federal court of the United States of America upheld the
enforceability of an open source license, by denying a motion for dismissal
of a lawsuit alleging violations of the GNU General Public License
(GPL).27 The District Court for the Northern District of California, in
Artifex Software v. Hancom28, also found that a breach of the GNU GPL
license was a breach of contract. Artifex is the creator (software
developer) and licensor of Ghostscript, an interpreter for Adobe Systems’
PDF (Portable Document Format) and PostScript language, which operates
under a dual licensing model. As per its dual licensing structure,
Ghostscript is offered by Artifex both under proprietary licensing terms,
and an open source license, which was the GNU GPL license in this case.
This implied that a licensee could either use Ghostscript for free provided
26 ibid
27 Artifex Software Inc. v. Hancom Inc. No. 16-cv-06982-JSC, 2017 U.S. Dist. LEXIS 62815, Doc. 32 (N.D.
Cal. Apr. 25, 2017)
28 ibid
s/he adhered to the GPL license terms (if a software is developed using the
GPL license, then the resultant software, that is the derivative work, can
only be distributed under the same open source licensing terms), or the
licensee could purchase Ghostscript and thus waive the GPL licensing
requirements. The defendant, Hancom, which is a South Korean software
developer of a suite of applications called Hancom Office, integrated
Ghostscipt into its word processing software product in 2013. However, in
doing so, Hancom neither sought a proprietary license for Ghostcript, nor
did it comply with its GPL licensing terms. Artifex, thus filed a suit
against Hancom in 2016, alleging that Hancom’s violations of the GPL
license amounted to copyright infringement as well as a breach of contract.
Hancom refuted the claims asserting that, Artifex was precluded from
seeking damages for GPL violations since grant of license under GPL is
royalty free. Further, Hancom also sought dismissal of the case on grounds
that the parties involved did not sign any GNU GPL contract, hence there
was no mutual assent, and thus, no existence of a contract. The court
denied the motion and ruled in favour of Artifex saying, “The GNU GPL
provides that the Ghostscript user agrees to its terms if the user does not
obtain a commercial license. Plaintiff alleges that Defendant used
Ghostscript, did not obtain a commercial license, and represented publicly
that its use of Ghostscript was licensed under the GNU GPL. These
allegations sufficiently plead the existence of a contract.”29Here, Hancom
did not obtain a commercial license, yet used the software. Thus, as per the
license, this usage of Ghostscript amounted to Hancom’s assent to the
GPU licensing terms, and hence constituted a contract. This ruling has
29 ibid
been hailed as a victory for the open-source community, and is often aptly
known as the “GPL is a Contract” case.30
In CoKinetic Systems v. Panasonic Avionics31, the plaintiff CoKinetic, a
major global developer and manufacturer of ‘in-flight entertainment’ (IFE)
software, alleged that the defendant Panasonic Avionics wilfully violated
terms of the GPLv2 open source license and sought damages amounting to
US $100 million. CoKinetic claimed that Panasonic’s IFE hardware uses a
Linux based operating system, which requires that its source code be
freely distributed to third party users under the GNU GPL license; but
Panasonic refused to distribute such open source code, and in doing so,
restrained its competitors including CoKinetic, to develop software for IFE
hardware. In the words of CoKinetic, “Panasonic has built the Linux-
Based Panasonic Core Software using the open-source Linux kernel,
which is clearly governed by the GPL, together with Panasonic’s own
modified Linux modules, which are likewise governed by the GPL.
Panasonic has incorporated a massive amount of open source modules,
programs, and libraries into the Linux-Based Panasonic Core Software,
without distributing notices or source code to the Linux-Based Panasonic
Core Software, or even to any part of it…By deliberately refusing to
distribute the source code to the Linux-Based Panasonic Core Software in
accordance with its GPL obligations, Panasonic intentionally deprives
competitors in the market from having the ability to develop software that
30 Darin Snyder, Melody Drummond Hansen and Heather J. Meeker, ‘Court Upholds Enforceability of Open
Source Licenses’ (O’Melveny, 3 May 2017) https://www.omm.com/resources/alerts-and-
publications/alerts/client-alert-court-upholds-enforceability-of-open-source-licenses/ accessed 14 January 2019;
Keith Collins, ‘A federal court has ruled that an open-source license is an enforceable contract’ (Quartz, 11 May
2017) https://qz.com/981029/a-federal-court-has-ruled-that-an-open-source-license-is-an-enforceable-contract/
accessed 14 January 2019
31 New York Southern District Court, Case no. 1:17-cv-01527
can access the basic features and capabilities of Panasonic IFE
Hardware.”32Thus, CoKinetic contended that Panasonic has “wilfully
infringed copyrights belonging to hundreds or even thousands of software
developers that freely contributed source code to Linux”33. Although the
parties eventually reached a settlement, this case is another example of
issues that arise due to non-compliance of open source licensing terms.34
4.6 FREE SOFTWARE
Richard Stallman, founder of the Free Software Movement, defines free
software as a “software that respects the users’ freedom and the social
solidarity of the users’ community”35. He highlights the freedom of a free
software by highlighting the constraints of a proprietary software. In his
words, “a proprietary software keeps its users divided and helpless”36.
Divided, because users do not have the freedom to share or distribute it;
and, helpless, because they do not have access to the source code of a
proprietary software, and hence, no freedom to study, review, modify or
enhance the code. Stallman believes that a software can qualify as a free
software if it grants users ‘four essential freedoms’, which are reproduced
as is:
“Freedom 0 is the freedom to run the program as you wish.
32 ibid
33 ibid
34 Sarah Gooding, ‘CoKinetic Systems Pursues $100 Million GPL License Violation Case Against Panasonic
Avionics’ (WP Tavern, 14 July 2017) https://wptavern.com/cokinetic-systems-pursues-100-million-gpl-license-
violation-case-against-panasonic-avionics accessed 21 January 2019
35 ‘What means Free Software and why it matters’ (Free Software Foundation Europe, 22 May 2009)
https://fsfe.org/freesoftware/transcripts/rms-2009-05-22-eliberatica.en.html#what-is-free-software? accessed 31
January 2019
36 ibid
Freedom 1 is the freedom to study the source code and then change it to
make the program do what you wish.
Freedom 2 is the freedom to help your neighbour – that's the freedom to
make and distribute exact copies of the program to others, when you wish.
And
Freedom 3 is the freedom to contribute to your community: that's the
freedom to distribute copies of your modified versions, when you wish.”37
According to Stallman, if either of the aforementioned freedoms is missing
from a software, then it is definitely not a free software, but a proprietary
software, since curbing one of these freedoms puts the software developer
in a superior position than the user, which is in direct conflict with free
software principles. Stallman insists that free software is not be thought of
as free in terms of price or cost, but free software implies ‘freedom’. To
illustrate his point and provide a relatable example, Stallman says that
“free” in free software is to be thought of as free in “free speech”, and not
free in “free beer”, thus emphasizing on the freedom of users.38
Richard Stallman strongly feels that a proprietary software should be
rejected not merely by software users but by the society as a whole, since
proprietary software serves as a tool for exploitation by its developer. In
contrast, a free software should be readily accepted by the society since it
facilitates social participation as well as individual user freedom. To sum
37 Richard Stallman, ‘What is Free Software?’ (GNU, 15 December 2018) https://www.gnu.org/philosophy/free-
sw.html accessed 31 January 2019
38 ibid
up, free software promotes individual freedom, social solidarity and
democracy; while proprietary software stands for ‘dictatorship’.39
Free software is often used interchangeably with open source software.
However, Richard Stallman says that the two stand for fundamentally
different values, despite having similarities. According to Stallman, “free
software is a social movement whereas open source is development
methodology”40. While free software is concerned with ethics of software
development and users’ freedom, open source is concerned with
development of practical solutions to make software ‘better’. While the
free software movement views non-free software or proprietary software
as its enemy/antithesis and a social problem, the open source community
rejects it as an ‘inferior solution’, and does not concern itself with the
ethical dilemma surrounding proprietary software. Further, in practice, the
criteria to be fulfilled to qualify as an open source software, is ‘a little
looser’ than free software criteria. This implies that, while all free software
codes are open source, all open source codes are not free. Stallman cites
“Open Watcom” as an instance, which is an open source software but not
free software, since it prohibits modification and private use of the source
code. Thus, according to Stallman, free software stands for ‘freedom’,
whereas open source software stands for ‘openness’, and unfortunately,
they are not the same thing.41
39 What means Free Software and why it matters (n 34)
40 Richard Stallman, ‘Why Open Source misses the point of Free Software?’ (GNU, 18 November 2016)
https://www.gnu.org/philosophy/open-source-misses-the-point.html.en accessed 31 January 2019
41 ibid