Re: [QGIS-Developer] Stale bot and older requests/issues - possible enhancement

[Charles Dixon-Paver]

How about something like:

Unfortunately this issue has not been addressed by the QGIS community for
some time. If you would like to expedite the resolution of this issue and
more like it, please refer to the https://qgis.org/en/site/getinvolved/facilitation.html";>facilitating
development guide for information on how to sponsor the development of
this functionality.

And make a facilitation page that explains the various resolution options
nicely.

Not sure if that's OK for non-native speakers

On Fri, 8 Jan 2021 at 02:51, Alexandre Neto  wrote:

>
> On Thu, Jan 7, 2021 at 11:44 PM Nyall Dawson 
> wrote:
>
>>
>>
>> What I'm trying to convey here is that there's a chance the ticket
>> will be addressed without sponsorship, but if they DO sponsor it will
>> get addressed immediately. So "fast track" here means something a
>> little like "short cut".  Is there better wording you think may convey
>> this same meaning?
>>
>> Nyall
>>
>>
>>
> Maybe "Speed up" or "accelerate"
>
> But maybe it's just my limited vocabulary.
>
> Alexandre
>
>
>> >
>> > Other than that +1
>> >
>> > Alexandre Neto
>> >
>> > A quinta, 7/01/2021, 08:33, Matthias Kuhn 
>> escreveu:
>> >>
>> >> Hi Nyall,
>> >>
>> >> I would also appreciate a hint like this.
>> >> Maybe it could be done even more subtle by shortening this text and
>> adding a link to a page "learn how to make things progress"?
>> >>
>> >> I'd also very much appreciate the voices of users on this topic
>> (that's a classical "we don't only want to hear the dev side" topic).
>> >>
>> >> Matthias
>> >>
>> >> On Thu, Jan 7, 2021 at 1:42 AM Nyall Dawson 
>> wrote:
>> >>>
>> >>> Hi list,
>> >>>
>> >>> I've a small request to consider for stale bot and issues/feature
>> >>> requests. I think that if a ticket remains open for say > 90 days
>> >>> since the last comment, it would be nice if stale bot added a comment
>> >>> like:
>> >>>
>> >>> "Unfortunately this bug/feature request has not seen any solution in
>> >>> the recent QGIS release. If this fix/feature is important to you or
>> >>> your organisation, you can help to fast-track its development by
>> >>> sponsoring this work. To do so, contact one of the QGIS commercial
>> >>> support providers listed at ... to discuss how you could fund this
>> >>> functionality".
>> >>>
>> >>> I think it's a non-threatening, non-begging way to advise bug
>> >>> reporters on the alternative ways they can fast track development in
>> >>> QGIS.
>> >>>
>> >>> Thoughts?
>> >>>
>> >>> Nyall
>> >>> ___
>> >>> QGIS-Developer mailing list
>> >>> QGIS-Developer@lists.osgeo.org
>> >>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >>
>> >> ___
>> >> QGIS-Developer mailing list
>> >> QGIS-Developer@lists.osgeo.org
>> >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Stale bot and older requests/issues - possible enhancement

[Alexandre Neto]

On Thu, Jan 7, 2021 at 11:44 PM Nyall Dawson  wrote:

>
>
> What I'm trying to convey here is that there's a chance the ticket
> will be addressed without sponsorship, but if they DO sponsor it will
> get addressed immediately. So "fast track" here means something a
> little like "short cut".  Is there better wording you think may convey
> this same meaning?
>
> Nyall
>
>
>
Maybe "Speed up" or "accelerate"

But maybe it's just my limited vocabulary.

Alexandre


> >
> > Other than that +1
> >
> > Alexandre Neto
> >
> > A quinta, 7/01/2021, 08:33, Matthias Kuhn 
> escreveu:
> >>
> >> Hi Nyall,
> >>
> >> I would also appreciate a hint like this.
> >> Maybe it could be done even more subtle by shortening this text and
> adding a link to a page "learn how to make things progress"?
> >>
> >> I'd also very much appreciate the voices of users on this topic (that's
> a classical "we don't only want to hear the dev side" topic).
> >>
> >> Matthias
> >>
> >> On Thu, Jan 7, 2021 at 1:42 AM Nyall Dawson 
> wrote:
> >>>
> >>> Hi list,
> >>>
> >>> I've a small request to consider for stale bot and issues/feature
> >>> requests. I think that if a ticket remains open for say > 90 days
> >>> since the last comment, it would be nice if stale bot added a comment
> >>> like:
> >>>
> >>> "Unfortunately this bug/feature request has not seen any solution in
> >>> the recent QGIS release. If this fix/feature is important to you or
> >>> your organisation, you can help to fast-track its development by
> >>> sponsoring this work. To do so, contact one of the QGIS commercial
> >>> support providers listed at ... to discuss how you could fund this
> >>> functionality".
> >>>
> >>> I think it's a non-threatening, non-begging way to advise bug
> >>> reporters on the alternative ways they can fast track development in
> >>> QGIS.
> >>>
> >>> Thoughts?
> >>>
> >>> Nyall
> >>> ___
> >>> QGIS-Developer mailing list
> >>> QGIS-Developer@lists.osgeo.org
> >>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >>
> >> ___
> >> QGIS-Developer mailing list
> >> QGIS-Developer@lists.osgeo.org
> >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Temporal controller issues

