Deprecation and Migration to Discord GameSDK #290
Comments
|
Will this new GameSDK have a license that is GPL 2 compatible? I need it to be able to keep adding it to open source software where rich presence would be useful. |
|
Will independent rich presence libraries still be supported or is Discord wanting to move only to GameSDK supported Rich Presence? What about this C++ library? Its practically just Rich Presence at this point and a lot of people still rely on it for not only their C++ projects, but bindings for their own Rich Presence implementation. |
|
This specific library is deprecated, but the underlying tech this library uses (namely our RPC implementation) is not deprecated and continues to be used (by the new SDK) and supported. |
|
So all the other Rich Presence libraries for the other languages have to either move to a custom implementation or be forced to use a "deprecated" library for the foreseeable future? |
|
How would I contribute to this new SDK? I only see a download link for a zip archive with sources and binaries. This seems like a major step backwards to me. Also, I can't sign in with that new place for feedback/feature requests. It just opens the sign in window, does some flashy animation and redirects me back without actually signing me in. |
|
I can't find a license for this new SDK. Is it not licensed? |
|
License: I'll get that handled. Independent RP Libraries: As night mentioned, the underlying RPC tech isn't changing/isn't deprecated. So you're welcome to continue developing independent libraries for Rich Presence specifically, as well as wrappers around the GameSDK, if you want to as well. Can't Sign In to Feedback: Might be that the site wasn't actually pushed live, my bad. I'll work with the folks who set up the site to figure out what's wrong there. |
|
Is there any reason not to have the source code for this on github? This method prevents others from contributing and improving the software directly through PRs like it was possible here. |
|
@MinnDevelopment We tried open source with this library, but we wanted a closed loop for development of the new sdk. People are required to use our binary instead of embedding source code into their games and other libraries (bypassing complexity of getting people to upgrade). additionally, we make assumptions about the sdk's version to allow for automatic upgrades where compatible. we think open source makes sense for certain things, but this is not one of them. |
|
Link to the feedback site should be updated now. Let me know if you can log into that. To briefly piggyback on what night said: At the time of the release of this first SDK, the people maintaining it were...well, me. With some help at the very beginning from Chris as the big issues were ironed out, and then Ben, for when stuff was over my head (which admittedly was fairly often, lol). The new GameSDK has an actual team of engineers behind it to fix things and add features. Further, the |
|
I still think open sourcing or at least have the code publicly available makes sense for the SDK since devs will have to have their code rely on it. It's not as easy to debug bugs with a closed sourced library compared to an open source one. It can be hard to tell if it's your code that's causing the bug or the black box. |
|
open source It is seemingly industry standard to have closed SDK, with all consoles and steam having some form of NDA closed library. This does exactly what sleepy said, create great confusion if it's the game or the SDK causing issues. From our experience with Party Crashers, closed source sdks are generally poorly documented and seemingly a magic black box. Just recently we had a bug in the game that took days to resolve only to figure out it's a bug in the SDK itself. While there are some excuses for closed source SDK on some platform, I don't really think there is any reason in this case other than to keep the code secret. I suppose one could argue maintainability is harder with many forks and unofficial ports to other languages having to be taken I to account. Other Libraries |
|
I'd say that just because this library is deprecated doesn't mean that tomorrow everything is going to break. The underlying functionality here is, as mentioned, nearly the same as the new GameSDK (though this one is cpp and the GameSDK is rust, for what it's worth). With the GameSDK also in a good number of big, live-ops games like Paladins and Warframe, we aren't exactly keen on breaking changes 😄 It's basically a long way of saying that yes, libraries that are wrappers around the core binding here will be relying on a deprecated library as their core, but I do not foresee any immediate fear of collapse of that core. |
|
Given that the SDK isn't under a FOSS-compatible license, this offers no forward migration path for games or tools with source under GPL licensing. |
|
What plans do you have for if something on your end breaks the Discord RPC at some point? I appreciate that you have plans to try stop the underlying functionality from changing, but I'd be extremely impressed and surprised if you manage to succeed at that indefinitely. |
|
GameSDK should have linux binaries, I would prefer not to have two different libraries to handle rich presence, networking and so on From what I read from the doc, there should be some binaries available for linux but the .zip does not contains the mentioned folder
|
|
@Masadow sorry about that, old documentation. We don't ship the |
|
I implemented RPC on a FOSS emulation application. I figure some features may be feasible but I thought I should ask
The application itself does not infringe any copyright, but it's all a legal gray area so I thought I should ask before even trying to integrate anything. |
|
Hmmm... guess not possible I figure I could still do lobbies/rpc and voice unless only published apps can use that. Do I have to publish my application on the store in order to use the SDK features? |
|
@fr500 that is interesting. I'm gonna raise that with our legal council here. Thank you for pointing that out. As far as we're concerned, no, you don't need to distribute on our store to use the SDK. That's why it's available for download freely from the docs 😄 EDIT: My lovely coworkers have schooled me on open source licenses, I now understand Clause 2.6 hah |
|
I'm a bit confused about the SDK stub feature. What happens when there's a change that requires new headers, like a method taking different argument? Will the stub not get the newer version, or will it crash until I recompile with updated headers? |
|
@msciotti so no solution for FOSS? RetroArch, citra, dolphin have RPC integration, but if that gets ever removed it would be impossible to move things forward (well technically there are a few possible workarounds but none of them are ideal) |
|
In https://discordapp.com/developers/docs/game-sdk/sdk-starter-guide, the Discord Game SDK link always refer to the 'latest' version. |
|
No, it's still there in the latest commit (c850283, 14 hours ago). It's in the store distribution agreement page, not the general legal page. Does that mean it only applies if you try to distribute through the store? https://github.com/discordapp/discord-api-docs/blob/master/docs/Store_Distribution_Agreement.md
|
|
Unless some good lawyers are hanging around this issue thread, I'd recommend perhaps instead writing into our gamedevs support at dis.gd/devsupport. Then we can go through proper channels to get legal questions answered. I am not a lawyer, and am not really comfortable diving into the details of a distribution agreement and the specifications of FOSS and GNU licenses. I am sorry to punt you to another place, but if it's paramount, you'll get a much better answer through that channel. |
Still broken too even after a month :~~~( |
|
Not broken so much as unsupported right now, but I plan to work on it. It's a little less simple than this repo because we have a lot of callbacks, and we autogen the C# bindings. If you'd like, you can use the example of this repo to change the C# binding (which is viewable in the ZIP download) yourself. |
|
There's no repo for the new SDK that we could submit PRs to though right? Wary of modifying things and then having to merge later. It's a tough sell to the engineering team for a large game to use a modified version of a 3rd party SDK - the maintenance burden of that ends up being seen as outweighing the benefits of using the SDK at all. I'm also concerned that it was a known issue in this SDK, then supported, then this SDK was deprecated and a new one was created replicating the same known issue - I feel, maybe incorrectly, that Unity is not a priority for Discord and not well tested internally and therefore dangerous to use. Do you have a timeline as to when this would be done? We're at a point where we have a hard decision to make. |
|
So, I spent some non-trivial time over the weekend attempting to get IL2CPP working in our new SDK, using the changes that had been made in this repo. I was, unfortunately, unsuccessful. The interface to the native code is significantly more complicated in our new SDK (you can compare the two C#) bindings, and on top of that, we autogenerate the bindings from the source. I've raised this issue again internally, pointing to possible resources to get it resolved. I won't make any promises, as I have no grounds on which to do so, but I am working to see if we can get this prioritized at all. |
|
Did anyone take @msciotti up on the suggestion to contact their gamedev support regarding the licensing issue? I'm wary of asking a question that might've already been answered a thousand times already and I'd like to know if the anti-foss clauses only apply to viral licenses like GPL, or if it goes as far as to apply to permissive licenses like BSD/MIT/ZLIB. |
|
I did, same response as here. |
|
I'll caveat this heavily: I AM NOT A LAWYER. THIS IS NOT LEGAL ADVICE. THIS IS ONE INDIVIDUAL PERSON'S READING OF A CONTRACT AND IF YOU'RE CONCERNED YOU SHOULD PROBABLY TALK TO AN ACTUAL LAWYER PERSON INSTEAD OF ENGINEERS AND PEOPLE PRETENDING TO BE ENGINEERS ON THE INTERNET The GPL license is hyper-restrictive, from what I can tell, and requires that any software distributed under that license be FOSS, which our GameSDK is not. Therefore, we do not allow you to distribute our SDK in such a manner, since that license requires that our software be FOSS, which it's not.
My understanding is that other licenses are less restrictive and may allow you to distribute non-FOSS software within them. In which case Discord would not be bound to oblige with contractual license obligations. I AM NOT A LAWYER. THIS IS NOT LEGAL ADVICE. THIS IS ONE INDIVIDUAL PERSON'S READING OF A CONTRACT AND IF YOU'RE CONCERNED YOU SHOULD PROBABLY TALK TO AN ACTUAL LAWYER PERSON INSTEAD OF ENGINEERS AND PEOPLE PRETENDING TO BE ENGINEERS ON THE INTERNET |
|
As for
Indeed, but this is not about releasing the GameSDK as free software, rather just use it in free software, either having the user manually add the SDK or shipping it along (the SDK itself not being under any kind of FOSS license). Dynamic linking makes this easy. |
|
Ah, our project is fine then. Thanks for the quick responses 😄 ❤️ |
|
Dynamic linking doesn't work around the GPL.
For steamworks icculus (I think) developed a shim/proxy that allows you to
work around it properly.
Something similar would be required.
…On Fri, Aug 23, 2019 at 7:22 PM Quinton Reeves ***@***.***> wrote:
Ah, our project is fine then. Thanks for the quick responses 😄 ❤️
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#290>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AANEFUHIT55JEDCGEP2DE3DQGB5LNANCNFSM4HJHXJMA>
.
|
|
As stated above, dynamic linking does not free you from the viral requirements of the GPL. See the GPL FAQ. If you are the project owner and have the power to change the software's license, it may be possible to add an exception to the GPL for each nonfree library you want to link. That will "weaken" the GPL for those specific libraries, preventing Discord from being bound by so-called "contractual obligations." |
|
IANAL but for our (@Vadi and my) project - being GPLed does allow us to distribute THIS library with our product because this library is MIT licenced - we just need to make sure we allow our users to know that we are using THIS library so that we comply with those terms. That is what means that we must stick to this product and not use the new GameSDK... |
|
@msciotti you got it wrong -- your own licensing is restrictive and does not allow for use of your new SDK with GPL licensed applications. Don't go and blame open source developers for your own company's decision to switch from a permissive license (MIT) to a proprietary SDK. All that will happen is that people will stick to using this deprecated lib, until it stops working or someone wants a new feature that's not exposed. Then we'll just write an open source replacement SDK that works against your IPC API directly (which to be fair we had already considered doing in the past) and you lose the ability to have any kind of control on client libraries ¯\_(ツ)_/¯ |
|
He's doing his best to help and isn't really responsible for the decisions of the company, don't take it out on an employee. |
|
🤷♀ I think at this point we've hyperexhausted the licensing question to the point that it can be answered in this issue. I'm not going to lock conversation because there may be other people that have a question not answered here that need this in the future. I would personally ask that we refrain from further legal questions on this issue in the future, as I am not a lawyer and cannot answer your questions, nor do I have control over the legal language of this SDK's terms of service. I've raised this internally a number of times and the answers I've written here are what have been given to me. I do very much apologize if the GameSDK isn't a drop-in replacement for GPL-licensed games. |
|
Thanks for your assistance nonetheless @msciotti 😄 I've since realised that GameSDK doesn't support |
|
It should support macOS—I dev on macOS almost daily with it. Linux is not something we support right now, that's correct. I don't have an ETA on that support unfortunately but I'm happy to raise it internally again and find out. |
|
Ah yep, you're right. I missed the |
|
@msciotti I am wondering, if the appropriate place to bring up (legal) issues making some projects unable to use the new GameSDK is not here, where should we submit such feedback so that Discord (the company) knows that this is a problem? I want to add a Discord Rich Presence to VLC media player (which is GPL licensed) and the only solution (other than implement all the RPC communication myself) is to use this deprecated library. |
👍 I'd be interested to see that - VLC is the (multi-platform) Bee's Knees for many Multimedia tasks... |
|
@SlySven As per the comments in this issue it seems that the IPC RPC API itself won't go away soon, as it is what the GameSDK uses too. So I can probably just use that, unfortunately there are some restrictions what is possible using that, which is quite unfortunate. |
|
I come bearing news! It's been a little while in coming, and I apologize for the delay, but we can now officially cross the last bits of parity off the list. Our newest version of the GameSDK—2.5.5—is now IL2CPP-compatible for Unity and includes linux bindings. https://dl-game-sdk.discordapp.net/2.5.5/discord_game_sdk.zip With that news, I'm going to close this issue. It's been over six months, and the only "open" questions are legal ones, which have run their course on this issue. If you have any issues with the new SDK, please come on over to https://discord.gg/discord-gamesdk and let us know! Or come say how happy you are; we take compliments too 😄 The official documentation will be updated with these changes, and the download link updated to be 2.5.5, once this sits in the wild for a little longer and we're confident it all looks good. |
|
Small note for future folks—gonna keep this issue open, unpinned, and locked for folks coming through in the future who may miss the note on the repo's Readme. |
and others
Hey everyone!
As you may or may not know, Discord has been working closely with Game Devs for a while to give developers a way to sell their game on Discord. Recently, we announced our open invitation to publish on Discord to everyone!.
Equally as exciting is the work that we've done to further support the tech behind games with our Discord GameSDK. It includes not only Rich Presence, an awesome thing that you all love, but also a host of other useful features for apps and games like:
The "Come on in everyone!" game publishing announcement also marked our public release of this SDK, and we're quite proud of it. With that public release, it doesn't make a lot of sense for us to maintain two separate SDKs when one (discord-rpc) is just a subset of functionality of the other (GameSDK). So today we're deprecating this SDK in favor of the new one.
So what's it mean?
For most people, this change doesn't mean much. The big takeaway is that we won't be making any new feature additions to this SDK. Those requests should be directed to the new Game SDK, which will be our foundation on which to build.
Is my stuff gonna break?
Nah. The tech behind this SDK—connection to Discord via IPC/unix sockets and sending commands/listening for events—is how the new SDK works as well. So you should not expect your implementations to break. But, if you wanna be safe and future-proof and get cool new features, you can upgrade to the new SDK.
We've even made some of the Rich Presence functionality better, like allowing you to send invites programmatically or with our nice overlay UI.
What about feature requests?
We do not want to lose them! We've amassed a number of feature requests/enhancements in this repo over time, and we want to give those a place to be heard. We've opened up a new feedback site specific to devs and integration/SDK stuff. You can find it here. I'll be working in the next week to port all existing feature requests there and clear out the outstanding queue here.
In fact, some of the outstanding feature requests here are already addressed in the new SDK. To grab a couple:
TL;DR
It's good info, please read it <3 I'll pin this issue and leave it open for comments for a little while to make sure any outstanding questions are answered!
List of Links
The text was updated successfully, but these errors were encountered: