Scala Individual CLA

[Michael Slinn]

I would like to share a few comments about the Scala Individual Contributor License Agreement. I have cc'd the designated contact at EPFL for issues pertaining to this document, Danielle Chamblerlain.

The first paragraph states that the purpose of the Agreement is "This license is for your protection as a Contributor as well as the protection of EPFL". I believe that the Agreement as currently written does not protect individual contributors in any way, and strongly favors EPFL in every way.

1. The jurisdiction is not stated. Normally, legal documents state jurisdiction, especially agreements that are international in scope such as this one. The jurisdiction is usually stated with a sentence like "This Agreement is subject to the laws of XYZ." Without stating jurisdiction, it is unclear how to interpret the document. For example, if interpreted under German law, the document would have much different scope and meaning than if it were interpreted under US law. Ambiguity of this sort favors the party with greater resource, namely EPFL. I recommend that a jurisdiction be adopted and incorporated into the document. I do not have an opinion or recommendation for a preferred jurisdiction.
2. The Agreement requires that the individual grant copyright and patent rights to EPFL, and to notify EPFL of any potential transgressions or material events in the future, by any party, without limitation. This is unreasonable and one-sided. Yes, similar language can found in other agreements of this sort, but it is not always phrased in such terms.
3. The Agreement fails to hold the contributor harmless in the event of litigation brought against EPFL through no fault of the contributor. In this sense the Agreement is one-sided: it requires the contributor to make warranties but offers nothing in return.

I believe that an equitable Contributor Agreement is a reflection of the nature of the relationship between the parties. The best agreements are mutually equitable. A one-sided Agreement such as this is inequitable and does not respect the rights or motivations of individual contributors. I believe that addressing these issues would be a positive step towards improving the Scala community.

Mike

[Miles Sabin]

The Scala license and CLA have come up before. It's something Typelevel
would very much like to see changed to consistently Apache 2.0 for
both the license and the CLA.

There isn't a problem with either the license (three clause BSD) or
the CLA (effectively the Apache 2.0 ICLA) individually ... both are fine
in their own right.

The problem is that they're mismatched. The three clause BSD license
is silent on patent licensing, and would typically be paired with a
CLA which is also silent on patent licensing. The Apache 2.0 ICLA
requires contributors to grant a patent license and is typically
paired with the Apache 2.0 license which grants a patent license in
return. By pairing the three clause BSD license with the Apache 2.0
CLA you end up with an asymmetric situation where contributors have to
grant a patent license, but Lightbend/EPFL don't grant one in return.

I'm sure this is either an oversight or, just as likely likely, nobody
wants to deal with this tedious legal stuff. But it is important, and
I think it should be addressed.

Cheers,


Miles

> --
> You received this message because you are subscribed to the Google Groups
> "scala-debate" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to scala-debate...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Miles Sabin
tel: +44 7813 944 528
skype: milessabin
gtalk: mi...@milessabin.com
http://milessabin.com/blog
http://twitter.com/milessabin

[Michael Slinn]

I think that an Apache-style license in conjunction with the suggestions I put forth would represent a fundamentally more equitable and enlightened restating of the role and status of contributors.

Mike

[Michael Slinn]

I raised a similar issue April 11, 2015 "Every project created by Activator is copyright Typesafe". I provide a link to it so everyone can read about it.

Speaking for Typesafe, havocp said (he was a Typesafe employee at that time):

We have had an internal discussion / round of advice on this already. The resulting policy is documented under "licensing" on this page: https://typesafe.com/activator/template/contribute

we require a liberal license and suggest public domain (aka "CC0") for seed templates and Apache for tutorials.

Activator doesn't make this decision though. It's case by case and up to the template author. Activator just copies what the author puts in the file.

I do think we intended to change some of Typesafe's seed templates to public domain and didn't do it yet. I'll confirm that. It isn't a change to Activator though, but to the templates. It will be up to other template authors how to copyright their stuff, except that we require something liberal (Apache style) to list in the catalog.

I agreed. Unfortunately, there was little or no follow-through. In June 2016 (more than a year later) I reported:

I just ran my script again. This issue has been ignored and has become worse.

