These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE Technology Lab

 
  • Topic is locked indefinitely.
12Next page
 

Third Party Developers License

First post First post
Author
CCP FoxFour
C C P
C C P Alliance
#1 - 2014-05-27 12:21:14 UTC  |  Edited by: CCP Logibro
Hey guys,

I know a lot of you have been asking for an update on the developer license agreement. I am here to provide you an update.

The main point I want to stress is this document is not yet in effect. We are posting it so you guys have an update as to where it is and what it says.

With that out of the way here is the current version of the license (that is again not yet in effect): http://cdn1.eveonline.com/community/forums/EVE/Developer_License_Agreement_2014_05_26.doc

There is also a wiki article here: https://wiki.eveonline.com/wikiEN/index.php?title=Developer_License_Agreement

I am bad with words so feel free to make that page make more sense.

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.

Peter Powers
Terrorists of Dimensions
#2 - 2014-05-27 12:30:42 UTC
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.

3rdPartyEve.net - your catalogue for 3rd party applications

Sentient Blade
Crisis Atmosphere
Coalition of the Unfortunate
#3 - 2014-05-27 12:38:48 UTC
Quote:
13.1. Force Majeure. If either Party should fail in the performance of any obligation under this Agreement by reason of acts of God, acts of war or terrorism, labor strikes, civil riots, governmental seizure, orbital bombardment, or other cause, without fault and beyond the reasonable control of the Party obligated


Don't be silly... as if anyone will be playing DUST by the time this comes out.
Seith Kali
Caldari Provisions
Caldari State
#4 - 2014-05-27 13:19:06 UTC
Quote:
At a later date, CCP may choose to begin charging fees or collecting royalties for the

rights granted herein. However, CCP shall provide Developer of no less than ninety

(90) calendar days’ notice prior to doing so, and in accordance with Section 6.4,

Developer may terminate this Agreement upon written notice to CCP.


Good luck.

Apprentice Goonswarm Economic Warfare Consultant - Drowning in entitlement and privilege. 

Jarnis McPieksu
Aliastra
Gallente Federation
#5 - 2014-05-27 13:55:28 UTC
Seith Kali wrote:
Quote:
At a later date, CCP may choose to begin charging fees or collecting royalties for the

rights granted herein. However, CCP shall provide Developer of no less than ninety

(90) calendar days’ notice prior to doing so, and in accordance with Section 6.4,

Developer may terminate this Agreement upon written notice to CCP.


Good luck.


Indeed. This is a nice bait-and-switch clause.

"Please spend a ton of time and effort to make a shiny app that supports our product and adds value to it. Then pray that we do not alter the deal. Much."
Anjanka
Interstellar Crime Scene Investigation
#6 - 2014-05-27 14:08:30 UTC
Peter Powers wrote:
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).


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 ,)
Seith Kali
Caldari Provisions
Caldari State
#7 - 2014-05-27 14:55:57 UTC
Jarnis McPieksu wrote:


"Please spend a ton of time and effort to make a shiny app that supports our product and adds value to it. Then pray that we do not alter the deal. Much."


This deal gets worse all the time...

Apprentice Goonswarm Economic Warfare Consultant - Drowning in entitlement and privilege. 

Peter Powers
Terrorists of Dimensions
#8 - 2014-05-27 15:07:00 UTC
Anjanka wrote:

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


3rdPartyEve.net - your catalogue for 3rd party applications

Anjanka
Interstellar Crime Scene Investigation
#9 - 2014-05-27 15:23:04 UTC
I did not say that there is no problem ... I just said I see no problem.

So you want a dialog? Part of a dialog is to read and answer to people with other opinions that might have not your opinion or insight without getting into rage... Calm down bro.
Rob Crowley
State War Academy
#10 - 2014-05-27 16:10:36 UTC
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
Slvrsmth
Native Freshfood
Minmatar Republic
#11 - 2014-05-28 10:38:51 UTC
2.2:
Quote:
...Developer shall not knowingly allow any third party to use or distribute, the Licensed Materials outside of the Application...


Example situation:

I have a web application that internally uses its own, publicly available JSON API, where some endpoints contain EvE data gained from CREST. The application is open source and well documented, including API documentation. I'm not explicitly encouraging anyone to use this API, but some people have read the documentation, and started using my API in their projects. As I read it, this is OK with the license, since I have not in any way blessed this access. Correct?

