Re: [epl-discuss] Who can enforce?

[Andrew Katz <Andrew.Katz@xxxxxxxxxxxxxx>]

Hi Till

Many thanks for this. Comments below.


On 8 Jun 2017, at 15:18, Till Jaeger <till.jaeger@xxxxxxxxx<mailto:till.jaeger@xxxxxxxxx>> wrote:

Hi Andrew,

Thank you for all the work and your help to avoid legal pitfalls. Could you
summarize the legal background under UK law you explained in the call
yesterday? This would be very helpful for all those not familiar with this
concept (including me).

Some remarks (in particular with regard to German law):

1.
"The first time a Recipient, having received a copy of the Program, uses,
reproduces or distributes it, one or more bipartite contracts are formed"

Is the part "one or more bipartite contracts are formed" a conclusion or an
additional requirement?

As a conclusion this might be not correct since Art. 5 (1) Directive
2009/24/EC
(http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32009L0024&from=DE)
does not require a contract or license for the lawful acquirer of the
program in accordance with its intended purpose.

Distributing the copy might fall under the exhaustion principle and
therefore no contract might be required to do so.

If it is a requirement it would be helpful to clarify it.

It’s a consequence of the preamble:

ANY USE, REPRODUCTION OR DISTRIBUTION OF THE PROGRAM CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT

and merely restates it in slightly more detail. I agree it’s problematic: here’s the text of Article 5.1 of the Computer Programs Directive:

1.   In the absence of specific contractual provisions, the acts referred to in points (a) and (b) of Article 4(1) shall not require authorisation by the rightholder where they are necessary for the use of the computer program by the lawful acquirer in accordance with its intended purpose, including for error correction.


Article 4.1 says:


Article 4

Restricted acts

1.   Subject to the provisions of Articles 5 and 6, the exclusive rights of the rightholder within the meaning of Article 2 shall include the right to do or to authorise:

(a)


the permanent or temporary reproduction of a computer program by any means and in any form, in part or in whole; in so far as loading, displaying, running, transmission or storage of the computer program necessitate such reproduction, such acts shall be subject to authorisation by the rightholder;


(b)


the translation, adaptation, arrangement and any other alteration of a computer program and the reproduction of the results thereof, without prejudice to the rights of the person who alters the program;


(c)


any form of distribution to the public, including the rental, of the original computer program or of copies thereof.



So the effect of this is that since the licensee has a right to use the software anyway, having lawfully acquired it, then no additional rights are required to run it, and therefore the contract cannot be formed at that stage (since there is no licence which requires to be granted). I don’t believe much turns on this - the requisite contract would be formed at the point when the Program is reproduced or distributed (subject to my comments on exhaustion), and we are primarily concerned with what happens when the program is distributed. So far, so good. However…

…Till mentions exhaustion (which he and I have discussed before, and I gave a talk on this both at FOSDEM and the ELN conference). For non-Europeans, exhaustion is similar to the first sale doctrine under US law, and Article 4.2 of the Directive says:

2.   The first sale in the Community of a copy of a program by the rightholder or with his consent shall exhaust the distribution right within the Community of that copy, with the exception of the right to control further rental of the program or a copy thereof.

There is a fair amount of judicial interpretation of this, and one view (the one I propose) says that since free/open source software isn’t ‘sold’, then the rights aren’t exhausted. Till cogently argues that (as evidenced by the German text of the directive), ‘sold’ should have a broader meaning which turns on a number of factors including whether a benefit accrues to the copyright holder, and whether the downstream imposition of copyleft terms generates that benefit. I think Till’s argument is strengthened by the indemnity contained in the licence, which does provide a tangible benefit to the rights holder, should the Program contain their Contribution be distributed commercially. This means that, once a copy of the software has been placed into circulation within the EU, subsequent recipients of that copy are no longer bound by the terms of the EPL. This gets terribly complicated, as the Oracle -v- UsedSoft case makes clear that in certain circumstances, even a downloaded copy (as opposed to a copy on a data carrier like a DVD) may also be subject to exhaustion. However, generally, where the mode of distribution is through downloading, exhaustion will not apply, as a new copy will have been made, and there’s no major problem. A bigger problem arises when the software is incorporated into a device, and that device is transferred. Then the exhaustion right will apply, and the Contributors will no longer be able to potentially control any further distribution (for example, by imposing a condition that the source code is made available by the entity doing the distribution). It may have a more significant problem in relation  to the commercial distribution indemnity. But I won’t go into the detail now. In one sense, there’s not a huge amount we can do about this - Till may disagree - there’s no effective way to ‘opt out’ of exhaustion.


