GSOC Project: Steam Integration

[Alvin Wong]

Hi,

@Emmet

> 1.) If I understand correctly, many aspects of Steam integration (like 
> achievements) require linking to and calling code in the Steamworks 
> API <https://partner.steamgames.com/doc/sdk/api>. Is doing so 
> compatible with Krita's GPLv3 license?
and @Ivan
> 1) From what I see, for linking a closed source library from GPLv3 
> would require to modify terms as seen 
> in"https://www.gnu.org/licenses/gpl-faq.html» however, I wonder if 
> this can be specific to libraries needed for providing API access. But 
> we would probably need insight from someone more familiar with this.

The Steamworks documentation 
<https://partner.steamgames.com/doc/sdk/uploading/distributing_opensource> 
calls out GPL to be potentially incompatible. It suggests two ways 
around it:

> The author can of course always (a) decide to grant Valve a different 
> license than the author grants everyone else or (b) decide that what 
> the Steamworks SDK does is just a communication with a service that 
> does not invoke the copyleft requirement of the GPL.
Option (a) is impossible given that we also use a lot of 3rd party code 
with GPLv3.

I am not sure if option (b) is really okay. GPLv3's copyleft does not 
extend to "system libraries", but it's defined as follows, and my 
non-lawyer brain can't really tell if that fits:

> The “System Libraries” of an executable work include anything, other 
> than the work as a whole, that (a) is included in the normal form of 
> packaging a Major Component, but which is not part of that Major 
> Component, and (b) serves only to enable use of the work with that 
> Major Component, or to implement a Standard Interface for which an 
> implementation is available to the public in source code form. A 
> “Major Component”, in this context, means a major essential component 
> (kernel, window system, and so on) of the specific operating system 
> (if any) on which the executable work runs, or a compiler used to 
> produce the work, or an object code interpreter used to run it.

I did find that someone has made a shim to use Steamworks as a separate 
process that may just bypass the whole issue: 
https://github.com/icculus/steamshim (Zlib license)

------------------------------------------------------------------------

> 2.) If that's not a problem, then would it require us to make 
> Steam-specific builds for each platform (Linux, Windows and MacOS)?
If you build it as a plugin that is only loaded if running from Steam 
and check that the Steamworks library is present, there should be no 
harm building it together with the normal build?

Cheers,

Alvin


On 16/2/2022 11:33, Iván Yossi wrote:
> hi all,
>
> I’ve been investigating a bit over this and from what I can understand 
> so far:
>
> 1) From what I see, for linking a closed source library from GPLv3 
> would require to modify terms as seen 
> in"https://www.gnu.org/licenses/gpl-faq.html» however, I wonder if 
> this can be specific to libraries needed for providing API access. But 
> we would probably need insight from someone more familiar with this.
>
> 2) I wonder if for this steam can launch install scripts?, if it can 
> we can add the redistributable_bin to the final krita directories in 
> the correct locations upon steam install. There would be no need for 
> extra builds if this can be done. Inside the code, the library would 
> have to be checked and linked at runtime.
>
> 3) Steam recommends no bigger transactions than 100Mb to avoid slow 
> close/open of the app, so if we limit to 250mb it probably will be a 
> limit on what we can do with the steam cloud.
>
> 4) Afaik, there is a way to work with teams on the app, if this is not 
> possible or is dangerous we could give the access to the mentor, and 
> work with the student through the mentor. For achivements the student 
> only needs the achievement key (we create them), and for development a 
> local textfile with an integer representing the app ID number is the 
> only thing needed (aside from, steam running, the krita application on 
> their library and my guess: the developer status for the app, but im 
> not familiar with the last part).
>
> There are challenges on this project and Im happy you bring them up, 
> specially non-related to coding as its sometimes forgotten when 
> thinking new projects.
>
> Iván Yossi
> <ghevan at gmail.com>
> IRC: ivanyossi
>
> El 15 de feb de 2022 16:45 -0600, Emmet O'Neill 
> <emmetoneill.pdx at gmail.com>, escribió:
>> Hey. I just wanted to comment on one of the GSOC projects listed here 
>> <https://community.kde.org/GSoC/2022/Ideas#Krita>.
>>
>> I haven't researched this too deeply, but I wonder if Steam 
>> integration as described here is possible for Krita. Eoin and I have 
>> a few questions:
>>
>> 1.) If I understand correctly, many aspects of Steam integration 
>> (like achievements) require linking to and calling code in the 
>> Steamworks API <https://partner.steamgames.com/doc/sdk/api>. Is doing 
>> so compatible with Krita's GPLv3 license?
>>
>> 2.) If that's not a problem, then would it require us to make 
>> Steam-specific builds for each platform (Linux, Windows and MacOS)?
>>
>> 3.) When it comes to cloud storage, there are a few practical 
>> limitations that should be considered. First is that Steam seems to 
>> limit cloud storage space to around 1GB per user, I think. While this 
>> isn't a ton of space to work with I can see how it might still be 
>> useful, but is it enough and are there any other limitations here 
>> that we should consider? The other issue is how we might create an 
>> interface through which users can decide what is or isn't saved to 
>> the Steam cloud. Would users be required to save their cloud-synced 
>> works in a special folder inside their Steam local content? (Using 
>> "Steam Auto-Cloud Configuration" we can enable cloud saving at a 
>> specific path without needing to use the Steamworks API at all, so 
>> the potential issue above doesn't necessarily apply here.)
>>
>> 4.) Steamworks integration and configuration would likely require 
>> administrator-level access to Krita's Steam project. Are we ok with 
>> granting that level of access to a GSOC student?
>>
>> I'm not against this project exactly, and I can certainly see how 
>> deeper Steam integration could be fun and a value-add for people who 
>> support us on Steam, but I want to make sure that some of the 
>> potential hurdles and pitfalls around this project are generally 
>> understood so that we don't end up sending one of our GSOC students 
>> on a wild goose chase or setting them up for failure.
>>
>> - Emmet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20220216/e0625221/attachment-0001.htm>