Re: KDE Licensing Policy Updates

2016-09-29 Thread Albert Astals Cid
El dijous, 29 de setembre de 2016, a les 9:32:00 CEST, Jonathan Riddell va 
escriure:
> On Wed, Sep 28, 2016 at 10:28:37PM +0200, Albert Astals Cid wrote:
> > Have you contacted the people that actually write docs if they are happy
> > with you imposing a change on the docs they write?
> > 
> > CC'ing them just in case they did not see it.
> 
> I'm not imposing :(
> 
> It's a suggested change we're discussing.

You're totally right, i was totally out of line.

Please accept my apologies.

Albert

> 
> Jonathan




Re: KDE Licensing Policy Updates

2016-09-29 Thread Jonathan Riddell
On Wed, Sep 28, 2016 at 10:28:37PM +0200, Albert Astals Cid wrote:
> Have you contacted the people that actually write docs if they are happy with 
> you imposing a change on the docs they write?
> 
> CC'ing them just in case they did not see it.

I'm not imposing :(

It's a suggested change we're discussing.

Jonathan


Re: KDE Licensing Policy Updates

2016-09-28 Thread Albert Astals Cid
El dimarts, 20 de setembre de 2016, a les 18:04:47 CEST, Jonathan Riddell va 
escriure:
> Changed:
> "Documentation must be licensed under the Creative Commons
> Attribution-Sharealike 4.0 International"
> Rationale: Currently we use GNU FDL but that licence is unmaintained,
> little used, problematic due to association with non-free options and
> incompatible with the GPL.  CC-BY-SA 4 is one way compatible with the
> GPL (code can be copied from docs to GPL code).  So I suggest moving
> new docs to CC.

Have you contacted the people that actually write docs if they are happy with 
you imposing a change on the docs they write?

CC'ing them just in case they did not see it.

Cheers,
  Albert


Re: KDE Licensing Policy Updates

2016-09-28 Thread Albert Astals Cid
El dimarts, 20 de setembre de 2016, a les 18:04:47 CEST, Jonathan Riddell va 
escriure:
> It's time for a new updates to the KDE Licensing Policy

kde-licens...@kde.org feels sad for not getting any news about this.

Cheers,
  Albert


Re: KDE Licensing Policy Updates

2016-09-27 Thread Jonathan Riddell
On Fri, Sep 23, 2016 at 06:52:13PM +0200, Luigi Toscano wrote:
> Still, as I mentioned, it would introduced problems if we move documentation 
> forth and back from wikis to other formats, and also with mixing content from 
> older documentation.

It would allow sharing content from wikis.  Currently this isn't possible.

The downside is content can't be shared with older KDE documentation, my 
feeling is this is less likely to happen.

Jonathan


Re: KDE Licensing Policy Updates

2016-09-23 Thread Riccardo Iaconelli
On 23 September 2016 at 18:52, Luigi Toscano  wrote:
> Still, as I mentioned, it would introduced problems if we move documentation
> forth and back from wikis to other formats, and also with mixing content from
> older documentation. I still don't buy the "cumbersome" argument, I don't
> think we use it the controversial parts like invariant section etc - do we?
> Trying to to relicense the existing documentation from FDL to FDL+CC as a
> start would be the best thing, but I think it would be complicated.

So yeah, FDL is impractical as it requires the full copy of the
license to be printed alongside with every printed copy of the
material covered by it.
...and doesn't really offer any more benefits I am aware of...

Bye,
-Riccardo
-- 
Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平
Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch שלום
Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화


Re: KDE Licensing Policy Updates