56 seed projects now exist. No change for most seed projects: they still use the Apache or MIT license, except for the following which use the desirable CC0 license: cats-seed, finch-seed, libgdx-scala-seed, play-slick-codegen-flyway-seed, scala-forklift-with-slick-start-seed. No Lightbend seed projects currently use CC0.

Disturbingly, six seed projects fail to state a license. These should not be used: play-java-react-seed, primary-scala-scalatest-seed, primitive-scala-scalatest-seed, reactive-salesforce-rest-javascript-seed, salesforce-canvas-seed, spray-slick-seed.

So not only do we need agreement, but also follow through.

Mike

[Seth Tisue]

On Sun, Oct 23, 2016 at 4:09 PM, Miles Sabin <mi...@milessabin.com> wrote:

The Scala license and CLA have come up before.

see https://github.com/scalacenter/advisoryboard/blob/master/minutes/002-2016-q3.md#the-scala-license for a summary of a discussion of the subject at a Scala Center Advisory Board meeting earlier this year.

Seth Tisue / Scala team / Lightbend, Inc.

[Michael Slinn]

Thanks, Seth. I was not aware of that discussion. I appreciate Sam Halliday raising the issue and Bill Venners presenting it to the Scala Advisory Board 7 months ago.

Even if the license was made Apache-style, there might be a desire by some for a CLA. I think the deficiencies in the CLA could be addressed without changing the license. Obviously it would be best to also address the licensing issue, but some progress would be better than no progress.

So, to be clear, we are talking about two orthogonal issues, which combine to strongly influence individual and organizational contributors:

• An equitable Scala Contributor Agreement (this is what my posting was about)
  
• Better licensing (not essential to this discussion, but I would be happy if this magically crystallizes into a solution for the CLA issue)

Mike

[Miles Sabin]

Apache 2.0 includes both a provider license and a matching CLA.

Cheers,


Miles

[Miles Sabin]

From the conversation we had later, I thought we'd concluded that the
main issue, the mismatch between the provider license and the CLA,
wasn't clearly in the foreground of the advisory board discussion.

I think it would be helpful to raise it again.

Cheers,


Miles

[Michael Slinn]

Thanks, Miles. I did not know that.

It seems, then, that changing the license would solve all problems. If that is unattainable in the short term, then an interim improvement would be to simply improve the existing CLA. I agree that bringing up the matter again seems like a good idea.

Might it be helpful if the programming public (Scala users) became aware of the issues, why it matters and how it affects them? Perhaps an article co-written by interested parties with varying points of views ("pros and cons"), with an opportunity for the programming public to add their voice, and an attendant survey so readers could vote on the issue once they are informed? The article, comments and survey results could be presented to the board.

Mike

[pagoda_5b]

On Monday, October 24, 2016 at 8:48:52 PM UTC+2, Michael Slinn wrote:

Thanks, Miles. I did not know that.

It seems, then, that changing the license would solve all problems. If that is unattainable in the short term, then an interim improvement would be to simply improve the existing CLA. I agree that bringing up the matter again seems like a good idea.

Mike

I support your idea, and would  be pleased if someone would be so kind as to better explain the topic for general public consumption.

I appreciate that people raise up the flag for issues that are usually glossed over or poorly understood.

Thanks

Ivano

[Michael Slinn]

pagoda_5b, the motivation that drove me to start this thread was to press for an equitable Scala Contributor Agreement. I'll let Miles or Sam address their motivations; although I completely agree with them, I know they have been working on their side for some time and they can probably provide a better explanation than me for the aspects that they are focusing on.

In summary, the Agreement states:

1. Contributors get nothing.
2. Contributors are required to protect EPFL from lawsuits, but no mention is made of compensation for doing so.
   
3. Contributors are not protected from lawsuits.
4. EPFL assumes all rights to the work done by contributors, and is allowed to do whatever they want with their contributions. EPFL's business model is in fact to license the work and makes money from it.
5. Not stating a jurisdiction means that the governing body of law is unknown.
6. This Agreement never expires.
   

