Workshop: Legal aspects of free and open source software
____________________________________________________________________________________________
43
“bare copyright license”. Licenses do not require licensees to do anything. They provide a
set of conditions: only fulfilling all of them gives the licensee the right to use, modify, copy,
distribute, etc., the software.
In the United States a landmark case from the Court of Appeal for the Federal Circuit
gave the same interpretation, allowing injunctive relief in a case of violation of a Free
Software license, in Jacobsen v. Katzer.
65
In Europe German courts followed the same line
of arguments in several cases raised by gpl-violations.org, despite following the contractual
line in the first place.
66
If anything, the stricter the license is, the more evident is the intention of the copyright
holder to retain control of the software, as opposed to letting it fall in a “public domain”.
Therefore, copyleft conditions strengthen the license and provide more ground for its
enforcement.
4.1
In particular: the liability regime and exclusion
Typically, FOSS licenses contain very strong disclaimer clauses, which discharge the
author from all liability.
67
The reason for this is that FOSS is often made available without
any monetary compensation of any sort, as a result of which the author generates
insufficient income to pay for liability insurances and legal costs.
68
Should the disclaimer be ineffective, could a software developer be liable for damages
caused by his or her software, in the light of the fact that his or her software is released for
free (under the Free Software license)? Apart from the cases of gross negligence and
intentional acts, or a liability in tort (such as releasing malicious software), the answer
seems to be negative in most cases. It is quite hard to construe a contractual liability only
based on the FOSS licensing. In a typical software license there is no obligation to deliver,
just conditions for use. Should a downstream recipient wish to integrate the software in a
larger product for a particular purpose, and the software be unfit to said purpose, it would
be upon the integrator – who is permitted to make all the modifications needed, including
the adaptations and quality assurance activities – to make sure that the combination
works.
There is a considerable difference between this case and a proprietary software license. In
proprietary software licensing, consideration is exchanged against the delivery of software
or even just against permission to use said software, which is to be qualified a sale.
69
As a
sale, it bears certain statutory warranties, including that the product is free from defects
that reduce its intended use. The same cannot apply to FOSS, which is not "sold", but just
offered to public use. If there is a separate agreement, such as a software development
agreement, the relationship between the client and the developer – in particular the liability
for defective software – is governed by this specific contract and not by the license.
The above conclusion is true when the contractual relationship between the upstream and
the downstream parties in the transaction is the license alone. It might well be the case
that separate agreements (like a software adaptation contract or a maintenance
agreement, or even a sale of a device containing software to an end user) are in place, in
which cases contractual liability rules would apply to that part of the relationship.
65 Lawrence Rosen, Bad facts make good law: the Jacobsen case and Open Source, IFOSS L. Rev., 1(1), pp 27 –
32. Available at
http://www.ifosslr.org/ifosslr/article/view/5
66 Landsgericht Frankfurt, Case 224/06
www.jbb.de/urteil_lg_frankfurt_gpl.pdf
An English translation is available
at
http://www.jbb.de/judgment_dc_frankfurt_gpl.pdf
67 See e.g., the BSD license (http://www.opensource.org/licenses/bsd-license):
"THIS SOFTWARE IS PROVIDED BY ”AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE."
68 B. PERENS, "The Open Source Definition", Open Sources: Voices from the Open Source Revolution,
http://perens.com/OSD.html
69 Cfr. European Court of Justice, case C-128/11 UsedSoft v. Oracle, par. 44-72
Policy Department C: Citizens' Rights and Constitutional Affairs
____________________________________________________________________________________________
44
Liability for lack of title is also a possibility. The releasing of software as Free Software by
an upstream provider could have been relied upon by a downstream recipient. If there is a
hole in this chain of title (e.g. in case one developer has taken software without complying
with the licensing conditions of it), this could result in the lower end of the chain being
damaged, e.g. because of resulting litigation. Can this distributor of software demand to be
indemnified by its upstream software provider who has "obfuscated" the real status of the
copyright title of that particular piece of code? Such indemnification is hard to construe
because there is no contractual link between the party requesting indemnification and its
upstream provider. What remains, in the absence of express warranties and representation,
is non-contractual liability. Certainly the licenses have no warranties and representation,
rather the contrary. Due diligence, in this case, seems to be the only protection one has. In
fact, there is a growing business for consulting companies which also offer various kinds of
automated source code (and sometimes also object code) checking tools and who maintain
a large database of referenced code. SPDX statements
70
or other licensing meta-
information can be used to this effect.
Finally, liability could be claimed on tort. It is reasonable to believe that a principle of
“caveat emptor” (for want of a better wording describing a principle that would place the
risks on the recipient of software) in a Free Software distribution could also be held to
apply. Therefore, only the final user who receives software as a part of a device or of a
software distribution could be in a position to claim damages should the software be
defective, and only vis-à-vis the party who has compiled the code. The chain of liability
would end pretty soon, as the code is “inspectionable” – unlike what happens in a
proprietary setting. This chain would be interrupted as soon as a provider has had a chance
to inspect the code to verify its malfunctioning.
The only generally applicable limit to liability disclaimers contained in a Free Software
license seems to be found, in Europe, at least, in consumer protection law (which puts
strong limits to the effectiveness of liability disclaimer in consumer agreements)
71
, then
again, this should be considered in the light of the particular licensing of the software.
5.
INTERACTION WITH OTHER “IP” RIGHTS
Free Software licensing heavily relies on copyright, but it would be plainly wrong to say that
licenses are just copyright licenses. The rights that are received by the users/recipients go
well beyond copyright. At the same time, other rightsholders – sometimes unrelated to the
actual development of the software – can claim rights that could interfere with the free
working of the licenses and contradict the freedoms that they can ensure.
5.1 Patents
Art. 52.2 (c) and 52.3 of the European Patent Convention
72
seem to exclude software from
the subject matters that can be patented. However, the constant practice of the European
Patent Office and of some of the Member States' patenting offices has been in stark
contrast with the letter of the Convention, so that there exist patents that read on pure
70 “The Software Package Data Exchange® (SPDX®) specification is a standard format for communicating the
components, licenses and copyrights associated with a software package”. See
https://spdx.org
for more
information.
71 For instance, implementation of the Directive 93/13/EEC of 5 April 1993 on unfair terms in consumer contracts
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31993L0013:EN:HTML
.
72 “Article 52 - Patentable inventions.
(1) European patents shall be granted for any inventions, in all fields of technology, provided that
they are new, involve an inventive step and are susceptible of industrial application.
(2) The following in particular shall not be regarded as inventions within the meaning of paragraph 1:
[...]
(c) schemes, rules and methods for performing mental acts, playing games or doing business, and
programs for computers;
[...]
(3) Paragraph 2 shall exclude the patentability of the subject-matter or activities referred to therein
only to the extent to which a European patent application or European patent relates to such subject-matter or
activities as such.”
Dostları ilə paylaş: |