2016-09-23 Thread Luigi Toscano
On Friday, 23 September 2016 16:46:22 CEST Jonathan Riddell wrote:
> On Fri, Sep 23, 2016 at 06:41:57PM +0200, Riccardo Iaconelli wrote:
> > Hi all,
> > 
> > On 20 September 2016 at 19:04, Jonathan Riddell  wrote:
> > > Added:
> > > "Content on collaborative edited websites such as wikis must be
> > > licensed under the Creative Commons Attribution-Sharealike 4.0
> > > International."
> > > Rationale: we have no policy for wikis but they are very important to
> > > us especially with wikitoLearn so we should add one.  Our wikis are
> > > currently CC 3.0+FDL but we should consider moving to CC 4.0 (CC
> > > includes an or later so there's no difficultly in doing this).  FDL is
> > > unmaintained and not much used so we can drop this.
> > 
> > WikiToLearn is currently dual licensing CC-BY-SA 3.0 / GNU FDL and
> > we're considering just dropping FDL as it is quite cumbersome and we
> > don't really use it anyways.
> 
> Right, that's why I suggest dropping FDL usage across all wikis and new
> docs.

Still, as I mentioned, it would introduced problems if we move documentation 
forth and back from wikis to other formats, and also with mixing content from 
older documentation. I still don't buy the "cumbersome" argument, I don't 
think we use it the controversial parts like invariant section etc - do we?
Trying to to relicense the existing documentation from FDL to FDL+CC as a 
start would be the best thing, but I think it would be complicated.

-- 
Luigi


Re: KDE Licensing Policy Updates

2016-09-23 Thread Jonathan Riddell
On Fri, Sep 23, 2016 at 06:41:57PM +0200, Riccardo Iaconelli wrote:
> Hi all,
> 
> On 20 September 2016 at 19:04, Jonathan Riddell  wrote:
> > Added:
> > "Content on collaborative edited websites such as wikis must be
> > licensed under the Creative Commons Attribution-Sharealike 4.0
> > International."
> > Rationale: we have no policy for wikis but they are very important to
> > us especially with wikitoLearn so we should add one.  Our wikis are
> > currently CC 3.0+FDL but we should consider moving to CC 4.0 (CC
> > includes an or later so there's no difficultly in doing this).  FDL is
> > unmaintained and not much used so we can drop this.
> 
> WikiToLearn is currently dual licensing CC-BY-SA 3.0 / GNU FDL and
> we're considering just dropping FDL as it is quite cumbersome and we
> don't really use it anyways.

Right, that's why I suggest dropping FDL usage across all wikis and new docs.

> We would need to keep BY-SA, but I am unaware of any particular
> difference between 3.0 and 4.0. We can of course evaluate only
> backward compatible changes, and we need to be backward compatible
> with 3.0 for a long time due to the usage of Wikimedia Commons content
> (still mostly 3.0).

4.0 just clarifies some bits and makes it more international.  It has
the additional advantage that content can be relicenced as LGPL 3,
usful for code examples.  CC 3 has an "or later" clause so content
from wikimedia commons can be moved to a CC 4 licenced wiki/

Jonathan


Re: KDE Licensing Policy Updates

2016-09-21 Thread Jonathan Riddell
On Wed, Sep 21, 2016 at 04:24:13PM +0200, Sebastian Kügler wrote:
> On dinsdag 20 september 2016 22:54:54 CEST Thomas Pfeiffer wrote:
> > On the other hand: Is Qt still used much for web services? 
> 
> It may in the future. During QtCon, Lars Knoll mentioned to make Qt render to 
> web browser as one possible future goal. We also have vague plans for kwin to 
> do that.

open365.io already does this for Libreoffice running KDE's breeze
artwork.  We would turn the whole archive to AGPL to prevent that sort
of project proprietising KDE software but my feeling is that's not
something we want to do and that it's far too big a discussion which should
be had separate from this licence policy update.

Jonathan


Re: KDE Licensing Policy Updates

2016-09-21 Thread Sebastian Kügler
On dinsdag 20 september 2016 22:54:54 CEST Thomas Pfeiffer wrote:
> On the other hand: Is Qt still used much for web services? 

It may in the future. During QtCon, Lars Knoll mentioned to make Qt render to 
web browser as one possible future goal. We also have vague plans for kwin to 
do that.

> And if so: Are
> our frameworks of much use for those?

Yes.
-- 
sebas

http://www.kde.org | http://vizZzion.org


Re: KDE Licensing Policy Updates

2016-09-21 Thread Jonathan Riddell
On Tue, Sep 20, 2016 at 09:19:26PM +0200, Thomas Pfeiffer wrote:
> On 20.09.2016 19:52, Nicolás Alvarez wrote:
> >2016-09-20 14:04 GMT-03:00 Jonathan Riddell :
> >>Added:
> >>''Applications which are intended to be run on a server'' can be
> >>licenced under the GNU AGPL 3.0 or later
> >>Rationale: KDE Store code is under AGPL
> >>Question: should this be an option or a requirement for server software?
> >I agree with this change, but I think it should remain an option.
> 
> I would support making it mandatory, actually, or at least
> recommended, because for an end user a web service based on GPL
> software is no better than one based on proprietary software,
> because they cannot tell what software it is they're interacting
> with. Therefore, the AGPL closes an important hole in FOSS web
> services.
> 
> I don't feel very strongly about this, but to me it would make sense
> to at least recommend AGPL for web software we produce.

Added that this is recommended now to the Draft

Jonathan


Re: KDE Licensing Policy Updates

2016-09-21 Thread Jonathan Riddell
On Tue, Sep 20, 2016 at 07:11:10PM +0200, Luigi Toscano wrote:
> > Rationale: we have no policy for wikis but they are very important to
> > us especially with wikitoLearn so we should add one.  Our wikis are
> > currently CC 3.0+FDL but we should consider moving to CC 4.0 (CC
> > includes an or later so there's no difficultly in doing this).  FDL is
> > unmaintained and not much used so we can drop this.
> 
> I disagree with "little used". What does it mean "unmaintained"? Is the MIT 
> license maintained?
> I still would keep the dual license. Coming back later can be complicated if 
> impossible.

unmaintained means nobody cares about problems with it and there's no
updates expected.  The MIT is also unmaintained which means some
people can make claims which are untrue such as Pine authors claiming
you can't ship modified sources or people claiming additional
restrictions can be arbitrarily added and there's nobody in authority
to point out this is nonsense.

> > Changed:
> > "Documentation must be licensed under the Creative Commons
> > Attribution-Sharealike 4.0 International"
> > Rationale: Currently we use GNU FDL but that licence is unmaintained,
> > little used, problematic due to association with non-free options and
> > incompatible with the GPL.  CC-BY-SA 4 is one way compatible with the
> > GPL (code can be copied from docs to GPL code).  So I suggest moving
> > new docs to CC.
> 
> See above. That would make mixing content really complicated, especially when 
> we move from wiki to other formats or vice-versa. So same license in both 
> (dual at most).

It would make it possible to mix content from wikis to docs and to
code.  It's not currently possible to do this.

It would mean old docs couldn't be mixed with new docs as a downside.
Dual licencing with FDL would fix that but mean we couldn't copy from
anywhere else into wikis/docs which seems limiting.

Jonathan


Re: KDE Licensing Policy Updates

2016-09-21 Thread Jonathan Riddell
On Tue, Sep 20, 2016 at 06:42:55PM +, Sune Vuorela wrote:
> On 2016-09-20, Jonathan Riddell  wrote:
> > Differences:
> > Removed
> > "code may not be copied from Qt into KDE Platform as Qt is LGPL 2.1"
> > Rationale: Qt is now LGPL 3 as well as 2
> 
> Qt is not LGPL2.1 in general. As long as we want to be LGPL2.1 compat,
> we can't copy code from Qt.

OK, I've reinstated that sentence but swapped versions to say:
 Note: code may not be copied from Qt into KDE Platform as Qt is LGPL 3 only 
which would prevent it being used under LGPL 2.1

> > Added:
> > ''Applications which are intended to be run on a server'' can be
> > licenced under the GNU AGPL 3.0 or later
> > Rationale: KDE Store code is under AGPL
> > Question: should this be an option or a requirement for server software?
> 
> Not a requirement. Just like we don't have copyleft requirements
> anywhere.
> 
> And it should also be specific to things on a web server.

I've updated it say to 'web server'.

> > Added:
> > "Content on collaborative edited websites such as wikis must be
> > licensed under the Creative Commons Attribution-Sharealike 4.0
> > International."
> 
> Again, I don't think we should force copyleft.

I've added "or compatible licence".  All our current wikis are CC-BY-SA 3.0.

> > Changed:
> > "Documentation must be licensed under the Creative Commons
> > Attribution-Sharealike 4.0 International"
> 
> Also here. No need to force copyleft.

The previous requirement was the copyleft GNU FDL so there's no change
there.  I've added "or compatible licence". I've also added a note
"Note: CC-BY-SA 4.0 can be converted to LGPL 3."

> > Removed:
> > Standalone media files CC 4.. "This does not apply to icons or
> > anything which is likely to be mixed with content under our normal
> > (GPL etc) licences."
> > Rationale: CC 4 is compatible with GPL 3 which is the licence of
> > Breeze icons anyway.
> 
> I want my icons licensed under the same terms as my application. Even
> when my application is more liberal licensed than GPLv3.

It's just an option, same as before, I just changed CC 3 to CC4 which
allows for more compatibility with GPLv3 licenced works.  I've also
removed the requiment for the files to be "standalone" as with CC4
being compatible to GPL 3 they can be mixed with code if it's a GPL3
project.

https://community.kde.org/index.php?title=Policies%2FLicensing_Policy%2FDraft=revision=74119=74112

Jonathan


Re: KDE Licensing Policy Updates

2016-09-20 Thread Jaroslaw Staniek
On 20 September 2016 at 22:54, Thomas Pfeiffer 
wrote:

> Certainly not. AGPL is like GPL in that sense, with the extra rule
>> that you must publish the source code even if you're only giving
>> access over the network and not distributing binaries.
>>
>> I don't think an AGPL library makes much sense though.
>>
>>
>> ​ALGPL makes sense then :)
>> ​
>>
>
> On the other hand: Is Qt still used much for web services? And if so: Are
> our frameworks of much use for those?
>
>
There are Qt related projects that facilitate adding web service
compatibility to a traditional code (example I tried recently:
qhttpengine). QML is network transparent, and web services with QML has
been advertised by some contributors. There were commercial endeavors such
as Enginio. Many more examples I just forgot about.

I don't see these things advertised that as much (and infantile) as all the
"awesome" web things that so often live for one year and die, or
transforming themselves without looking back or caring for compatibility
and are encouraging copy-paste type of usages.

When asking about local vs web computing there seems to be apparent
polarization, you switch tools every time you move from one world to
another. That does not need to be a rule.



> I think this might be more of an edge case. I suppose that if we're doing
> web stuff, it's more likely to be full applications rather than libraries.
>

Well I'd like to see such usage increasing. Not to create unholy mix but to
truly continue the x0 years old concept of client-server computing, just
differently named artifacts.

I think certain already good apps and libs from FOSS would be even better
and more popular if they have support use cases that require web services
and if placing some of the logic on the server would be an officially
supported feature. Certainly also my modest usage would increase too (two
Qt projects at the moment) so the ALGPL term isn't a nonsense for me.

Programming for a local workstation is simpler, maybe that's why many C++
developers start there and and also stay in where the sweet spot is. For
example the last time when a contributor offered help in adding to support
for Oracle server in my KDE project... it was in 2004.

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek


Re: KDE Licensing Policy Updates

2016-09-20 Thread Thomas Pfeiffer

Certainly not. AGPL is like GPL in that sense, with the extra rule
that you must publish the source code even if you're only giving
access over the network and not distributing binaries.

I don't think an AGPL library makes much sense though.


​ALGPL makes sense then :)
​


On the other hand: Is Qt still used much for web services? And if so: Are our 
frameworks of much use for those?


I think this might be more of an edge case. I suppose that if we're doing web 
stuff, it's more likely to be full applications rather than libraries.


Re: KDE Licensing Policy Updates

2016-09-20 Thread Jaroslaw Staniek
On 20 September 2016 at 22:00, Nicolás Alvarez 
wrote:

> 2016-09-20 16:53 GMT-03:00 Jaroslaw Staniek :
> >
> >
> > On 20 September 2016 at 21:42, Nicolás Alvarez <
> nicolas.alva...@gmail.com>
> > wrote:
> >>
> >> 2016-09-20 16:30 GMT-03:00 Jaroslaw Staniek :
> >> >
> >> >
> >> > On 20 September 2016 at 21:19, Thomas Pfeiffer <
> thomas.pfeif...@kde.org>
> >> > wrote:
> >> >>
> >> >> On 20.09.2016 19:52, Nicolás Alvarez wrote:
> >> >>>
> >> >>> 2016-09-20 14:04 GMT-03:00 Jonathan Riddell :
> >> 
> >>  Added:
> >>  ''Applications which are intended to be run on a server'' can be
> >>  licenced under the GNU AGPL 3.0 or later
> >>  Rationale: KDE Store code is under AGPL
> >>  Question: should this be an option or a requirement for server
> >>  software?
> >> >>>
> >> >>> I agree with this change, but I think it should remain an option.
> >> >>
> >> >>
> >> >> I would support making it mandatory, actually, or at least
> recommended,
> >> >> because for an end user a web service based on GPL software is no
> >> >> better
> >> >> than one based on proprietary software, because they cannot tell what
> >> >> software it is they're interacting with. Therefore, the AGPL closes
> an
> >> >> important hole in FOSS web services.
> >> >>
> >> >> I don't feel very strongly about this, but to me it would make sense
> to
> >> >> at
> >> >> least recommend AGPL for web software we produce.
> >> >>
> >> >
> >> > I see that too but also aren't we also limited here in one case: when
> >> > our
> >> > LGPL software is usable for services? What can we do with e.g. KF5?
> Move
> >> > it
> >> > to AGPL and add linking exception?
> >> >
> >> > Sorry if that's already solved some way.
> >>
> >> AGPL code can use GPL and
> >> LGPL libraries.
> >
> >
> > Sure but that's not the challenge.
> > Rather: can an AGPL library be dynamically linked to a proprietary
> binary?
>
> Certainly not. AGPL is like GPL in that sense, with the extra rule
> that you must publish the source code even if you're only giving
> access over the network and not distributing binaries.
>
> I don't think an AGPL library makes much sense though.
>

​ALGPL makes sense then :)
​