[Nyall Dawson]

On Thu, 7 Jan 2021 at 15:38, Nyall Dawson  wrote:
>
> > For example, one can add all sorts of SQL-like filters to a layer 
> > datasource (which was how the TimeManager plugin worked, if I understand 
> > correctly) and the selection tool, vertex tool, and so on are not broken by 
> > that. When somebody turns on the NTC, it is reasonable for them to expect 
> > that the filtering it does would act in a similar manner to those SQL-like 
> > filters added manually to a layer, yes?
>
> Time manager indeed piggy backed onto the layer sql filter
> functionality to implement time filtering. This had some advantages in
> that the temporal filtering became an innate property of the layer,
> but it was ultimately a dead end. There were issues with using the
> layer filter which couldn't be resolved, including:
> - poor UX -- users could not edit the layer filter while time manager
> was active, as the changes would either break time manager's temporal
> filter or would get immediately discarded as soon as time manager
> changed the temporal part of the filter.
> - constant fighting with time formats, and provider-specific support:
> because layer sql filters are handed directly off to the underlying
> backend, their syntax varies provider by provider. This means that the
> time manager approach becomes a tricky/fragile balancing act of
> provider-specific filter clauses. This also led to the requirement of
> strict time format constraints, which again varied provider by
> provider (and sometimes even locale by locale). While that's fine for
> a plugin, we wanted to ensure that time handling in qgis core was as
> seamless and pain-free as possible, and would work transparently
> across all data sources. Thus a different approach was required.

Bah, I realised I forget THE most important point here:
- Layer based filters are universal, and apply everywhere in QGIS.
Using them for temporal filtering would mean it's impossible to have
different views of the layer showing different time ranges (e.g one
map canvas filtered to a certain time range and another showing all
data, or different layout maps showing different slices of temporal
data, e.g. a print layout with a map for January, February, etc). The
final approach used ensures that we can flexibly control the time
range per map render, so we're free to have a different time range
visible in a 2d map vs a 3d map vs a print layout map.

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Plugin licensing requirements

[Nyall Dawson]

On Fri, 8 Jan 2021 at 03:18, Vincent Picavet (ml)
 wrote:
>
> Hi,
>
> On 07/01/2021 10:43, Nyall Dawson wrote:
> > On Thu, 7 Jan 2021 at 19:13, Topi Tjukanov  wrote:
> [..]
> >> So if this really is a requirement, should this be enforced somehow and
> >> checked when plugins are accepted to the official repository?
> >
> > Agreed, but keep in mind that it's a little tricky sometimes. A plugin ONLY
> > has to make the modules which import QGIS classes GPL (and consequently any
> > other modules which import these modules). It is entirely possible to
> > separate plugins into two isolated components, a non-GPL "core" layer which
> > does NOT use any QGIS modules, and a GPL layer which imports both the QGIS
> > modules and the non-gpl core. (This is how the licensed SLYR plugin works,
> > for reference).
>
> I would not bet any cent on these assertions. Would you have any serious
> references supporting this ?

No, you're correct -- there's basically only a lot of untested
theories out there, but as far as I can see no definitive answer to
this/legal outcome which has put these theories it to the test.

