Re: KDE Licensing Policy Updates

[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

[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

[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

[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

[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

[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

[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

[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

[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

KDE Licensing Policy Updates

[Jonathan Riddell]

It's time for a new updates to the KDE Licensing Policy

The purpose of the policy is to ensure a common understanding of what
KDE code and contributions can be licenced as for copying.  It should
allow maximum reusability amongst KDE and other free software groups
while ensuring people are encouraged to contribute back or at least
not proprietise our code.

https://community.kde.org/Policies/Licensing_Policy/Draft
http://weegie.edinburghlinux.co.uk/~jr/tmp/policy-diff

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

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?

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.

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.

Changed:
'Standalone media files'' such as images may be licensed under the
Creative Commons Attribution-ShareAlike 4.0 International licence"
Rationale: Moved from CC 3 to CC 4 which has clearer language and is
compatible with more countries' legal systems.  CC 3 includes an "or
later" so can be moved to CC 4 without asking the copyright holder.

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.


Let me know what you think

Jonathan

Re: Creating a map of KDE contributors?

[Antonio Larrosa]

I also remembered it, but I didn't remember the location of the map. It's
even in the internet archive: https://web.archive.
org/web/20020402050748/http://worldwide.kde.org/map/

2016-09-20 14:11 GMT+02:00 Sebastian Kügler :

> On dinsdag 20 september 2016 11:49:43 CEST Jonathan Riddell wrote:
> > Gnome already do this
> > https://wiki.gnome.org/GnomeWorldWide
> >
> > and I have vauge memories of KDE doing it in the past too, or maybe I
> dreamt
> > that
>
> You didn't dream that: https://dot.kde.org/2002/03/16
> /kde-worldwide-goes-live
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org
>

Re: Creating a map of KDE contributors?

[Burkhard Lück]

Am Dienstag, 20. September 2016, 11:49:43 CEST schrieb Jonathan Riddell:
> Gnome already do this
> https://wiki.gnome.org/GnomeWorldWide
> 
> and I have vauge memories of KDE doing it in the past too, or maybe I dreamt
> that
> 
http://web.archive.org/web/20051221060246/http://worldwide.kde.org/pics/
fullmap.jpeg

-- 
Burkhard Lück

Re: Creating a map of KDE contributors?

[Sebastian Kügler]

On dinsdag 20 september 2016 11:49:43 CEST Jonathan Riddell wrote:
> Gnome already do this
> https://wiki.gnome.org/GnomeWorldWide
> 
> and I have vauge memories of KDE doing it in the past too, or maybe I dreamt
> that

You didn't dream that: https://dot.kde.org/2002/03/16/kde-worldwide-goes-live
-- 
sebas

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

Re: Creating a map of KDE contributors?

[Luigi Toscano]

On Tuesday, 20 September 2016 13:42:35 CEST Thomas Pfeiffer wrote:
> Hi everyone,
> I recently realized that unless you ask fellow KDE contributors personally
> where they live, you don't really know where over the world (or even in
> your home country) KDE is spread.
> 
> [...]
> 
> So, two questions:
> 1. Does that make sense to you?

We had a "heat-map" of committers in the old commit-digest:
https://commit-digest.kde.org/issues/2014-11-16/
So yes, it makes sense.

Also, for example:
https://www.debian.org/devel/developers.loc

> 2. If yes: Does anyone know of a piece of code that allows people to enter
> their city of residence and then show people on a map (ideally as an OSM
> overlay), or could otherwise maybe create it?

If it's not for the fact that sysadmin want to replace identity, a custom 
field there with the city and/or coordinates and some script to grab them, 
convert into geojson, and it's really easy (read: few lines of code) to setup 
a map with leaflet.

http://leafletjs.com/examples/geojson.html

Ciao
-- 
Luigi

Re: Creating a map of KDE contributors?

[Thomas Pfeiffer]

On 20.09.2016 13:49, Jonathan Riddell wrote:

Gnome already do this
https://wiki.gnome.org/GnomeWorldWide

Nice!
Though a zoomable map would be nicer, because on that map it's a bit difficult 
to distinguish cities in more crowded countries.

Re: Creating a map of KDE contributors?

[Jonathan Riddell]

Gnome already do this
https://wiki.gnome.org/GnomeWorldWide

and I have vauge memories of KDE doing it in the past too, or maybe I dreamt 
that

Jonathan

Creating a map of KDE contributors?

[Thomas Pfeiffer]

Hi everyone,
I recently realized that unless you ask fellow KDE contributors personally where 
they live, you don't really know where over the world (or even in your home 
country) KDE is spread.


I think this is a pity, given that knowing that would allow us to, among other 
things

- show the world how globally wide-spread KDE is
- make it easier to organize local events (like release parties or just local 
meetups)

- determine who could help with local FOSS events where KDE could participate
- pick locations for sprints or conferences depending on minimal overall travel 
effort


Therefore, I would like to create a map of KDE contributors' home towns (the 
towns/cities would be enough, no need to know the precise location). Ideally it 
would be possible for people to decide whether they want their name to show up 
publicly, or whether they just want to show up as an anonymous contributor.


So, two questions:
1. Does that make sense to you?
2. If yes: Does anyone know of a piece of code that allows people to enter their 
city of residence and then show people on a map (ideally as an OSM overlay), or 
could otherwise maybe create it?


Cheers,
Thomas

Mentoring, student programs coming up

[Valorie Zimmerman]

Hi folks, I have no announcements, but was thinking about our Season
of KDE and how we can enlarge and improve it. I believe we've been
thinking of it too much like GSoC, when it can be so much more.

For instance, I've seen a few announcements from maintainers wanting
to step back from a large piece of code for which they have been
responsibie. Sometimes seasoned developers step up, but what happens
when they don't? We don't have to settle for abandoned code, or
burning out maintainers. How about writing up a good description of
what is required, and offering to mentor a new maintainer for a few
months?

We all know that we have some large projects that need doing
(www.kde.org for instance) that have been too challenging to get done
so far. How about offering to mentor a specific part of such a task?
In SoK, we've never had a rule that the task had to be handled by one
person -- it could be a small team, so keep that in mind. Mentors can
act as a team, as well.

Think of all the work that Scarlett has done building the CI with the
help of Ben and the sysadmin team. Has that helped almost every KDE
developer? I think so!

These are just a few thoughts off the top of my head. Please think of
work you can mentor which will involve your mentee (SoK mentees do
*not* have to be students) more deeply in KDE and making the world
better.

If you are not subscribed to KDE-Soc-Mentor [1], please subscribe and
discuss your ideas.

Oh, and GCi [2] is happening this fall, so if you have a number of
small tasks, please start writing those up.

Valorie

1. https://mail.kde.org/mailman/listinfo/kde-soc-mentor

2. https://developers.google.com/open-source/gci/

-- 
http://about.me/valoriez