>
> --
> Nicolás
>



-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek


Re: KDE Licensing Policy Updates

2016-09-20 Thread Nicolás Alvarez
2016-09-20 16:53 GMT-03:00 Jaroslaw Staniek :
>
>
> On 20 September 2016 at 21:42, Nicolás Alvarez 
> wrote:
>>
>> 2016-09-20 16:30 GMT-03:00 Jaroslaw Staniek :
>> >
>> >
>> > On 20 September 2016 at 21:19, Thomas Pfeiffer 
>> > wrote:
>> >>
>> >> On 20.09.2016 19:52, Nicolás Alvarez wrote:
>> >>>
>> >>> 2016-09-20 14:04 GMT-03:00 Jonathan Riddell :
>> 
>>  Added:
>>  ''Applications which are intended to be run on a server'' can be
>>  licenced under the GNU AGPL 3.0 or later
>>  Rationale: KDE Store code is under AGPL
>>  Question: should this be an option or a requirement for server
>>  software?
>> >>>
>> >>> I agree with this change, but I think it should remain an option.
>> >>
>> >>
>> >> I would support making it mandatory, actually, or at least recommended,
>> >> because for an end user a web service based on GPL software is no
>> >> better
>> >> than one based on proprietary software, because they cannot tell what
>> >> software it is they're interacting with. Therefore, the AGPL closes an
>> >> important hole in FOSS web services.
>> >>
>> >> I don't feel very strongly about this, but to me it would make sense to
>> >> at
>> >> least recommend AGPL for web software we produce.
>> >>
>> >
>> > I see that too but also aren't we also limited here in one case: when
>> > our
>> > LGPL software is usable for services? What can we do with e.g. KF5? Move
>> > it
>> > to AGPL and add linking exception?
>> >
>> > Sorry if that's already solved some way.
>>
>> AGPL code can use GPL and
>> LGPL libraries.
>
>
> Sure but that's not the challenge.
> Rather: can an AGPL library be dynamically linked to a proprietary binary?