Here is an example. You might think it somewhat fantastic, but I've worked as an expert witness in quite a few court cases in the US and Europe, and I assure you this stuff happens. Bad things do happen to good people. Lets pretend EvilCo in Lower Slobbovia (a made-up country) has a problem that they blame on a Scala-related fault. Perhaps the documentation was vague, and the Scala compiler programmers and documenters assumed one interpretation, but the programmers at EvilCo believed another interpretation applied. In this fantasy/nightmare, Bad Things Happened; people died, fortunes were lost, and now the search for a scapegoat is underway. EvilCo's PR department spins a tale of woe, and blames Scala. EvilCo, under pressure from shareholders and survivors of the disaster, decides to sue anyone related to Scala, and focuses on the feature. Any and all individuals who contributed or reviewed the PRs related to that feature now find themselves summoned to Lower Slobbovia to face trial, and because Lower Slobbovia has extradition treaties with most countries, the contributors find themselves paying for round-trip tickets to Lower Slobbovia and for extended stays in a hotel, where they are required to remain for several weeks or months at their own expense. Most of them lose their jobs as a result of missed work, and many families fracture under the strain. According to the agreement as it currently exists, EPFL is not required to help the contributors in any fashion during this process. The contributors also have no recourse against EPFL. Because there is no jurisdiction for the Agreement, there is no legal means for them to seek justice or even support from EPFL - few individuals could afford the legal expense to litigate the question of the jurisdiction.

Let's look at the current Agreement, section by section:

1. The title of the Agreement is "Software Grant and Individual Contributor License Agreement ("Agreement"), v1.0". This tells us that individuals are signing away any claim to their contribution (normally software and/or documentation) that they created.
2. "In order to clarify the intellectual property license granted with Contributions from any person or entity, EPFL must have a Contributor License Agreement ("CLA") on file that has been signed by each Contributor, indicating agreement to the license terms below. This license is for your protection as a Contributor as well as the protection of EPFL; it does not change your rights to use your own Contributions for any other purpose." This sounds great, but the agreement only addresses issues that favor EPFL and does not consider anything that might be of interest to a contributor.
3. "You accept and agree to the following terms and conditions for your present and future Contributions submitted to EPFL. Except for the license granted herein to EPFL and recipients of software distributed by EPFL, You reserve all right, title, and interest in and to Your Contributions." Sounds good, right? This paragraph is undermined by the paragraphs that follow.
4. Some definitions follow. They are rather long, but not unreasonable.
5. "Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to EPFL and to recipients of software distributed by EPFL a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works." This means EPFL has copyright and distribution rights for the work and they can incorporate the work into anything they like. You get nothing in return ("no-charge, royalty-free"). The interpretation of "non-exclusive" "copyright" varies wildly around the world. Sam Halliday can tell you about the German interpretation. I am sure that the attorneys that I have worked with in the US would be able to make that sentence mean whatever they need it to mean. Lack of jurisdiction destroys any meaning that this section might have.
6. This next section, Grant of Patent License, is also very bad. It is long, so I'll paraphrase it:
1. Contributors assign all patent rights to EPFL, in return for nothing
2. Contributors promise to protect EPFL from any problems, however caused, forever, at their own expense. It is important to know that in the US, anyone can launch a lawsuit; merit is not considered by the courts when court documents are filed. Using the courts to attack rivals is a common tactic in the US. A company selling a rival compiler could sue EPFL in the US for no reason than to cause trouble, and contributors might find themselves defending EPFL at their expense, at any time in the future. While EPFL would easily survive such an attack, any contributors unlucky enough to be subpoenaed could be devastated.
   
3. Contributors promise to inform EPFL of any potential legal issues relating to their contribution, forever, at their own expense, without limitation. There is no end of potential legal issues, depending on one's interpretation and motivation. Section 8 echoes this sentiment, again without limitation, now and forever: "You agree to notify EPFL of any facts or circumstances of which you become aware that would make these representations inaccurate in any respect."
7. "Unless required by applicable law or agreed to in writing, You provide Your Contributions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE." So the question is, what is the applicable law? This is undefined. Many jurisdictions uphold the notion of implied warranties and related concepts. That means this section probably offers no protection to the contributor. BTW, writing in ALL CAPS does not make the text any more enforceable, it is simply a technique meant to intimidate the reader.
   

This Agreement as it exists could spell financial and personal ruin for contributors, and provides a basis for EPFL to run a business that profits from unpaid volunteers. I seek a fair and equitable agreement that respects the rights and interests of all parties, and recognizes that individual contributors are fundamentally not on an equal footing with EPFL. I do not have a problem with EPFL running a business. EPFL should assume all risk, howver, except in circumstances where contributors have broken applicable laws; this of course assumes that those laws are described in advance. Normally one would say "ignorance of the law is not an excuse", but if a jurisdiction is selected that is in a different country than that of a contributor, it is unreasonable to assume that the contributor would or should attempt to learn those laws. This is where Apache-style licensing comes into play. I'll let Miles or Sam take it from here.

Mike

[Adriaan Moors]

I know this is scala-debate, and I'm no lawyer, so I'm not here to give legal advice, but there seem to be a few exaggerations in your characterization of our (Apache 2.0) CLA...

I thought the discussion was about the CLA requiring you to grant EPFL a license to any patents related (and licensable by you) in your contributions, whereas Scala's BSD-3 license does not have the reciprocal clause. I don't see how this has anything to do with being ruined by having to go to some country, made up or not. My understanding is that it aims to take software patent claims our of the picture as a liability in accepting contributions.

You seem to imply a CLA should somehow protect contributors against suits by third parties. Can you provide an example of a CLA that does that?

cheers

adriaan

--

[Michael Slinn]

Adriaan,

I'm not implying anything, I made some very direct statements, as concretely as I could.

Seems you have adopted a contrary position, although I am unclear what you base that opinion on, or which of the two parties that you identify with. Should we assume you do not speak for EPFL? Obviously you cannot speak for individual contributors. I think your status in legal terms is "lacks standing" and/or conflicted.

Cheers,

Mike

[Michael Slinn]

Danielle,

You are the official EPFL contact shown below the "Software Grant and Individual Contributor License Agreement ("Agreement"), v1.0". Four days ago I invited you to participate in this discussion, but you have not responded. We respectfully ask that someone reply to this thread on behalf of EPFL, who is authorized to negotiate the issues raised.

The courtesy of an acknowledgement by yourself is requested.

Thank you,

Mike Slinn

[Lukas Rytz]

Mike,

Danielle is administrative staff at EPFL, she used to handle CLAs while

they were still in paper form and required a hand-written signature. That's

as far as her involvement goes in this :)

Cheers: Lukas

--
You received this message because you are subscribed to a topic in the Google Groups "scala-debate" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-debate/ryr2q18b74w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-debate+unsubscribe@googlegroups.com.

[Paolo Giarrusso]

Mike, you're avoiding the question with legalese in a discussion between community members. IMHO that's not a helpful strategy for your goals.

As a contributor, let me iterate this question:

> You seem to imply a CLA should somehow protect contributors against suits by third parties. Can you provide an example of a CLA that does that?

If you meant something else, please say so.

I'm also unconvinced of the substance of your summary. IIUC https://www.lightbend.com/contribute/cla/scala/current talks only about patent litigation (please provide direct quotes to the contrary), and IIUC simply states that if a contributor is sued by EvilCo in *patent litigation*, EviLCo loses the patent license that you granted to it.

The relevant paragraph starts with

> If any entity institutes patent litigation against You or any other entity [...]

I'm finally unconvinced by your claims about the EPFL business model; up to now, you have tentatively convinced me that the CLA *would allow* for that model, *if we ignored* for a moment that the software in question is open source.

On Thursday, October 27, 2016 at 1:21:22 AM UTC+2, Michael Slinn wrote:

Adriaan,

I'm not implying anything, I made some very direct statements, as concretely as I could.

Seems you have adopted a contrary position,

No, Adriaan asked a question which you're avoiding.

 

although I am unclear what you base that opinion on, or which of the two parties that you identify with. Should we assume you do not speak for EPFL? Obviously you cannot speak for individual contributors. I think your status in legal terms is "lacks standing" and/or conflicted.

Quoting A Few Good Men, this "looks like a bunch of fancy lawyer tricks".

[Paolo Giarrusso]

On Thursday, October 27, 2016 at 12:22:47 PM UTC+2, Lukas Rytz wrote:

Mike,

Danielle is administrative staff at EPFL, she used to handle CLAs while

they were still in paper form and required a hand-written signature. That's

as far as her involvement goes in this :)

Thanks for clarifying, but that probably means this line from https://www.lightbend.com/contribute/cla/scala/current should be changed, dropped, or redirected to some scala mailing list if there's no speciifc responsible?

> For more information please contact danielle dot chamberlain at epfl dot ch. 

But I can at most file an issue for that ;-)

Cheers,

Paolo

On Thu, Oct 27, 2016 at 11:55 AM, Michael Slinn <msl...@gmail.com> wrote:

Danielle,

You are the official EPFL contact shown below the "Software Grant and Individual Contributor License Agreement ("Agreement"), v1.0". Four days ago I invited you to participate in this discussion, but you have not responded. We respectfully ask that someone reply to this thread on behalf of EPFL, who is authorized to negotiate the issues raised.

The courtesy of an acknowledgement by yourself is requested.

Thank you,

Mike Slinn

--
You received this message because you are subscribed to a topic in the Google Groups "scala-debate" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-debate/ryr2q18b74w/unsubscribe.

To unsubscribe from this group and all its topics, send an email to scala-debate...@googlegroups.com.

[Sam Halliday]

Thanks Seth,

From various people I've spoken to, I did a terrible job of explaining what I was trying to bring up. The original ensime points are here:

http://ensime.github.io/contributing/center/#licensing

I think the CLA is perfectly reasonable, but it's the scala licence that I'd like to see become Apache 2.0. Martin more or less hinted that changing the current situation would involve long protracted discussions with their legal department, which sounds painful no i can understand everybody's desire to avoid it. It is concerning when one realises how many noftwace patents EPFL owns (even in the USA) but I guess we're all willing as a community to trust that EPFL are not planning on coming after users of scalac for patent royalties.

The request in this thread for a designated jurisdiction would be something I'd completely be against. Apache doesn't do it, but Typesafe do, and it's the sole reason I don't sign the Typesafe CLA (different to the Scala CLA). There is absolutely no way I am signing anything that moves my rights to the Caliornian legal system. Jurisdiction of the defender is the norm.

Best regards,
Sam

[Mike Slinn]

Lukas,

Thank you for the information. Danielle is shown as the official
contact. If the information is out of date it should be updated.

I see that you are at Lightbend; I am pleased to 'meet' you. Your
response, and the web of connections between Lightbend and EPFL, shows
that my request should be sufficient for the appropriate person at EPFL
to step forward at this time.

Thank you,

Mike

[Paolo Giarrusso]

(Dropping Danielle Chamberlain from this email thread, sorry I forgot before).

I've taken a closer look, and I currently agree with Miles Sabin's arguments over Michael Slinn's arguments, though I'm open to more convincing arguments. Of course, I'm no lawyer.

Most have already argued they're fine with the current CLA. I'll engage with some of its criticism anyway.

- Miles claims the CLA matches Apache's ICLA. However, Apache's ICLA I guess assigns copyright to the Apache Foundation (a US charity), while this CLA assigns it to the EPFL, which allegedly has a business model of making money from the licensed work.

- That sounded implausible, but I've looked into it a bit more. However:

1. I've never seen companies license BSD/Apache work, that only makes sense for GPL work (as e.g. the MySQL company used to do).