As you've pointed out the safest approach is complete separation
between the layers. But that approach is still entirely possible to do
for many QGIS plugins, so my original point about it being time
consuming to determine whether a certain file in a plugin's repo is
correctly licensed still stands. Maybe the whole enforcement thing
would just be an unnecessary time sink for the QGIS project itself,
and we're better off just leaving this to the "community" to police...

Nyall



>
> The GPL licence makes the code "viral" through the notion of "link". For 
> Python
> module, it is through import. A link is bidirectionnal, and therefore your 
> whole
> package if distributed is considered GPL.
>
> As far as I know, the only way to have a GPL/proprietary coexistence is to 
> have
> distinct processes and inter-process communication ( through files, web
> interfaces... ). And it can be even trickier if there are strong dependencies
> between modules, which can be interpreted as "derived product" or "link", even
> if there is no link as in "library link" between the modules.
>
> Best regards,
> Vincent
>
>
> >
> > So to enforce this in some circumstances you'd need to check file-by-file,
> > which is going to be time-consuming.
> >
> > Nyall
> >
> >
> >>
> >> Kind regards, Topi Tjukanov Gispo Oy
> >> ___ QGIS-Developer mailing
> >> list QGIS-Developer@lists.osgeo.org List info:
> >> https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe:
> >> https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > ___ QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org List info:
> > https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe:
> > https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
>
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Stale bot and older requests/issues - possible enhancement

[Nyall Dawson]

On Fri, 8 Jan 2021 at 09:25, Alexandre Neto  wrote:
>
> As an user and member of a user group, the message does not offend at all. 
> This is something we struggle to explain to users and it's a good opportunity 
> to send the message.
>
>  I prefer a long version instead of just a link (many won't click on it)
>
> I am not a native english speaker, but I think using something like "consider 
> sponsoring" instead of "you can sponsor".
>
> Also the term "fast track" for me is not very clear for me, again as 
> non-native english speaker.

What I'm trying to convey here is that there's a chance the ticket
will be addressed without sponsorship, but if they DO sponsor it will
get addressed immediately. So "fast track" here means something a
little like "short cut".  Is there better wording you think may convey
this same meaning?

Nyall


>
> Other than that +1
>
> Alexandre Neto
>
> A quinta, 7/01/2021, 08:33, Matthias Kuhn  escreveu:
>>
>> Hi Nyall,
>>
>> I would also appreciate a hint like this.
>> Maybe it could be done even more subtle by shortening this text and adding a 
>> link to a page "learn how to make things progress"?
>>
>> I'd also very much appreciate the voices of users on this topic (that's a 
>> classical "we don't only want to hear the dev side" topic).
>>
>> Matthias
>>
>> On Thu, Jan 7, 2021 at 1:42 AM Nyall Dawson  wrote:
>>>
>>> Hi list,
>>>
>>> I've a small request to consider for stale bot and issues/feature
>>> requests. I think that if a ticket remains open for say > 90 days
>>> since the last comment, it would be nice if stale bot added a comment
>>> like:
>>>
>>> "Unfortunately this bug/feature request has not seen any solution in
>>> the recent QGIS release. If this fix/feature is important to you or
>>> your organisation, you can help to fast-track its development by
>>> sponsoring this work. To do so, contact one of the QGIS commercial
>>> support providers listed at ... to discuss how you could fund this
>>> functionality".
>>>
>>> I think it's a non-threatening, non-begging way to advise bug
>>> reporters on the alternative ways they can fast track development in
>>> QGIS.
>>>
>>> Thoughts?
>>>
>>> Nyall
>>> ___
>>> QGIS-Developer mailing list
>>> QGIS-Developer@lists.osgeo.org
>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Stale bot and older requests/issues - possible enhancement

[Alexandre Neto]

As an user and member of a user group, the message does not offend at all.
This is something we struggle to explain to users and it's a good
opportunity to send the message.

 I prefer a long version instead of just a link (many won't click on it)

I am not a native english speaker, but I think using something like
"consider sponsoring" instead of "you can sponsor".

Also the term "fast track" for me is not very clear for me, again as
non-native english speaker.

Other than that +1

Alexandre Neto

A quinta, 7/01/2021, 08:33, Matthias Kuhn  escreveu:

> Hi Nyall,
>
> I would also appreciate a hint like this.
> Maybe it could be done even more subtle by shortening this text and adding
> a link to a page "learn how to make things progress"?
>
> I'd also very much appreciate the voices of users on this topic (that's a
> classical "we don't only want to hear the dev side" topic).
>
> Matthias
>
> On Thu, Jan 7, 2021 at 1:42 AM Nyall Dawson 
> wrote:
>
>> Hi list,
>>
>> I've a small request to consider for stale bot and issues/feature
>> requests. I think that if a ticket remains open for say > 90 days
>> since the last comment, it would be nice if stale bot added a comment
>> like:
>>
>> "Unfortunately this bug/feature request has not seen any solution in
>> the recent QGIS release. If this fix/feature is important to you or
>> your organisation, you can help to fast-track its development by
>> sponsoring this work. To do so, contact one of the QGIS commercial
>> support providers listed at ... to discuss how you could fund this
>> functionality".
>>
>> I think it's a non-threatening, non-begging way to advise bug
>> reporters on the alternative ways they can fast track development in
>> QGIS.
>>
>> Thoughts?
>>
>> Nyall
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Plugin licensing requirements

[Even Rouault]

On jeudi 7 janvier 2021 18:18:03 CET Vincent Picavet (ml) wrote:
> Hi,
> 
> On 07/01/2021 10:43, Nyall Dawson wrote:
> > On Thu, 7 Jan 2021 at 19:13, Topi Tjukanov  wrote:
> [..]
> 
> >> So if this really is a requirement, should this be enforced somehow and
> >> checked when plugins are accepted to the official repository?
> > 
> > Agreed, but keep in mind that it's a little tricky sometimes. A plugin
> > ONLY
> > has to make the modules which import QGIS classes GPL (and consequently
> > any
> > other modules which import these modules). It is entirely possible to
> > separate plugins into two isolated components, a non-GPL "core" layer
> > which
> > does NOT use any QGIS modules, and a GPL layer which imports both the QGIS
> > modules and the non-gpl core. (This is how the licensed SLYR plugin works,
> > for reference).
> 
> I would not bet any cent on these assertions. Would you have any serious
> references supporting this ?
> 
> The GPL licence makes the code "viral" through the notion of "link". For
> Python module, it is through import. A link is bidirectionnal, and
> therefore your whole package if distributed is considered GPL.
> 
> As far as I know, the only way to have a GPL/proprietary coexistence is to
> have distinct processes and inter-process communication ( through files,
> web interfaces... ). And it can be even trickier if there are strong
> dependencies between modules, which can be interpreted as "derived product"
> or "link", even if there is no link as in "library link" between the
> modules.

Those situations are tricky. Nyall's case looks to me a bit similar to the 
NVIDIA Linux kernel module:
- Linux kernel core : GPL
- shim layer for the NVIDIA driver: GPL
- NVIDIA blob that doesn't call GPL code: proprietary
NVIDIA claims that the blob isn't considered a derived work of the Linux 
kernel as it is OS-independent work.
Only a judge can ultimately decide what is a derived work or not.

Reference to a discussion regarding the NVIDIA case:
https://ipfs.io/ipfs/QmdA5WkDNALetBn4iFeSepHjdLGJdxPBwZyY47ir1bZGAK/comp/
linux/gpl_modules.html

https://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs might also be 
relevant.

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Loading WFS layers from GeoServer (Paul Wittle)

[Paul Wittle]

Hi,

I have now resolved the issue I was having and I'm posting in case it helps 
others.

In terms of ensuring the geometry type / projection is correct I have now moved 
to use the geometry_columns table 
(https://docs.geoserver.org/latest/en/user/data/database/oracle.html#using-the-geometry-metadata-table)
 but that didn't fix my issue.

The real issue was with the Namespace URI in the workspace definition. The URL 
I had used was actually a URL but it contained the ? character. This character 
was then being replicated into the XML definition in the WFS GML outputs.

I seems that MapInfo didn't mind this at all but QGIS was being picky for some 
reason. Given that it is a unique URI rather than a URL I just replaced the 
question mark with a forward splash and presto it is working now 😊

Perhaps it is worth an update to the docs 
(https://docs.geoserver.org/latest/en/user/data/webadmin/workspaces.html#edit-a-workspace)
 to recommend that special characters are avoided but then I'm probably the 
only person in the world that has ever done it so I'm happy to just say it 
works and move on if we don't think it needs documenting. I will of course 
cross post this to the GeoServer mailing list as well as it is not a QGIS issue.

Thanks to those that tried to help me work out the issue and I hope this post 
is helpful to others.
Paul
This e-mail and any files transmitted with it are intended solely for the use 
of the individual or entity to whom they are addressed. It may contain 
unclassified but sensitive or protectively marked material and should be 
handled accordingly. Unless you are the named addressee (or authorised to 
receive it for the addressee) you may not copy or use it, or disclose it to 
anyone else. If you have received this transmission in error please notify the 
sender immediately. All traffic may be subject to recording and/or monitoring 
in accordance with relevant legislation. Any views expressed in this message 
are those of the individual sender, except where the sender specifies and with 
authority, states them to be the views of Dorset Council. Dorset Council does 
not accept service of documents by fax or other electronic means. Virus 
checking: Whilst all reasonable steps have been taken to ensure that this 
electronic communication and its attachments whether encoded, encrypted or 
otherwise supplied are free from computer viruses, Dorset Council accepts no 
liability in respect of any loss, cost, damage or expense suffered as a result 
of accessing this message or any of its attachments. For information on how 
Dorset Council processes your information, please see 
www.dorsetcouncil.gov.uk/416433
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Plugin licensing requirements

[Vincent Picavet (ml)]

Hi,

On 07/01/2021 10:43, Nyall Dawson wrote:
> On Thu, 7 Jan 2021 at 19:13, Topi Tjukanov  wrote:
[..]
>> So if this really is a requirement, should this be enforced somehow and
>> checked when plugins are accepted to the official repository?
> 
> Agreed, but keep in mind that it's a little tricky sometimes. A plugin ONLY
> has to make the modules which import QGIS classes GPL (and consequently any
> other modules which import these modules). It is entirely possible to
> separate plugins into two isolated components, a non-GPL "core" layer which
> does NOT use any QGIS modules, and a GPL layer which imports both the QGIS
> modules and the non-gpl core. (This is how the licensed SLYR plugin works,
> for reference).

I would not bet any cent on these assertions. Would you have any serious
references supporting this ?

The GPL licence makes the code "viral" through the notion of "link". For Python
module, it is through import. A link is bidirectionnal, and therefore your whole
package if distributed is considered GPL.

As far as I know, the only way to have a GPL/proprietary coexistence is to have
distinct processes and inter-process communication ( through files, web
interfaces... ). And it can be even trickier if there are strong dependencies
between modules, which can be interpreted as "derived product" or "link", even
if there is no link as in "library link" between the modules.

Best regards,
Vincent


> 
> So to enforce this in some circumstances you'd need to check file-by-file,
> which is going to be time-consuming.
> 
> Nyall
> 
> 
>> 
>> Kind regards, Topi Tjukanov Gispo Oy 
>> ___ QGIS-Developer mailing
>> list QGIS-Developer@lists.osgeo.org List info:
>> https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe:
>> https://lists.osgeo.org/mailman/listinfo/qgis-developer
> ___ QGIS-Developer mailing list 
> QGIS-Developer@lists.osgeo.org List info:
> https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe:
> https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Stale bot and older requests/issues - possible enhancement

[Jürgen E . Fischer]

Hi Stefan,

On Thu, 07. Jan 2021 at 12:55:22 +, Stefan Steiger wrote:
> Also, if you use commercial software, 

you probably meant to say proprietary software - as you correctly said free
software is not required to be free of charge and hence can be commercial too.

> As with plugins:
> As long as they are NOT distributed with the software BY DEFAULT, they don’t
> necessarily have to abide by the GPL.

If they are derived from GPL software they also have to be GPL - and most QGIS
plugins have no use without QGIS.


> As long as you only use it internally (e.g. on a WebServer), you don’t have
> to abide by the terms of the GPL (the
> Affero/Application-Service-Provider
> loophole).

You always have to abide the license terms - just if you don't redistribute,
many restrictions don't apply.


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Nordenhttps://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Stale bot and older requests/issues - possible enhancement

[JD L]

My bad, it's a bad translation on my part. I though "gratuit" in French
translated to free (free of charges). I'm totally agree with you. That will
teach me to give my opinion in the language if Shakespeare.

Le jeu. 7 janv. 2021 à 13:55, Stefan Steiger  a
écrit :

> >> As a user and employee of a French administration, I think what is 
> >> proposed would be an excellent reminder. Open source is not free.
>
>
>
> Wrong on so many levels.
>
>
>
> First: GPL = Free Software
>
> So since the license of QGIS is GPL, it’s free software.
>
> “Free Software” means that along with the software, you get the source
> code for free, included in that is the freedom to change and redistribute
> it.
>
> Free as in Freedom. That does not mean it’s gratis.
>
>
>
> Second: “OpenSource” is not the same as 'Free Software'
>
> “OpenSource” merely means you have the source.
>
> It doesn’t mean you’re allowed to change or redistribute it.
>
> It also doesn’t mean it’s gratis.
>
> So “OpenSource” is much worse than GPL./ 'Free Software'.
>
>
>
> Third misconception:
>
> Free (as in freedom) doesn’t mean it’s gratis.
>
> It just means you have the freedom to alter and redistribute the software,
> provided you abide by the license’s requirements, which means granting the
> same right to others.
>
> It also doesn’t mean somebody else does your work for you, or pays
> somebody else to do your work for you.
>
> Therefore QGIS is indeed free, just not gratis.
>
>
>
> What you mean to say is that Free is not Gratis.
>
> That’s a truism/platitude.
>
>
>
> Also, if you use commercial software, you pay far more for the same, and
> you don’t have ANY guarantee that ANY bug is fixed, even if you can pay.
>
> You also cannot usually pay anyone else than the original company to do
> some work on it, even if somebody else could do the same work far cheaper.
>
> With commercial software, you also don’t have any guarantee that the
> product isn’t discontinued tomorrow, or taken into a completely different
> direction.
>
>
>
> As with plugins:
>
> As long as they are NOT distributed with the software BY DEFAULT, they
> don’t necessarily have to abide by the GPL.
>
> As long as you only use it internally (e.g. on a WebServer), you don’t
> have to abide by the terms of the GPL (the Affero
> /Application-Service-Provider
> loophole).
>
>
>
>
>
>
>
> *Von:* QGIS-Developer  *Im
> Auftrag von *JD L
> *Gesendet:* Donnerstag, 7. Januar 2021 10:10
> *An:* Matthias Kuhn 
> *Cc:* qgis-developer 
> *Betreff:* Re: [QGIS-Developer] Stale bot and older requests/issues -
> possible enhancement
>
>
>
> Hi
>
> As a user and employee of a French administration, I think what is proposed 
> would be an excellent reminder. Open source is not free.
>
>
>
> Le jeu. 7 janv. 2021 à 09:33, Matthias Kuhn  a
> écrit :
>
> Hi Nyall,
>
>
>
> I would also appreciate a hint like this.
>
> Maybe it could be done even more subtle by shortening this text and adding
> a link to a page "learn how to make things progress"?
>
>
>
> I'd also very much appreciate the voices of users on this topic (that's a
> classical "we don't only want to hear the dev side" topic).
>
>
>
> Matthias
>
>
>
> On Thu, Jan 7, 2021 at 1:42 AM Nyall Dawson 
> wrote:
>
> Hi list,
>
> I've a small request to consider for stale bot and issues/feature
> requests. I think that if a ticket remains open for say > 90 days
> since the last comment, it would be nice if stale bot added a comment
> like:
>
> "Unfortunately this bug/feature request has not seen any solution in
> the recent QGIS release. If this fix/feature is important to you or
> your organisation, you can help to fast-track its development by
> sponsoring this work. To do so, contact one of the QGIS commercial
> support providers listed at ... to discuss how you could fund this
> functionality".
>
> I think it's a non-threatening, non-begging way to advise bug
> reporters on the alternative ways they can fast track development in
> QGIS.
>
> Thoughts?
>
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Stale bot and older requests/issues - possible enhancement

[Giovanni Manghi]

> I've a small request to consider for stale bot and issues/feature
> requests. I think that if a ticket remains open for say > 90 days
> since the last comment, it would be nice if stale bot added a comment
> like:
>
> "Unfortunately this bug/feature request has not seen any solution in
> the recent QGIS release. If this fix/feature is important to you or
> your organisation, you can help to fast-track its development by
> sponsoring this work. To do so, contact one of the QGIS commercial
> support providers listed at ... to discuss how you could fund this
> functionality".
>
> I think it's a non-threatening, non-begging way to advise bug
> reporters on the alternative ways they can fast track development in
> QGIS.

yes please!

cheers

-- G --
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Stale bot and older requests/issues - possible enhancement

[Stefan Steiger]

>> As a user and employee of a French administration, I think what is proposed 
>> would be an excellent reminder. Open source is not free.


Wrong on so many levels.

First: GPL = Free Software
So since the license of QGIS is GPL, it’s free software.
“Free Software” means that along with the software, you get the source code for 
free, included in that is the freedom to change and redistribute it.
Free as in Freedom. That does not mean it’s gratis.

Second: “OpenSource” is not the same as 'Free Software'
“OpenSource” merely means you have the source.
It doesn’t mean you’re allowed to change or redistribute it.
It also doesn’t mean it’s gratis.
So “OpenSource” is much worse than GPL./ 'Free Software'.

Third misconception:
Free (as in freedom) doesn’t mean it’s gratis.
It just means you have the freedom to alter and redistribute the software, 
provided you abide by the license’s requirements, which means granting the same 
right to others.
It also doesn’t mean somebody else does your work for you, or pays somebody 
else to do your work for you.
Therefore QGIS is indeed free, just not gratis.

What you mean to say is that Free is not Gratis.
That’s a truism/platitude.

Also, if you use commercial software, you pay far more for the same, and you 
don’t have ANY guarantee that ANY bug is fixed, even if you can pay.
You also cannot usually pay anyone else than the original company to do some 
work on it, even if somebody else could do the same work far cheaper.
With commercial software, you also don’t have any guarantee that the product 
isn’t discontinued tomorrow, or taken into a completely different direction.

As with plugins:
As long as they are NOT distributed with the software BY DEFAULT, they don’t 
necessarily have to abide by the GPL.
As long as you only use it internally (e.g. on a WebServer), you don’t have to 
abide by the terms of the GPL (the 
Affero/Application-Service-Provider
 loophole).



Von: QGIS-Developer  Im Auftrag von JD L
Gesendet: Donnerstag, 7. Januar 2021 10:10
An: Matthias Kuhn 
Cc: qgis-developer 
Betreff: Re: [QGIS-Developer] Stale bot and older requests/issues - possible 
enhancement


Hi

As a user and employee of a French administration, I think what is proposed 
would be an excellent reminder. Open source is not free.

Le jeu. 7 janv. 2021 à 09:33, Matthias Kuhn 
mailto:matth...@opengis.ch>> a écrit :
Hi Nyall,

I would also appreciate a hint like this.
Maybe it could be done even more subtle by shortening this text and adding a 
link to a page "learn how to make things progress"?

I'd also very much appreciate the voices of users on this topic (that's a 
classical "we don't only want to hear the dev side" topic).