2.
What is the concrete problem we would like to avoid? Is there a typical use
case?

If you’re not familiar with third party beneficiaries, it may be as well to skip to my answer to 3, and then back here…

There are two problems I am trying to avoid. The first is that, if this is a contract, and if it contains references to any third parties, or classes thereof, then those third parties, in the absence of specific exclusionary wording, would have rights under the agreement, directly enforceable against the contracting parties, even though the third parties are not parties to the contract. Having said that, as a concrete problem it has now been reduced by my suggestion that ‘licensee’ in section 3.1(a) is replaced by ‘Recipient’. The other clause where is may potentially cause a slight problem is in clause 7 which states that ‘everyone is permitted to copy and distribute copies of this agreement’ - which extends rights to the world at large. Under the Contracts (Rights of Third Parties) Act 1999, this means that everyone in the world can enforce the right. Which is, in itself, not a problem. What is a problem is that it means that everyone in the world now has the power to object to any alteration or recession of the terms. I’m not aware of any case law on this point (largely because the legislation is almost invariably excluded), but it could potentially mean that anyone could interfere in any attempted private variations to the agreement, or attempts to rescind it, or any exceptions granted between two parties. It’s difficult to see exactly when this might happen, but it provides some grounds for mischief. So my instinct is, as is common in almost all English Law contracts, to exclude third party beneficiary rights entirely.

The second problem I am trying to avoid is enforceability by recipients. The view of the FSF, and, with a few dissenters, the common law world, is that the GPL (at least v2 - v3 poses some more problems not to be discussed here) as a bare licence is enforceable *only* by rights holders. In other words, if you’re an aggrieved recipient of GPL object code without the source, your route to compliance of last resort is to enlist the help of a copyright holder and persuade them to initiate an infringement claim against the misbehaving distributor. As a recipient, you have no right to demand the source yourself.

I have always assumed (possibly naively), that this is the standard approach for FOSS licensing (and when we were discussing the last version of the CERN licence we automatically adopted this model, but discussed whether a ‘recipient has rights’ model might make more sense for open hardware, given the relatively fewer opportunities in hardware for the licence to impinge). I’m certainly going to look through a few other licences and see whether they are potentially enforceable by recipients as well as rights holders.


3.
What is a "third party beneficiary”?
Under English Law, ‘privity of contract’ means that only the parties to a contract may enforce it. Thus if I agree to pay you £10 to buy flowers for Mike, Mike, not being a party to the agreement between you and me, can’t sue you if you don’t buy him flowers. Or at least, he couldn’t until 1999. Since then the Contracts (Rights of Third Parties) Act has extended to Mike the ability to sue you for flowers, unless you and I expressly agree to exclude that act. And if we make our agreement, and subsequently decide to vary it so that you’re supposed to by Mike a cake instead, then Mike can complain, and still sue you for the flowers, unless he consents to the change. I don’t know much about third party beneficiary rights in other jurisdictions (except Ireland, where they only exist for the purpose of data protection law, but that’s another story). However, I know that New York state does have the ability to extend enforceable rights to third parties (someone else will be able to explain how explicit that extension of rights must be to be effective).


Incidentally, thinking this through a bit more, my proposed wording does not work so well in relation to the commercial distribution clause. So that potentially needs recasting.



Thanks in advance!

My pleasure - I hope all this makes some sense!

Best,

Till



Am 08.06.2017 um 15:24 schrieb Andrew Katz:
Hi all

Sorry to open the topic of enforcement yesterday. Thinking about this
some more, it’s very difficult for me to retain the current ambiguity
around who can enforce, and also incorporate third party wording, because
as soon as we add exceptions to the third parties who *can’t* enforce,
(e.g. upstream Contributors), we develop a cascade of complication,
including having to include (for English law) the words “the consent of
no third party is required to any variations or recession of this
Agreement” which in itself looks strange (any may cause problems with
waivers and exceptions), and then opens a new question: is this a mesh of
bipartite agreements, or a single multi-partite agreement.

So, in the enclosed draft, I’ve taken the upfront approach and (with
slightly more wording than we wanted, sorry), clarified that (1) the
licensing model is a mesh (or cascade) or bipartite agreements; (2) that
enforcement lies in the hands solely of the various upstream
Contributors.

The heavy lifting is done in a new paragraph right at the end of the
license, which reads:


The first time a Recipient,  having received a copy of the Program, uses,
reproduces or distributes it,  one or more bipartite contracts are
formed, each contract being between the Recipient and each Upstream
Contributor on the terms of this Agreement. Nothing in this Agreement is
enforceable by any entity other than the Recipient and its Upstream
Contributors, including any third party beneficiary.


I have added a definition for ‘Upstream contributor’ which is:


“Upstream Contributor”: a Contributor is an ‘Upstream Contributor’ in
relation to a Recipient if the Program as received by that Recipient
contains any Contribution of that Contributor.

I have also added slight variants of the following wording to clauses,

It is a condition, enforceable solely by each of its Upstream
Contributors, that if a Contributor Distributes the Program as Source
Code, then...

However, if we remove the ability of Recipients to enforce in the new
para 7, so it reads as follows, we would no longer need this additional
wording:

The first time a Recipient,  having received a copy of the Program, uses,
reproduces or distributes it,  one or more bipartite contracts are
formed, each contract being between the Recipient and each Upstream
Contributor on the terms of this Agreement. Nothing in this Agreement is
enforceable by any entity other than a Recipient's Upstream Contributors,
including any third party beneficiary.

This makes the Agreement completely unenforceable by Recipients (who,
under English law at least, are still able to use it as a shield against
a copyright claim from Upstream Contributors, provided they have complied
with the terms). I comfortable with this concept in the context of a GPL
bare license model, but I need to think it through a bit more in the
context of a contract. However, the overall intention here is make the
licensing structure more clearly like a GPL cascade.

I would have thought this clarification would be attractive to existing
licensors, as it immediately shuts down a huge number of potential
claimants, in that recipients can no longer enforce; only upstream
contributors.

Feel free to shoot this idea down in flames - I appreciate it does
immediately raise a number of issues that we may not be ready to address
right now.

Document is enclosed in Word and .pdf formats. Unfortunately, my copy of
LibreOffice mangles the document when it tries to open it.

By the way, would it be ok to bring my colleague Katie Osborne (copied
in) in on this conversation? She wrote the IFOSSLR article on EPLv1 a
couple of years ago and I know Mike you invited her onto the mailing list
a while ago, but she was on maternity leave at the time. She has now
returned and is keen to add her expertise!

Best


Andrew







Andrew Katz Moorcrofts LLP

Corporate Law | Technology Law | Commercial Law | Employment Law Employee
Incentivisation & Share Schemes | Intellectual Property Law Commercial
Property Law | Secured Lending

Thames House, Mere Park, Dedmere Road, Marlow, Bucks SL7 1PB +44 (0) 1628
470003 (phone) |  +44 (0) 7970 835001 (mobile)
www.moorcrofts.com<http://www.moorcrofts.com/><http://www.moorcrofts.com/>

Partners - Adrian Phillips, Andrew Katz, Theresa Hunter, Ian Hylton,
Peter Woolley, Matthew Jenkin Registered in England & Wales OC 311818
Regulated and authorised by the Solicitors Regulation Authority "Partner"
means a member of Moorcrofts LLP, or person of equivalent status,
qualifications or experience. THIS EMAIL IS CONFIDENTIAL. IF YOU ARE NOT
THE INTENDED RECIPIENT, PLEASE LET US KNOW. We store email addresses and
the names of addressees to assist with future correspondence.



_______________________________________________ epl-discuss mailing list
epl-discuss@xxxxxxxxxxx<mailto:epl-discuss@xxxxxxxxxxx> To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/epl-discuss

_______________________________________________
epl-discuss mailing list
epl-discuss@xxxxxxxxxxx<mailto:epl-discuss@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/epl-discuss