[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: Relicensing Krita as LGPLv2+
From:       Wolthera <griffinvalley () gmail ! com>
Date:       2017-01-08 14:01:57
Message-ID: CAN80MtGVfj13VESdDK1M3CmbcebAoNep-eLK2isHXnRnZnm5xg () mail ! gmail ! com
[Download RAW message or body]

Well, kickstarter might be a bit overkill, don't forget that kickstarter is
quite intense for us, and signing needs to happen every year.
Krita-Package-Signing patreon on the other hand :P
But this isn't quite an issue just yet.

On Sun, Jan 8, 2017 at 9:00 AM, Paragon <french.paragon@gmail.com> wrote:

> If we need to pay to get the krita package signed on Mac Os we may do
> specific kickstarters to get the money we need to do so, no ?
>
> This would make some mac users understand what it mean to get theirs
> packages from the app-store, or support Apple software distribution
> philosophy.
>
> (it would also be possible to put it in the annual kickstarter budget, but
> I think we miss the educational advantages of running a campaign just for
> that, and linux and windows users would maybe dislike paying for Apple
> philosophy).
>
>
> Le 08. 01. 17 à 01:58, Wolthera a écrit :
>
> These situations use an amazingly untested construction where there's a
> glue library that can link to GPL without having the main plugin be forced
> to follow GPL. The same can be said of MuseScore and VLC.
>
> Sven's concern is quite valid though. I think that we kind of need to
> wonder whether questions about the appstore shouldn't just be forwarded to
> the mailing list so that boud shouldn't have to answer them, especially
> because I haven't come across such questions myself, meaning that there's a
> significant chunk of people who do know how to use it on OSX. The problem
> being that people who don't are about computer literate enough to mail the
> foundation email but not use the 20 other places they could ask about this.
> For OSX, the only thing I am really worried about is signing of OSX
> packages, because if that becomes mandatory we might as well give up.
>
> On Sat, Jan 7, 2017 at 10:01 PM, Paragon <french.paragon@gmail.com> wrote:
>
>> Blender and Natron are under a GPL license but there are comercial
>> plugins for both of them. (And even commercial "forks" of blender, or at
>> least builds of blenders that are sold with a commercial closed software,
>> like vray). So I don't think relicensing under lgpl will change much on
>> this case. Tell me if i'm wrong ???
>>
>>
>> Le 07. 01. 17 à 21:37, Sven Langkamp a écrit :
>>
>> On Thu, Jan 5, 2017 at 10:13 AM, Boudewijn Rempt < <boud@valdyas.org>
>> boud@valdyas.org> wrote:
>>
>>> Hi,
>>>
>>> Umpteenth draft of this mail, but I think we should consider relicensing
>>> the GPL code in Krita to LGPL.
>>>
>>> One reason is that now that Krita is on its own, the mix of LGPL library
>>> code inherited from koffice/calligra and GPL library code inherited from
>>> Krita makes it hard to move code around; like we just did in the svg
>>> branch, creating the kritacommand library from code from krita/image
>>> and libs/kundo2. That code needs to be relicensed to LGPL before we
>>> merge the branch, of course.
>>>
>>
>> We could go to GPL for the complete repository and never have to
>> relicense anything again. It also doesn't happen that often that files need
>> to be moved across libaries and I have done some relicensing for this in
>> the past.
>>
>>
>>> Another reason is that there are too many macOS users who get confused
>>> when they install an application that's not in the app store, and we
>>> cannot publish GPL software in the app store. I wish I could just shrug
>>> that off, and I've done that until 3.1, but it's getting quite a
>>> support burden.
>>>
>>
>> This is somewhat of a grey area. At least the FSF thinks that even the
>> LGPL isn't compatible with the App Store.
>>
>> https://www.fsf.org/blogs/licensing/left-wondering-why-vlc-
>> relicensed-some-code-to-lgpl
>>
>> VLC did the same relicensing and is in the App Store, so it works for
>> now. But I wouldn't bet on that for the future.
>>
>> Beside that I don't like that Apple indirectly dictates our licensing.
>>
>> I haven't found a script yet that will figure out who owns copyright
>>> on the original GPL'ed krita code only -- running things like git fame
>>> only works on the whole repo, most of which is LGPL already...
>>>
>>
>> I'm remain sceptical about this for now.
>>
>> There is another issue that should be considered. Due to the heavy use of
>> plugins in Krita it would become very easy to extend Krita with
>> closed-source plugins. Pratically is would be possible to make a
>> close-source version on top of the existing code. This may sound
>> hypothetical, but we had this in the past were the license prevented a
>> commercial fork. Do we allow that? I think that's something that should at
>> least be considered.
>>
>>
>>
>
>
> --
> Wolthera
>
>
>


-- 
Wolthera

[Attachment #3 (text/html)]

<div dir="ltr"><div>Well, kickstarter might be a bit overkill, don&#39;t forget that \
kickstarter is quite intense for us, and signing needs to happen every year. \
Krita-Package-Signing patreon on the other hand :P<br></div>But this isn&#39;t quite \
an issue just yet.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On \
Sun, Jan 8, 2017 at 9:00 AM, Paragon <span dir="ltr">&lt;<a \
href="mailto:french.paragon@gmail.com" \
target="_blank">french.paragon@gmail.com</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    If we need to pay to get the krita package signed on Mac Os we may
    do specific kickstarters to get the money we need to do so, no ?<br>
    <br>
    This would make some mac users understand what it mean to get theirs
    packages from the app-store, or support Apple software distribution
    philosophy. <br>
    <br>
    (it would also be possible to put it in the annual kickstarter
    budget, but I think we miss the educational advantages of running a
    campaign just for that, and linux and windows users would maybe
    dislike paying for Apple philosophy).<br>
    <p><br>
    </p>
    <div class="m_8019756279750967108moz-cite-prefix">Le 08. 01. 17 Ã  01:58, \
Wolthera a  écrit  :<br>
    </div><div><div class="h5">
    <blockquote type="cite">
      <div dir="ltr">
        <div>These situations use an amazingly untested construction
          where there&#39;s a glue library that can link to GPL without
          having the main plugin be forced to follow GPL. The same can
          be said of MuseScore and VLC.<br>
          <br>
        </div>
        Sven&#39;s concern is quite valid though. I think that we kind of
        need to wonder whether questions about the appstore shouldn&#39;t
        just be forwarded to the mailing list so that boud shouldn&#39;t
        have to answer them, especially because I haven&#39;t come across
        such questions myself, meaning that there&#39;s a significant chunk
        of people who do know how to use it on OSX. The problem being
        that people who don&#39;t are about computer literate enough to mail
        the foundation email but not use the 20 other places they could
        ask about this. For OSX, the only thing I am really worried
        about is signing of OSX packages, because if that becomes
        mandatory we might as well give up.<br>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Sat, Jan 7, 2017 at 10:01 PM,
          Paragon <span dir="ltr">&lt;<a href="mailto:french.paragon@gmail.com" \
target="_blank">french.paragon@gmail.com</a>&gt;</span>  wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex">  <div bgcolor="#FFFFFF" text="#000000">
              <p>Blender and Natron are under a GPL license but there
                are comercial plugins for both of them. (And even
                commercial &quot;forks&quot; of blender, or at least builds of
                blenders that are sold with a commercial closed
                software, like vray). So I don&#39;t think relicensing under
                lgpl will change much on this case. Tell me if i&#39;m wrong
                ???</p>
              <p><br>
              </p>
              <div class="m_8019756279750967108m_2302276371515168143moz-cite-prefix">Le \
07.  01. 17 à 21:37, Sven Langkamp a écrit  :<br>
              </div>
              <div>
                <div class="m_8019756279750967108h5">
                  <blockquote type="cite">
                    <div dir="ltr">
                      <div class="gmail_extra">
                        <div class="gmail_quote">On Thu, Jan 5, 2017 at
                          10:13 AM, Boudewijn Rempt <span dir="ltr">&lt;<a \
class="m_8019756279750967108m_2302276371515168143moz-txt-link-abbreviated" \
href="mailto:boud@valdyas.org" target="_blank"></a><a \
class="m_8019756279750967108moz-txt-link-abbreviated" href="mailto:boud@valdyas.org" \
target="_blank">boud@valdyas.org</a>&gt;</span>  wrote:<br>
                          <blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>  <br>
                            Umpteenth draft of this mail, but I think we
                            should consider relicensing<br>
                            the GPL code in Krita to LGPL.<br>
                            <br>
                            One reason is that now that Krita is on its
                            own, the mix of LGPL library<br>
                            code inherited from koffice/calligra and GPL
                            library code inherited from<br>
                            Krita makes it hard to move code around;
                            like we just did in the svg<br>
                            branch, creating the kritacommand library
                            from code from krita/image<br>
                            and libs/kundo2. That code needs to be
                            relicensed to LGPL before we<br>
                            merge the branch, of course.<br>
                          </blockquote>
                          <div><br>
                          </div>
                          <div>We could go to GPL for the complete
                            repository and never have to relicense
                            anything again. It also doesn&#39;t happen that
                            often that files need to be moved across
                            libaries and I have done some relicensing
                            for this in the past.<br>
                          </div>
                          <div>  </div>
                          <blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Another  reason is \
that there are too many macOS  users who get confused<br>
                            when they install an application that&#39;s not
                            in the app store, and we<br>
                            cannot publish GPL software in the app
                            store. I wish I could just shrug<br>
                            that off, and I&#39;ve done that until 3.1, but
                            it&#39;s getting quite a<br>
                            support burden.<br>
                          </blockquote>
                          <div><br>
                          </div>
                          <div>This is somewhat of a grey area. At least
                            the FSF thinks that even the LGPL isn&#39;t
                            compatible with the App Store.</div>
                          <div><br>
                          </div>
                          <div><a \
href="https://www.fsf.org/blogs/licensing/left-wondering-why-vlc-relicensed-some-code-to-lgpl" \
target="_blank">https://www.fsf.org/blogs/lice<wbr>nsing/left-wondering-why-vlc-<wbr>relicensed-some-code-to-lgpl</a><br>
  </div>
                          <div><br>
                          </div>
                          <div>VLC did the same relicensing and is in
                            the App Store, so it works for now. But I
                            wouldn&#39;t bet on that for the future.</div>
                          <div><br>
                          </div>
                          <div>Beside that I don&#39;t like that Apple
                            indirectly dictates our licensing.</div>
                          <div><br>
                          </div>
                          <blockquote class="gmail_quote" style="margin:0px 0px 0px \
                0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I
                            haven&#39;t found a script yet that will figure
                            out who owns copyright<br>
                            on the original GPL&#39;ed krita code only --
                            running things like git fame<br>
                            only works on the whole repo, most of which
                            is LGPL already...<br>
                          </blockquote>
                          <div><br>
                          </div>
                          <div>I&#39;m remain sceptical about this for now.</div>
                          <div><br>
                          </div>
                          <div>There is another issue that should be
                            considered. Due to the heavy use of plugins
                            in Krita it would become very easy to extend
                            Krita with closed-source plugins. Pratically
                            is would be possible to make a close-source
                            version on top of the existing code. This
                            may sound hypothetical, but we had this in
                            the past were the license prevented a
                            commercial fork. Do we allow that? I think
                            that&#39;s something that should at least be
                            considered.</div>
                          <div><br>
                          </div>
                        </div>
                      </div>
                    </div>
                  </blockquote>
                  <br>
                </div>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <br>
        -- <br>
        <div class="m_8019756279750967108gmail_signature" \
data-smartmail="gmail_signature">Wolthera</div>  </div>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" \
data-smartmail="gmail_signature">Wolthera</div> </div>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic