EVE Technology Lab

Problem 1)
its geared towards application developers, and application developers only. It does not properly cover libraries such as pheal, perry, eaal (and many others), which are pieces of software that are used by other applications to access the "Crest or any other CCP tool". (Definition 1.2, Application).
The Grants in 2.1 further more do only allow display and distribution within the application, meaning that even if 1.2 would cover such libraries, the grant does not cover it. To explain what such libraries do in terms that someone who is not a software developer might understand: they cover the transport (and transformation to a datastructure native to the language used) between the CCP tool an the runtime environment of the application. Most larger EVE applications make use of such libraries (for example zkillboard, edk, evemaps use phealng).

Problem 2)
2.2 does prohibit offering own apis for the data. For example, edk and zkillboard both have apis / feeds through which they syndicate and exchange killmails which have been pulled from CCPs API or CREST.

Good luck.

I don't see a problem here. You don't need a license to write a library that allows your forum to authenticate using the sso endpoint... you will need the license for the application that uses the library.

I guess there will be some kind of api key that you only get if you sign the license... the library developer won't need them but the runtime environment will.

The problem I see is applications that run at the end users system.. like evemon. How would a developer put his key in the app without the risk of exposing it ? It would require some kind of app signing .. but I guess that is out of scope ,)

• the license is not about sso only
• the license is about how you are allowed to interface with eve, something that has long been missing and problematic, especially with the eula/terms of service prohibiting you from developing that stuff.
• not covering the libs *is* problematic, for example because in the very nature on how such lib needs to be build, libs like perry carry information on how the apis of ccp look, which is CCPs property.
- and with the license not applying to libraries, that means i still don't have anything for my libs there where ccp acknowledges what they recognize in 3.7 for applications.

i'm not pointless raging, i have invested *a lot* of time this year in this subject. I'm pointing out that this license (which i had several ccp guys say to me would solve my worries) is not solving all problems.

Fine, i can apply this to my Fansite, i can sign this for the SSO trials, but all the other work i've done is still not in a spot where i don't feel confident about being safe.

So what should i do?
I decided to mention the problem (which i just did) (again) before i sign something (and then have to pull down everything that is not covered by that license, just to be safe).

I want this to be a dialog and i want this to be fruitful. Despite having invested a lot of time into something i dislike doing (like: reading all that legal stuff, getting people who are actually a bit better in this to talk to me and point out how certain things actually work and what the risks are) i still believe that we all want the same thing, and that is putting this on a basis where we (3rd party guys) can improve the game.

So frankly, if you don't care about the why, or if you don't care about what i'm pointing out - please stay out of it, rather than to just declare it "no problem".

I basically still have the same 2 questions I had about the old license a year ago:

1. If my application includes (a part of) the SDE data in a way that would theoretically allow someone else to access that data outside of my app (e.g. by opening the files containing the SDE information with a text editor or whatever), is that covered and allowed by section 2.1 or would I be violating section 2.2? It would be strange if redistribution of publicly available data (like the SDE) was forbidden just because it might be accessible outside of the app.

2. I still don't see what section 8 has to do with 3rd party development and I find it exceedingly weird that you would have me sign that I'm obligated to be your copyright snitch. It's alright to let me sign that I don't violate your IP rights, but I really don't see why I should have to assist you when others do. Don't get me wrong, I like CCP and EVE, so I'd probably do it anyway, but that still is no reason to contractually bind me to do it.

Btw, typo in 2.1: non-transferrable

I see the same outcome, different reasoning.



Then...



Your API is within the scope of your Application, used for the purpose. Period. Your example seems straight forward.

Further I would argue that displaying kills data in a proprietary format distinct from CCP's CREST API specification which is also machine-readable as a web page within the zkillboard site is in fact one of the purposes of the zkillboard application: validating and republishing aggregated kills data. The ZKillboard API then becomes a non-issue.

3rd-Party provided language-specific SDKs (otherwise referred to as libraries) are still in a bit of limbo here as I read things. It really isn't clear to me if that can qualify as it's own Application with a legitimized Purpose under these terms.

This needs further clarification from CCP so we understand clearly, preferably available in the form of a standard diff performed on the agreement between revisions. Most of us don't have legal teams to help us interpret this stuff, and we can use all the help we can get.

Were there any thoughts on a paid dev license that would allow 3rd party apps to charge rl money ?

I was thinking more about the question of 3rd Party Libraries / SDKs and because the Library itself can act as a conduit or intermediary to pass an application's keys through it rather than relying on it's own keys there may be a way to provide safe harbor or that safe harbor may already exist such that 3rd Party Library authors would not need to be licensed 3rd Party Developers themselves in order to provide a library which facilitates authoring licensed applications -- each of which then would need to be in full compliance of the license otherwise.

Just kicking some thoughts over the wall to see what I'm missing...

Yes, that is going to have to happen. Everyone who installs your killboard would have to sign up so they can get a secret key and app ID in order to access CREST and the SSO.

Let me put it to you this way, once this is out and people are using app IDs and secret keys, if a specific app goes haywire and we deem it to be doing bad stuff we will ban that app ID. As a developer of an open source project you don't want one guy to go and install you application, make some changes to it that cause it to hammer our servers at 300 RPS, and then suddenly we ban every instance of your killboard.

This is how APIs work on the internet. There is an open source mobile app for Reddit that uses their API. The source code does not contain an app ID or secret key. When you install the built version it has that stuff but the source does not. If you fork the source or build from source you have to provide that app ID and secret key.

Generally speaking, it's fairly easy for us to find who the original developer for something is even if there are a lot of people running something. Especially if you are kind enough to provide a good user agent, even more so when you are registered as a third party developer.

I have two questions outstanding with people responsible for the DLA with regards to libraries and third party APIs.

Those questions our out and we will wait for their answers.