Matthias

On Thu, Jan 7, 2021 at 1:42 AM Nyall Dawson 
mailto:nyall.daw...@gmail.com>> wrote:
Hi list,

I've a small request to consider for stale bot and issues/feature
requests. I think that if a ticket remains open for say > 90 days
since the last comment, it would be nice if stale bot added a comment
like:

"Unfortunately this bug/feature request has not seen any solution in
the recent QGIS release. If this fix/feature is important to you or
your organisation, you can help to fast-track its development by
sponsoring this work. To do so, contact one of the QGIS commercial
support providers listed at ... to discuss how you could fund this
functionality".

I think it's a non-threatening, non-begging way to advise bug
reporters on the alternative ways they can fast track development in
QGIS.

Thoughts?

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Plugin licensing requirements

[Nyall Dawson]

On Thu, 7 Jan 2021 at 19:13, Topi Tjukanov  wrote:
>
> Howdy list,
>
> One question that keeps popping up with QGIS plugin development is one 
> regarding the licensing requirements. As per my understanding the plugins 
> have to be GPL compatible (GPL2 or higher) and that is what these resources 
> also suggest:
> https://blog.qgis.org/2016/05/29/licensing-requirements-for-qgis-plugins/
> https://gis.stackexchange.com/questions/61065/qgis-plugin-licence