Certainly not. AGPL is like GPL in that sense, with the extra rule
that you must publish the source code even if you're only giving
access over the network and not distributing binaries.

I don't think an AGPL library makes much sense though.

-- 
Nicolás


Re: KDE Licensing Policy Updates

2016-09-20 Thread Nicolás Alvarez
2016-09-20 16:30 GMT-03:00 Jaroslaw Staniek :
>
>
> On 20 September 2016 at 21:19, Thomas Pfeiffer 
> wrote:
>>
>> On 20.09.2016 19:52, Nicolás Alvarez wrote:
>>>
>>> 2016-09-20 14:04 GMT-03:00 Jonathan Riddell :

 Added:
 ''Applications which are intended to be run on a server'' can be
 licenced under the GNU AGPL 3.0 or later
 Rationale: KDE Store code is under AGPL
 Question: should this be an option or a requirement for server software?
>>>
>>> I agree with this change, but I think it should remain an option.
>>
>>
>> I would support making it mandatory, actually, or at least recommended,
>> because for an end user a web service based on GPL software is no better
>> than one based on proprietary software, because they cannot tell what
>> software it is they're interacting with. Therefore, the AGPL closes an
>> important hole in FOSS web services.
>>
>> I don't feel very strongly about this, but to me it would make sense to at
>> least recommend AGPL for web software we produce.
>>
>
> I see that too but also aren't we also limited here in one case: when our
> LGPL software is usable for services? What can we do with e.g. KF5? Move it
> to AGPL and add linking exception?
>
> Sorry if that's already solved some way.

