Re: [epl-discuss] Who can enforce?

[Till Jaeger <till.jaeger@xxxxxxxxx>]

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.

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

3.
What is a "third party beneficiary"?

Thanks in advance!

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/>
> 
> 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 To change your delivery options, retrieve your
> password, or unsubscribe from this list, visit 
> https://dev.eclipse.org/mailman/listinfo/epl-discuss
>