>
> If that is the requirement, why plugins are accepted to the official 
> repository with various licenses and the requirement is not enforced in any 
> way?
> For example here are a few I found quickly with a random check:
>
> MIT license: https://plugins.qgis.org/plugins/XYZHubConnector/
> MIT license: https://github.com/gee-community/qgis-earthengine-plugin


> No license: https://github.com/riccardoklinger/amaps

This one is fine -- it just uses license headers, eg
https://github.com/riccardoklinger/amaps/blob/master/amaps.py#L15

> So if this really is a requirement, should this be enforced somehow and 
> checked when plugins are accepted to the official repository?

Agreed, but keep in mind that it's a little tricky sometimes. A plugin
ONLY has to make the modules which import QGIS classes GPL (and
consequently any other modules which import these modules). It is
entirely possible to separate plugins into two isolated components, a
non-GPL "core" layer which does NOT use any QGIS modules, and a GPL
layer which imports both the QGIS modules and the non-gpl core. (This
is how the licensed SLYR plugin works, for reference).

So to enforce this in some circumstances you'd need to check
file-by-file, which is going to be time-consuming.

Nyall


>
> Kind regards,
> Topi Tjukanov
> Gispo Oy
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin licensing requirements

[Topi Tjukanov]

Howdy list,

One question that keeps popping up with QGIS plugin development is one
regarding the licensing requirements. As per my understanding the plugins
have to be GPL compatible (GPL2 or higher) and that is what these
resources also suggest:
https://blog.qgis.org/2016/05/29/licensing-requirements-for-qgis-plugins/
https://gis.stackexchange.com/questions/61065/qgis-plugin-licence