Carebearium - find the best solar system for you!

sembur
Sebiestor Tribe
Minmatar Republic
#12 - 2014-05-28 10:59:22 UTC
Slvrsmth wrote:
2.2:
Quote:
...Developer shall not knowingly allow any third party to use or distribute, the Licensed Materials outside of the Application...


Example situation:

I have a web application that internally uses its own, publicly available JSON API, where some endpoints contain EvE data gained from CREST. The application is open source and well documented, including API documentation. I'm not explicitly encouraging anyone to use this API, but some people have read the documentation, and started using my API in their projects. As I read it, this is OK with the license

I see the same outcome, different reasoning.

Quote:
2.1. CCP grants Developer...right...to: use, display, and distribute the Game Data solely within an Application used for the Purpose.


Then...

Quote:
2.2. Notwithstanding anything to the contrary in Section 2.1 above ...


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. Blink Most of us don't have legal teams to help us interpret this stuff, and we can use all the help we can get.
Myopic Thyne
Accounts Payable.
End Point
#13 - 2014-05-29 07:03:41 UTC
I concur with the above that libraries do not inherently meet the purpose, though I suppose one could reason that they allow the developer of an application to enjoy eve more by extent of allowing them to write the tools for eve more easily...? This is definitely some serious grey area and could use some clarification at a minimum.

I'm curious what works are artistic and literary that could be in an application that you want to lay claim to as Derivative Works as well, I find this quite odd.
Risingson
#14 - 2014-05-29 09:59:23 UTC
Were there any thoughts on a paid dev license that would allow 3rd party apps to charge rl money ?
Hel O'Ween
Men On A Mission
#15 - 2014-05-29 11:05:15 UTC
Seith Kali wrote:
Quote:
At a later date, CCP may choose to begin charging fees or collecting royalties for the

rights granted herein. However, CCP shall provide Developer of no less than ninety

(90) calendar days’ notice prior to doing so, and in accordance with Section 6.4,

Developer may terminate this Agreement upon written notice to CCP.


Good luck.


This depends on what you get in return for the money. And if there'll be different kinds of license: 1) an "altruistic" license - both CCP and you charge/earn nothing and 2) you pay royalties (like with various dev libs/APIs) and you're allowed to "market" your work.

EVEWalletAware - an offline wallet manager.

sembur
Sebiestor Tribe
Minmatar Republic
#16 - 2014-05-29 17:45:29 UTC
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...
Shellac Brookdale
Cutting Edge Incorporated
RAZOR Alliance
#17 - 2014-06-01 09:26:58 UTC
The current license version is really problematic for open source projects. If I'm going to create a open source killboard (e.g. as zkillboard does) I can't sign the agreement for all potential users who are going to install their own killboard instance on their webserver. As its open source anyone on of them could make modifications that would not be allowed within the license and theres nothing I could do about it.
So you'd need all endusers to sign up. Every corp admin who manages to install the killboard (or any other OSS tool) would need to sign up and submit its application which would basically just be a clone so you end up with 200 corp killboards in the 3rd party listing and with hundreds of contact persons who actually don't really know a big deal about the application.
CCP FoxFour
C C P
C C P Alliance
#18 - 2014-06-01 09:43:12 UTC
Shellac Brookdale wrote:
The current license version is really problematic for open source projects. If I'm going to create a open source killboard (e.g. as zkillboard does) I can't sign the agreement for all potential users who are going to install their own killboard instance on their webserver. As its open source anyone on of them could make modifications that would not be allowed within the license and theres nothing I could do about it.
So you'd need all endusers to sign up. Every corp admin who manages to install the killboard (or any other OSS tool) would need to sign up and submit its application which would basically just be a clone so you end up with 200 corp killboards in the 3rd party listing and with hundreds of contact persons who actually don't really know a big deal about the application.


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.

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.

CCP FoxFour
C C P
C C P Alliance
#19 - 2014-06-01 09:47:38 UTC
Risingson wrote:
Were there any thoughts on a paid dev license that would allow 3rd party apps to charge rl money ?


Not that I am aware of.

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.

CCP FoxFour
C C P
C C P Alliance
#20 - 2014-06-01 09:49:39 UTC
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.

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.

12Next page