AGPL code can use GPL and LGPL libraries.

-- 
Nicolás


Re: KDE Licensing Policy Updates

2016-09-20 Thread Jaroslaw Staniek
On 20 September 2016 at 21:19, Thomas Pfeiffer 
wrote:

> On 20.09.2016 19:52, Nicolás Alvarez wrote:
>
>> 2016-09-20 14:04 GMT-03:00 Jonathan Riddell :
>>
>>> Added:
>>> ''Applications which are intended to be run on a server'' can be
>>> licenced under the GNU AGPL 3.0 or later
>>> Rationale: KDE Store code is under AGPL
>>> Question: should this be an option or a requirement for server software?
>>>
>> I agree with this change, but I think it should remain an option.
>>
>
> I would support making it mandatory, actually, or at least recommended,
> because for an end user a web service based on GPL software is no better
> than one based on proprietary software, because they cannot tell what
> software it is they're interacting with. Therefore, the AGPL closes an
> important hole in FOSS web services.
>
> I don't feel very strongly about this, but to me it would make sense to at
> least recommend AGPL for web software we produce.
>
>
​I see that too​ but also aren't we also limited here in one case: when our
LGPL software is usable for services? What can we do with e.g. KF5? Move it
to AGPL and add linking exception?

Sorry if that's already solved some way.

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek


Re: KDE Licensing Policy Updates

2016-09-20 Thread Thomas Pfeiffer

On 20.09.2016 19:52, Nicolás Alvarez wrote:

2016-09-20 14:04 GMT-03:00 Jonathan Riddell :

Added:
''Applications which are intended to be run on a server'' can be
licenced under the GNU AGPL 3.0 or later
Rationale: KDE Store code is under AGPL
Question: should this be an option or a requirement for server software?

I agree with this change, but I think it should remain an option.


I would support making it mandatory, actually, or at least recommended, because 
for an end user a web service based on GPL software is no better than one based 
on proprietary software, because they cannot tell what software it is they're 
interacting with. Therefore, the AGPL closes an important hole in FOSS web services.


I don't feel very strongly about this, but to me it would make sense to at least 
recommend AGPL for web software we produce.




Re: KDE Licensing Policy Updates

2016-09-20 Thread Jaroslaw Staniek
On 20 September 2016 at 20:42, Sune Vuorela  wrote:

> On 2016-09-20, Jonathan Riddell  wrote:
> > Differences:
> > Removed
> > "code may not be copied from Qt into KDE Platform as Qt is LGPL 2.1"
> > Rationale: Qt is now LGPL 3 as well as 2
>
> Qt is not LGPL2.1 in general. As long as we want to be LGPL2.1 compat,
> we can't copy code from Qt.
>

