Constitutional affairs legal affairs



Yüklə 228,85 Kb.
Pdf görüntüsü
səhifə19/45
tarix11.10.2017
ölçüsü228,85 Kb.
#4288
1   ...   15   16   17   18   19   20   21   22   ...   45

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.” 


Yüklə 228,85 Kb.

Dostları ilə paylaş:
1   ...   15   16   17   18   19   20   21   22   ...   45




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©www.genderi.org 2024
rəhbərliyinə müraciət

    Ana səhifə