<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi,<br>
    </p>
    <p>@Emmet<br>
      <blockquote type="cite">1.) If I understand correctly, many
        aspects of Steam integration (like achievements) require linking
        to and calling code in the <a
          href="https://partner.steamgames.com/doc/sdk/api">Steamworks
          API</a>. Is doing so compatible with Krita's GPLv3 license?</blockquote>
      and @Ivan<br>
      <blockquote type="cite">1) From what I see, for linking a closed
        source library from GPLv3 would require to modify terms as seen
        in"<a href="https://www.gnu.org/licenses/gpl-faq.html"
          target="_blank" class="moz-txt-link-freetext">https://www.gnu.org/licenses/gpl-faq.html</a>»
        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.</blockquote>
      <br>
      The <a moz-do-not-send="true"
href="https://partner.steamgames.com/doc/sdk/uploading/distributing_opensource">Steamworks
        documentation</a> calls out GPL to be potentially incompatible.
      It suggests two ways around it:</p>
    <p>
      <blockquote type="cite">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.</blockquote>
      Option (a) is impossible given that we also use a lot of 3rd party
      code with GPLv3.</p>
    <p>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:<br>
    </p>
    <p>
      <blockquote type="cite">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.</blockquote>
    </p>
    <p>I did find that someone has made a shim to use Steamworks as a
      separate process that may just bypass the whole issue: <a
        moz-do-not-send="true"
        href="https://github.com/icculus/steamshim"
        class="moz-txt-link-freetext">https://github.com/icculus/steamshim</a>
      (Zlib license)<br>
    </p>
    <hr width="100%" size="2">
    <p>
      <blockquote type="cite">2.) If that's not a problem, then would it
        require us to make Steam-specific builds for each platform
        (Linux, Windows and MacOS)?</blockquote>
      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?<br>
      <br>
    </p>
    <p>Cheers,</p>
    <p>Alvin</p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 16/2/2022 11:33, Iván Yossi wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:d4f26cc3-0798-4448-bdea-e17297c18cd9@Spark">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <title></title>
      <div name="messageBodySection">
        <div dir="auto">hi all,<br>
          <br>
          I’ve been investigating a bit over this and from what I can
          understand so far:<br>
          <br>
          1) From what I see, for linking a closed source library from
          GPLv3 would require to modify terms as seen in"<a
            href="https://www.gnu.org/licenses/gpl-faq.html"
            target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://www.gnu.org/licenses/gpl-faq.html</a>»
          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.<br>
          <br>
          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.<br>
          <br>
          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.<br>
          <br>
          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).<br>
          <br>
          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.</div>
      </div>
      <div name="messageSignatureSection"><br>
        <div class="matchFont">Iván Yossi
          <div><a class="moz-txt-link-rfc2396E" href="mailto:ghevan@gmail.com"><ghevan@gmail.com></a></div>
          <div>IRC: ivanyossi</div>
          <div><br>
          </div>
        </div>
      </div>
      <div name="messageReplySection">El 15 de feb de 2022 16:45 -0600,
        Emmet O'Neill <a class="moz-txt-link-rfc2396E" href="mailto:emmetoneill.pdx@gmail.com"><emmetoneill.pdx@gmail.com></a>, escribió:<br>
        <blockquote type="cite" style="border-left-color: grey;
          border-left-width: thin; border-left-style: solid; margin: 5px
          5px;padding-left: 10px;">
          <div dir="ltr">
            <div>Hey. I just wanted to comment on one of the GSOC
              projects listed <a
                href="https://community.kde.org/GSoC/2022/Ideas#Krita"
                moz-do-not-send="true">here</a>.</div>
            <div><br>
            </div>
            <div>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:</div>
            <div><br>
            </div>
            <div>1.) If I understand correctly, many aspects of Steam
              integration (like achievements) require linking to and
              calling code in the <a
                href="https://partner.steamgames.com/doc/sdk/api"
                moz-do-not-send="true">Steamworks API</a>. Is doing so
              compatible with Krita's GPLv3 license?<br>
            </div>
            <div><br>
            </div>
            <div>2.) If that's not a problem, then would it require us
              to make Steam-specific builds for each platform (Linux,
              Windows and MacOS)?</div>
            <div><br>
            </div>
            <div>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.)<br>
            </div>
            <div><br>
            </div>
            <div>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?</div>
            <div><br>
            </div>
            <div>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.</div>
            <div><br>
            </div>
            <div>- Emmet<br>
            </div>
          </div>
        </blockquote>
      </div>
    </blockquote>
  </body>
</html>