Precision is needed here; ​I can easily copy some Qt project's code ​and
even relicense if I find it useful. I mean the BSD examples.

>
> > Added:
> > ''Applications which are intended to be run on a server'' can be
> > licenced under the GNU AGPL 3.0 or later
> > Rationale: KDE Store code is under AGPL
> > Question: should this be an option or a requirement for server software?
>
> Not a requirement. Just like we don't have copyleft requirements
> anywhere.
>
> And it should also be specific to things on a web server.
>
> For example:
> An imap AGPLv3 server might be a bad thing - there is a way to notify
> the user over teh imap protocol, but it is annoying for users, so it
> should really not be used. (It is the way quota messages and similar
> normally are sent)
>
> > Added:
> > "Content on collaborative edited websites such as wikis must be
> > licensed under the Creative Commons Attribution-Sharealike 4.0
> > International."
>
> Again, I don't think we should force copyleft.
>
> > Changed:
> > "Documentation must be licensed under the Creative Commons
> > Attribution-Sharealike 4.0 International"
>
> Also here. No need to force copyleft.
>
> > Removed:
> > Standalone media files CC 4.. "This does not apply to icons or
> > anything which is likely to be mixed with content under our normal
> > (GPL etc) licences."
> > Rationale: CC 4 is compatible with GPL 3 which is the licence of
> > Breeze icons anyway.
>
> I want my icons licensed under the same terms as my application. Even
> when my application is more liberal licensed than GPLv3.
>

​This. ​

​If I have icons that are part of my LGPL framework, I don't want ​my icons
to be viral making the framework GPL and thus severly self-limited. The
same goes for icons in LGPL apps (yes, LGPL is good for modular apps that
happen to be a source of frameworks).

I see a similar issue with widget styles such as Breeze; their viral GPL
affects apps, libs or plugins that choose to include them. For _nobody's_
benefit.

I see no need to be more paranoiac when dealing with ​friends than it's
needed.

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek


Re: KDE Licensing Policy Updates

2016-09-20 Thread Sune Vuorela
On 2016-09-20, Jonathan Riddell  wrote:
> Differences:
> Removed
> "code may not be copied from Qt into KDE Platform as Qt is LGPL 2.1"
> Rationale: Qt is now LGPL 3 as well as 2

Qt is not LGPL2.1 in general. As long as we want to be LGPL2.1 compat,
we can't copy code from Qt.

>
> Added:
> ''Applications which are intended to be run on a server'' can be
> licenced under the GNU AGPL 3.0 or later
> Rationale: KDE Store code is under AGPL
> Question: should this be an option or a requirement for server software?

Not a requirement. Just like we don't have copyleft requirements
anywhere.

And it should also be specific to things on a web server.

For example:
An imap AGPLv3 server might be a bad thing - there is a way to notify
the user over teh imap protocol, but it is annoying for users, so it
should really not be used. (It is the way quota messages and similar
normally are sent)

> Added:
> "Content on collaborative edited websites such as wikis must be
> licensed under the Creative Commons Attribution-Sharealike 4.0
> International."

Again, I don't think we should force copyleft.

> Changed:
> "Documentation must be licensed under the Creative Commons
> Attribution-Sharealike 4.0 International"

Also here. No need to force copyleft.

> Removed:
> Standalone media files CC 4.. "This does not apply to icons or
> anything which is likely to be mixed with content under our normal
> (GPL etc) licences."
> Rationale: CC 4 is compatible with GPL 3 which is the licence of
> Breeze icons anyway.

I want my icons licensed under the same terms as my application. Even
when my application is more liberal licensed than GPLv3.

/Sune