2. EPFL is a public institution: "EPFL, like ETH Zurich, is thus directly controlled by the Swiss federal government." (https://en.wikipedia.org/wiki/%C3%89cole_Polytechnique_F%C3%A9d%C3%A9rale_de_Lausanne).

Opinions might differ, but a public institution is in principle just as trustworthy as a charity — their past behavior counts. In both cases, all they've done is simply redistribute the work under a free software license. Or rather: Martin's research group distributed software, and I'm not aware of anything "EPFL itself" did beyond employing them.

3. "Software has no warranty" is an often repeated statement which always checked out until now — since Michael challenged this fact, I'd appreciate a reference.

4. I'd assume that changing the license to a different standard open source license (promising only a patent grant) would be easier than getting EPFL to promise legal assistance to contributors (hence, potentially, actual money), and I'd have guessed (even before Sam's email) that even changing the license would be overly complicated because of the involvement of university lawyers.

I've been employed in multiple public universities (especially in Germany), and any interaction with university lawyers took immense effort. Assigning copyright to a foundation would probably also not work easily: my contracts assigned to the university copyright over what I produced as part of my job, and I'd guess the same is true for EPFL.

5. Finally, as a layman, if you bring up nuisance lawsuits, I'd like to know why contributing to Scalac exposes me to additional ones.

Cheers,
Paolo

[Michael Slinn]

Paulo,

You have mischaracterized what I said to some degree. Before we get into that discussion I'd like to ascertain your status. I believe that you are a Ph.D. student in the Programming Languages and Software Engineering research group at the Department of Mathematics and Computer Science of University of Marburg, Germany. Have you signed this agreement as an individual, or are you contributing under some other aegis, or are you not a contributor?

Thank you,

Mike

[Adriaan Moors]

Michael please stop the personal "approach" you're taking here. This does not in any way contribute to the topic. If you fail to live by our code of conduct, I won't hesitate to put your account on moderation until you can find a way to abide by it.

--

[Mike Slinn]

Adriaan,

I take exception to your unfounded negative characterization of me.

Is it your intent to make an example of everyone who does not share your world view? The list seems ever-growing since you became moderator. Peter Hintjens said it well here and here. Peter also discussed contracts.

I understand that there is a high likelihood of retaliation for challenging your behavior. I will continue to aspire to behave in accordance with the highest standards, and part of that is refusing to be intimidated. I believe that you should either apologize or excommunicate. "Muzzling", or censorship, is effectively excommunication.

Mike

[Naftoli Gugenheim]

Hi Michael. I'm curious why you want to know what Paulo's status is, could you explain?

--

[Adriaan Moors]

My world views have nothing to do with what is appropriate behavior on a technical forum like this. In any case, Michael, you're doing a great job of making an example out of yourself all by yourself.

More generally speaking, this is a forum for technical debate, not for personal attacks, no matter how thinly veiled. As an example from your recent behavior, dragging people's backgrounds or affiliations into a discussion of the legal merits or drawbacks of our CLA / license mismatch is not acceptable behavior, and I won't stand for it.

 

A requirement for anyone having a voice on this forum is that it be used constructively (that includes criticism, of course) for the discussion of ideas (not people), for the advancement of Scala, its community and its whole eco-system. If you are not willing or able to do that, this is not the place for you.

I will use every tool available to me to prevent this forum from being used for harassment of any kind, and don't even think of giving me this petty "oh no I'm a victim of censorship bullshit". We are not the government, and this is not the only forum available to you. We state clearly what this forum is for, and you chose to ignore our rules. We don't owe anyone a podium for attacking others, or harming our otherwise shared goals of improving all things Scala.

Very sincerely,

Adriaan Moors, Scala Team Lead at Lightbend

[Russ Paielli]

Hey guys, I have no dog in this fight, but I would like to make a brief comment. There is a place for public communication, and there is a place for private communication. When things start getting personal and contentious, that is usually when private communication is more appropriate. I think Adriaan's admonition of Mike should have been private. And perhaps Mike's query about Paulo's status too. Making these things public just creates resentment. I'm pretty sure Mike is a strong Scala advocate, and it would be foolish to alienate him over something like this if you care about promoting Scala. Thanks.

--Russ P.

--

You received this message because you are subscribed to the Google Groups "scala-debate" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

http://RussP.us

[Mike Slinn]

Naftoli,

Certainly. I merely wanted to ascertain whether he is a party to the agreement or not, or in other words, whether he "has standing" or not. Nothing personal.

Thank you,

Mike

[Naftoli Gugenheim]

Ok, and why do you want to ascertain that?

[Adriaan Moors]

Fair enough, but by letting these public statements stand we're sending an implicit message that we condone this behavior. We do not.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

http://RussP.us

[Adriaan Moors]

I think this topic has veered far enough off course that it would be fair to ask to please stop this subthread, in order to free up energy for discussing the important original topic.

[Mike Slinn]

Naftoli,

My purpose is to negotiate an more equitable agreement. The first step is to identify whom at EPFL is authorized to discuss the agreement. Seems that is not easy to do. People who are not a party to the agreement are not affected by the outcome, and may contribute in such a way that hinders the best outcome for the two parties. Many technical people have opinions about legal matters, but little experience. Thus unrelated parties are likely to add more confusion to the process, and not smooth the way. By way of a counter-example, Lightbend employees physically at EPFL are in a good position to identify and introduce the appropriate EPFL person to this discussion.

Thank you,

Mike

[Adriaan Moors]

This thread is not going to reach EPFL's legal department. We are talking to Miles, Sam and others to have this discussed at the next Scala Center Advisory Board meeting.