If that is the requirement, why plugins are accepted to the official
repository with various licenses and the requirement is not enforced in any
way?
For example here are a few I found quickly with a random check:

   - MIT license: https://plugins.qgis.org/plugins/XYZHubConnector/
   - MIT license: https://github.com/gee-community/qgis-earthengine-plugin
   - No license: https://github.com/riccardoklinger/amaps

So if this really is a requirement, should this be enforced somehow and
checked when plugins are accepted to the official repository?

Kind regards,
Topi Tjukanov
Gispo Oy
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Stale bot and older requests/issues - possible enhancement

[JD L]

Hi

As a user and employee of a French administration, I think what is
proposed would be an excellent reminder. Open source is not free.


Le jeu. 7 janv. 2021 à 09:33, Matthias Kuhn  a écrit :

> Hi Nyall,
>
> I would also appreciate a hint like this.
> Maybe it could be done even more subtle by shortening this text and adding
> a link to a page "learn how to make things progress"?
>
> I'd also very much appreciate the voices of users on this topic (that's a
> classical "we don't only want to hear the dev side" topic).
>
> Matthias
>
> On Thu, Jan 7, 2021 at 1:42 AM Nyall Dawson 
> wrote:
>
>> Hi list,
>>
>> I've a small request to consider for stale bot and issues/feature
>> requests. I think that if a ticket remains open for say > 90 days
>> since the last comment, it would be nice if stale bot added a comment
>> like:
>>
>> "Unfortunately this bug/feature request has not seen any solution in
>> the recent QGIS release. If this fix/feature is important to you or
>> your organisation, you can help to fast-track its development by
>> sponsoring this work. To do so, contact one of the QGIS commercial
>> support providers listed at ... to discuss how you could fund this
>> functionality".
>>
>> I think it's a non-threatening, non-begging way to advise bug
>> reporters on the alternative ways they can fast track development in
>> QGIS.
>>
>> Thoughts?
>>
>> Nyall
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Stale bot and older requests/issues - possible enhancement

[Matthias Kuhn]

Hi Nyall,

I would also appreciate a hint like this.
Maybe it could be done even more subtle by shortening this text and adding
a link to a page "learn how to make things progress"?

I'd also very much appreciate the voices of users on this topic (that's a
classical "we don't only want to hear the dev side" topic).

Matthias

On Thu, Jan 7, 2021 at 1:42 AM Nyall Dawson  wrote:

> Hi list,
>
> I've a small request to consider for stale bot and issues/feature
> requests. I think that if a ticket remains open for say > 90 days
> since the last comment, it would be nice if stale bot added a comment
> like:
>
> "Unfortunately this bug/feature request has not seen any solution in
> the recent QGIS release. If this fix/feature is important to you or
> your organisation, you can help to fast-track its development by
> sponsoring this work. To do so, contact one of the QGIS commercial
> support providers listed at ... to discuss how you could fund this
> functionality".
>
> I think it's a non-threatening, non-begging way to advise bug
> reporters on the alternative ways they can fast track development in
> QGIS.
>
> Thoughts?
>
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer