From nyall.dawson at gmail.com Sun Feb 1 14:13:57 2026 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Mon, 2 Feb 2026 08:13:57 +1000 Subject: [QGIS-Developer] bugprone-branch-clone false positives Message-ID: Hi list, Is anyone else annoyed by the number of (very clearly wrong) false positives that the bugprone-branch-clone lint check is giving on CI? Is there ANY value in this particular check? Or should we just disable it? It seems completely broken to me[1]. Nyall [1] I searched upstream for bug reports and can't find anyone else having this issue. The closest I can find is possibly https://github.com/llvm/llvm-project/issues/67662 -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.cabieces at oslandia.com Mon Feb 2 01:02:56 2026 From: julien.cabieces at oslandia.com (Julien Cabieces) Date: Mon, 02 Feb 2026 10:02:56 +0100 Subject: [QGIS-Developer] bugprone-branch-clone false positives In-Reply-To: (Nyall Dawson via's message of "Mon, 2 Feb 2026 08:13:57 +1000") References: Message-ID: <87ecn3a56n.fsf@julienlaptop.home> Hi, > Is anyone else annoyed by the number of (very clearly wrong) false positives that the bugprone-branch-clone lint check is giving on CI? Yes, I was close to disable it recently. I searched a little bit to better understand what was going on and my conclusion is that there are several issues since clang 19 (missing includes are one, but it doesn't behave well with some Qt type, like if we replace a QVector with a std::vector, the issue suddenly disappear). So, I'm in favor of removing it. Regards, Julien > Hi list, > > Is anyone else annoyed by the number of (very clearly wrong) false positives that the bugprone-branch-clone lint check is giving on CI? > > Is there ANY value in this particular check? Or should we just disable it? It seems completely broken to me[1]. > > Nyall > > [1] I searched upstream for bug reports and can't find anyone else having this issue. The closest I can find is possibly > https://github.com/llvm/llvm-project/issues/67662 > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Julien Cabieces Senior Developer at Oslandia julien.cabieces at oslandia.com From julien.cabieces at oslandia.com Mon Feb 2 02:21:58 2026 From: julien.cabieces at oslandia.com (Julien Cabieces) Date: Mon, 02 Feb 2026 11:21:58 +0100 Subject: [QGIS-Developer] bugprone-branch-clone false positives In-Reply-To: <87ecn3a56n.fsf@julienlaptop.home> (Julien Cabieces via's message of "Mon, 02 Feb 2026 10:02:56 +0100") References: <87ecn3a56n.fsf@julienlaptop.home> Message-ID: <875x8fa1ix.fsf@julienlaptop.home> Just a precision, I think there are way more issues after clang 19, since clang 20. I'm using clang 19 on my machine and I don't get any of the false positives that I get in the CI. Anyway, it doesn't change the conclusion. > Hi, > >> Is anyone else annoyed by the number of (very clearly wrong) false positives that the bugprone-branch-clone lint check is giving on CI? > > Yes, I was close to disable it recently. > > I searched a little bit to better understand what was going on and my > conclusion is that there are several issues since clang 19 (missing > includes are one, but it doesn't behave well with some Qt type, like if > we replace a QVector with a std::vector, the issue suddenly disappear). > > So, I'm in favor of removing it. > > Regards, > Julien > >> Hi list, >> >> Is anyone else annoyed by the number of (very clearly wrong) false positives that the bugprone-branch-clone lint check is giving on CI? >> >> Is there ANY value in this particular check? Or should we just disable it? It seems completely broken to me[1]. >> >> Nyall >> >> [1] I searched upstream for bug reports and can't find anyone else having this issue. The closest I can find is possibly >> https://github.com/llvm/llvm-project/issues/67662 >> >> _______________________________________________ >> QGIS-Developer mailing list >> QGIS-Developer at lists.osgeo.org >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Julien Cabieces Senior Developer at Oslandia julien.cabieces at oslandia.com From apasotti at gmail.com Mon Feb 2 05:29:42 2026 From: apasotti at gmail.com (Alessandro Pasotti) Date: Mon, 2 Feb 2026 14:29:42 +0100 Subject: [QGIS-Developer] Gentle reminder: assign tickets to yourself when working on them Message-ID: Dear fellow developers, In order to avoid duplication of efforts and waste of your precious time, please remember to assign the tickets to yourself when working on them. Happy bugfixing! -- Alessandro Pasotti QCooperative: www.qcooperative.net ItOpen: www.itopen.it From wonder.sk at gmail.com Wed Feb 4 13:17:20 2026 From: wonder.sk at gmail.com (Martin Dobias) Date: Wed, 4 Feb 2026 22:17:20 +0100 Subject: [QGIS-Developer] QGIS 3D: Move away from Qt 3D? Message-ID: Hi all As you know, 3D map views in QGIS are based on the Qt 3D module. Since Qt 6.8 (released in Oct 2024) the Qt 3D module is marked as deprecated [1]. This does not mean that it will be removed anytime soon, but there's no development planned by the Qt company. There has been very little development in Qt 3D in recent years and little adoption within wider Qt community. A question naturally comes up - what should we do within the QGIS project? Stay with Qt 3D or start moving towards something else? At Lutra, we have started some internal discussions about this. Qt 3D does its job, but we find it often over-complicated (e.g. framegraph, entity-component-system scene representation) and under-documented. And with the lack of direct access to graphics APIs we have accumulated various workarounds and bugs that are difficult to fix. If we wanted to switch to something else, there are lots of options: from the very low-level wrappers around graphics APIs all the way to full blown 3D rendering engines for games. At this point, QRhi [2] looks like an interesting option. QRhi is a part of Qt GUI module and it is a relatively low-level abstraction on top of modern graphics APIs (Metal, Vulkan, Direct3D). It is already being used under the hood by Qt Quick and Qt Quick 3D (and optionally also by Qt 3D). It is kind of semi-private API of Qt GUI module, but it is well documented and the API has been quite stable despite the lack of source/binary compatibility guarantees. With a low-level approach like QRhi we would get a lot of control, at the expense of having to roll out our own abstractions that Qt 3D provides (e.g. camera, geometry, material, scene graph). I would love to hear some thoughts from other QGIS devs about the possible migration away from Qt 3D. If there will be consensus, we can then start working on a QEP and prepare a more detailed plan. Regards Martin [1] https://doc.qt.io/qt-6/whatsnew68.html [2] https://doc.qt.io/qt-6/qrhi.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet.duman at tubitak.gov.tr Wed Feb 4 13:15:29 2026 From: mehmet.duman at tubitak.gov.tr (Mehmet DUMAN (UZAY)) Date: Thu, 5 Feb 2026 00:15:29 +0300 (TRT) Subject: [QGIS-Developer] QGIS 3.40 build failure in crssync with PROJ 9.7.1 on OSGeo4W Message-ID: <1880612133.1704649.1770239729803.JavaMail.zimbra@tubitak.gov.tr> Hello QGIS developers, ? I am building QGIS 3.40 (ltr) from source on Windows using the OSGeo4W development environment and Visual Studio 2022, and I am encountering a build failure in the "synccrsdb" target. ? Environment ? - QGIS: 3.40 (source build) - OS: Windows x64 - Compiler: Visual Studio 2022 - Build system: CMake (MSVC generator) ? OSGeo4W packages installed ? Main development meta-package: ? qgis-ltr-deps ? Relevant dependency versions: ? proj-runtime: 9.7.1 proj-data: 1.24 ? Error ? The build fails while running "crssync.exe": ? Operation needs translation in QgsCoordinateReferenceSystemUtils::translateProjection: spilhaus aborted ? Visual Studio reports: ? synccrsdb.vcxproj custom build exited with code -1073740791 ? Question ? Is QGIS 3.40 expected to build correctly with PROJ 9.7.x, or is there a recommended PROJ version range for this release when using OSGeo4W? ? Should the qgis-ltr-deps package alone be sufficient to build the QGIS LTR source on Windows? If not, what is the recommended dependency set or workflow for building the LTR branch with OSGeo4W? ? ? ? Best regards, Mehmet Duman R&D Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Wed Feb 4 14:04:29 2026 From: gdt at lexort.com (Greg Troxel) Date: Wed, 04 Feb 2026 17:04:29 -0500 Subject: [QGIS-Developer] QGIS 3.40 build failure in crssync with PROJ 9.7.1 on OSGeo4W In-Reply-To: <1880612133.1704649.1770239729803.JavaMail.zimbra@tubitak.gov.tr> (Mehmet DUMAN via's message of "Thu, 5 Feb 2026 00:15:29 +0300 (TRT)") References: <1880612133.1704649.1770239729803.JavaMail.zimbra@tubitak.gov.tr> Message-ID: "Mehmet DUMAN (UZAY) via QGIS-Developer" writes: > The build fails while running "crssync.exe": > ? > Operation needs translation in QgsCoordinateReferenceSystemUtils::translateProjection: spilhaus I ran into this a year ago. The problem is that qgis needs a table of all projections. This message should be a big hint. Realize that it's a diff for a packaging system and thus there is the confusing presentation of adding a patch that changes qgis, with nested patch quoting! https://mail-index.netbsd.org/pkgsrc-changes/2025/05/02/msg322783.html But the real issue is that you are building 3.40, and not 3.44, which has the fix for spilhaus. As I understand it, 3.44 will be LTR soon, Are you sure you are using the 3.40 from git, or the latest point release? From andreaerdna at libero.it Thu Feb 5 00:42:33 2026 From: andreaerdna at libero.it (Andrea Giudiceandrea) Date: Thu, 5 Feb 2026 09:42:33 +0100 Subject: [QGIS-Developer] QGIS 3.40 build failure in crssync with PROJ 9.7.1 on OSGeo4W Message-ID: Il 04/02/2026 23:04, Greg Troxel via QGIS-Developer ha scritto: > But the real issue is that you are building 3.40, and not 3.44, which > has the fix for spilhaus. As I understand it, 3.44 will be LTR soon, Hi Greg and Mehmet, actually also 3.40 code has the "fix" for spilhaus projection from about 1 year. See: - https://github.com/qgis/QGIS/blame/release-3_40/src/core/proj/qgscoordinatereferencesystemutils.cpp#L428-L429 - https://github.com/qgis/QGIS/pull/60685 Perhaps Mehmet is using a very 3.40 code? Regards. Andrea From andreaerdna at libero.it Thu Feb 5 02:19:00 2026 From: andreaerdna at libero.it (Andrea Giudiceandrea) Date: Thu, 5 Feb 2026 11:19:00 +0100 Subject: [QGIS-Developer] QGIS 3.40 build failure in crssync with PROJ 9.7.1 on OSGeo4W Message-ID: <01ba5144-7c8b-411b-a086-76851a901049@libero.it> Il 05/02/2026 09:42, Andrea Giudiceandrea ha scritto: > Perhaps Mehmet is using a very 3.40 code? ...a very old 3.40 code... From jean.felder at oslandia.com Thu Feb 5 05:58:56 2026 From: jean.felder at oslandia.com (Jean Felder) Date: Thu, 5 Feb 2026 14:58:56 +0100 Subject: [QGIS-Developer] QEP 322: Point layer edition from the profile tool In-Reply-To: <4947d9ed-b730-45d4-b6dd-236e1ef62f8e@oslandia.com> References: <4947d9ed-b730-45d4-b6dd-236e1ef62f8e@oslandia.com> Message-ID: Hi everyone, Just a friendly reminder: voting is still open for the 'Point layer edition from the profile tool' QEP https://github.com/qgis/QGIS-Enhancement-Proposals/pull/328 Regards, Jean Le 13/01/2026 ? 10:12, Jean Felder via QGIS-Developer a ?crit?: > Hi, > > Thank you for all your feedback; it has been taken into account in the > QEP. > It is now opened to vote: > https://github.com/qgis/QGIS-Enhancement-Proposals/pull/328 > > > Regards, > Jean > > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Jean Felder D?veloppeur SIG Oslandia -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x12722DC64D3F429E.asc Type: application/pgp-keys Size: 2444 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From voting at qgis.org Thu Feb 5 18:33:00 2026 From: voting at qgis.org (Voting Officer) Date: Fri, 6 Feb 2026 10:33:00 +0800 Subject: [QGIS-Developer] Community Voting Members Election 2026: Ballot In-Reply-To: References: Message-ID: Hi all, just a friendly reminder that voting closes in 4 days on 10 February. Cheers John On Wed, Jan 28, 2026 at 9:51?AM Voting Officer wrote: > Dear QGIS Community, > > Thanks to the QGIS Committers for answering the Call for Nominations! The > call has now closed, with nominations for the following QGIS community > members: > > - > > Jean-Marie Arsac > - > > Lo?c Bartoletti > - > > Lova Andriarimalala > > We have one opening for the position of Community Voting Member. Eligible > voters are now invited to cast their ballot. > > Only QGIS Committers (?any person who has been granted commit access in > any of the official QGIS repositories?) are eligible to cast a ballot. This > includes committers to any QGIS Git repository or Transifex project. > > The voting will remain open until **23:59 UTC on 10 February 2026**. You > can cast your ballot here: > > https://forms.gle/1tAMLkatg7gfKS6V6 > > For further details, visit the QGIS community organisation page > . If you have any questions > about the process, please don?t hesitate to contact me. > > Thank you for your continued engagement! > John Bryant > QGIS Voting Officer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lova at kartoza.com Fri Feb 6 08:36:26 2026 From: lova at kartoza.com (Lova Andriarimalala) Date: Fri, 6 Feb 2026 19:36:26 +0300 Subject: [QGIS-Developer] QGIS Full Stack Developer Report from January 26th to February 6th, 2026 Message-ID: Hello everyone, Please find some highlights regarding the development and maintenance of the QGIS Websites for the last two weeks, from January 26th to February 6th, 2026. *QGIS.org:* - Fix duplicate Ubuntu/ Debian packages [Deployed] - Individual Contributors Map [Deployed] - Add new supporting contributors from Dec 2025 [Deployed] - Add a contributor badge for commercial support [Deployed] - Add contributor filter and search functionality with UI updates [New PR] *QGIS plugins:* - Upgrade Metabase to a recent version [Deployed] - Improve Qt6 support for RPC and metadata value [Deployed] - Fix auto approval logic for version create view [Deployed] - Add support for screenshots on plugins [New PR] - Improve documentation clarity in plugin publishing guidelines [New PR] - Disable pointer events for right ribbon overlay [New PR] - Improve API response handling for token based upload [New PR] - Fix code formatting in security scan result [New PR] *QGIS hub:* - Show animated GIFs in details and review page [New PR] - Show download button for reviewer in review details page [New PR] - Upgrade metabase docker image [Deployed] *QGIS planet:* - Add Hfc QGIS to subscribers [New PR] *QGIS feed:* - Upgrade metabase docker image [Deployed] - Enhance image preview functionality by adding cropping and scaling [Deployed] *QGIS Infrastructure Maintenance:* - QGIS Release Timeline Improvement Have a nice weekend, Lova Andriarimalala *QGIS Full Stack Developer * *T *: +27(0) 87 809 2702 *E *: lova at kartoza.com *W* : kartoza.com *This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you * *have received this email in error, please notify the sender immediately and delete it from your system. Unauthorised use, disclosure, or copying* *of the contents is prohibited.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.ml at oslandia.com Fri Feb 6 09:01:16 2026 From: vincent.ml at oslandia.com (Vincent Picavet) Date: Fri, 6 Feb 2026 18:01:16 +0100 Subject: [QGIS-Developer] "Human In The Loop" Policy For AI/Tool-Assisted Contributions In-Reply-To: References: Message-ID: <556b38ab-0d35-444c-bd3e-8ba6708cb4db@oslandia.com> Hi, I would double-down on Greg Troxel's advice concerning copyright issues, especially concerning the introduction of LLM-generated code into QGIS codebase. Opensource's success is based on these main characteristics : quality, security, trust. AI contributions pose a threat to quality, security and trust alike. A human-in-the-loop policy for contributions written with AI may help for quality and security issues, but will still leaves a huge problem for trust. Among the various aspects of trust, what worries me most right now is the copyright issue. OpenSource software is based on intellectual property laws, and especially on copyright, to be able to derive copyleft and grant more rights to end-users. End-user trust opensource software from a legal point of view because : - they are backed by well-established copyright laws - they have clear and well established end-users contracts ( opensource licences ) - they have a full record of modifications of the source code, hence a full lineage and certification of IP rights for the code - also, foundations like OSGeo additionnaly put a stamp on the software to guarantee that process and initial IP can be trusted enough to have a legal insurance concerning the software Introducing IA black boxes into the development process breaks the ability to control the lineage of the code and guarantee that it is a genuine invention, and therefore allowed to be licenced under the GPL. For quality and security, a developer can always intrinsically assess that the generated code has the required level of quality, and that it does not include any security flaw. But **there is no way for a developer to evaluate the IP rights on a code generated by a LLM**. How would one do it, since the code has been generated through a total opaque black box ingesting non-identified enormous volumes of data ? Today, we definitely know that LLMs ( ChatGPT, Claude and others ) have been trained on illegal copyrighted material. It is proven that they trained LLMs on pirated books. Furthermore, every time someone complaints about IP violation by LLM, big corps settle a financial arrangement with the copyright owners and move on. There is therefore no doubt that they have also trained LLMs on proprietary code. And also on opensource code not compliant with GPLv2+. Big corp. currently hide behind a "fair use" argument, but this is clearly rubbish, otherwise why would they bother to settle large financial deals with copyright owners ? So, LLM-generated code contributed to QGIS will at some point be plagiarized from random code available on the internet, and neither QGIS.org nor the contributor will be able to know. If we start accepting such code without being able to check provenance or copyright issues, it will end up buried deep inside QGIS, and the day we will discover that it infringes copyright, it will be a nightmare to solve : in this case we will want to revert all incriminated code, and also all code depending on the plagiarized code **and have it rewritten from scratch by someone who has never read the plagiarized code** ( ref : SCO/UNIX for example ). This is almost impossible. This would be a nightmare, just for one identified contribution. Even more, if/when the fair-use principle of LLMs falls down, then all LLM-generated code should be removed from QGIS, and all code depending on it. This is a really high risk with high impact. You may say : "ok but everyone does it, the chances of being caught are low, why not benefit from the opportunity ?" Then what about "everyone copies GPL code into proprietary code, the chances of being caught are low, why not benefit from the opportunity ?" Copyright is at the foundation of OpenSource software, and especially GPL-based software. If we choose to deny it, then we loose our core principle. In the text Even propose, there is a copyright section, pushing the responsibility of IP compliance control back to the contributor. It may protect QGIS.org or other developers from being sued whenever there is a problem, or they could sue back the faulty contributor, but this is not enough : - the faulty contributor has no way to ensure his generated code has no IP issue ( other than NOT using LLMs ) : responsibility without any mean of action is not fair and sustainable - even if the QGIS projet can avoid being convicted by transferring responsibility, then the situation would still be open and be a nightmare : removing plagiarized code entangled down the core of the software and all its dependency code, and rewrite it without IP issue is really hard Therefore, I do not think this mention is enough for IP protection. This rationale concerns the generated code itself, contributed to QGIS or other software in the ecosystem. LLMs may be useful and without IP risks to help find bugs, write parts of documentations where there is no risk of plagiarism, or other use cases. But I would definitely **forbid any generated code to be introduced into the main source code because of IP risk**. Also, the least we can do for any contribution, is not only to have a human in the loop, but also to have a mandatory mention and description of LLM usage for each contribution. This would at least give traceability. It does not solve anything, but in case of a problem, we could at least start to investigate. A am glad this conversation takes place, and willing to pursue the discussion, sorry for having been long. Have a nice weekend, Vincent On 31/01/2026 01:01, Greg Troxel via QGIS-Developer wrote: > I would suggest a much stronger policy: > > no LLM-generated code or discussion may be submitted to any QGIS forum > > > The idea that LLM-generated code has been "reviewed" intends to be that > it is of high enough quality that it is reasonable for *humans* to spend > time reviewing it. But I don't believe that asking that it be reviewed > will achieve that in practice. > > I've already had the experience (in a different project) of seeing a > posted PR(ish, patch on list), taking the time to comment, and getting > LLM-generated (vacuous) replies to my comments. > > Besides the ethical problems with asking humans to review, improve, > judge or in any other way pay attention to LLM output, there's the > problem of copyright. While machine-generated text isn't copyrightable > as is, LLM output is a derived work of stolen human work, scraped > and used without permission, often as DDOS. > > On the basis of each reason, I believe the policy about LLM should just > be "no". > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer From bertrand.parpoil at oslandia.com Fri Feb 6 09:19:17 2026 From: bertrand.parpoil at oslandia.com (Bertrand Parpoil) Date: Fri, 6 Feb 2026 18:19:17 +0100 Subject: [QGIS-Developer] RFI: Code review contracts by Oslandia Message-ID: <56516fc1-1f61-4cca-bb1a-d6de61770001@oslandia.com> Hello, Oslandia contributes to QGIS through several projects carried out on behalf of our clients and through improvements made in-house. We actively and regularly review contributions to QGIS, and our own contributions are reviewed by members of the community. Oslandia therefore already finances many contributions to the QGIS project and its community operations, in particular the review of code written by the entire community, by making its employees' time available. Beyond our own code reviews by Oslandia employees who contribute to QGIS, we would like to set up direct code review contracts for developers in the community. The aim of this is to: - respond to the high level of activity in terms of Pull Requests (by Oslandia employees and others) and therefore the need for review - encourage review efforts in general - promote the growth of the number of reviewers, and ultimately core committers Oslandia therefore offers paid contracts for developers, which are aimed at: - active members of the QGIS community who are likely to be involved in a number of Pull Requests - or C++ and Qt developers who are likely to be involved in C++, Qt, 3D, and other issues. Please note that this is not a community initiative led by QGIS.org but a specific initiative of the company Oslandia. Oslandia is the contractor and remains the decision-maker on the work to be prioritized under these contracts. The work carried out by the service providers must comply with all the written rules of operation of the QGIS project. In the case of an expert from outside the QGIS community, we are committed to making the necessary efforts to integrate them into the QGIS community. Contracts will be based on a negotiated hourly rate and a maximum number of hours ordered per contractor. We require a commitment to responsiveness in exchanges within the PRs and an initial agreement to review the various PRs with a schedule for intervention. The contractual conditions also include: - compliance with the QGIS code of conduct - a constructive approach to all interactions - actively benevolent behavior - justification of proposed changes - compliance with all explicit QGIS rules We are offering 10-hour contracts to start with, which can be extended or adapted according to individual needs and capabilities. The process is as follows: - Call for expressions of interest (this message today) - Receipt of applications: before February 14 - Selection of candidates by Oslandia: before February 21 - Contractualization Would you like to apply? Fill out the following form: https://oslandia.com/en/call-for-interest-qgis-qt-reviews-contracts/ Any question? Contact us and let's talk: qgis+review at oslandia.com Thank you for your proposals, and have a nice and shiny day ! -- Bertrand Parpoil Directeur Oslandia +33 188 320 680 Notre livre blanc d?di? ? la migration SIG opensource est disponible ! https://oslandia.com/livre-blanc-migration-sig-opensource/ *** https://www.linkedin.com/company/oslandia/ fingerprint=F06E 6518 C3B5 868D 6E57 BC13 E270 51C0 BE24 8B8F From lnicola at dend.ro Fri Feb 6 09:41:01 2026 From: lnicola at dend.ro (=?UTF-8?Q?Lauren=C8=9Biu_Nicola?=) Date: Fri, 06 Feb 2026 19:41:01 +0200 Subject: [QGIS-Developer] "Human In The Loop" Policy For AI/Tool-Assisted Contributions In-Reply-To: <556b38ab-0d35-444c-bd3e-8ba6708cb4db@oslandia.com> References: <556b38ab-0d35-444c-bd3e-8ba6708cb4db@oslandia.com> Message-ID: <3387b4a1-2c9a-4922-bc7b-f304f27218ca@betaapp.fastmail.com> Hi, At least in the US (and in my personal opinion, too), training an LLM is now thought to be transformative, thus fair use [1]. It's also not obvious that an LLM will reproduce ad-literam material from its training set [2]. > Transformativeness is a characteristic of such derivative works that makes them transcend, or place in a new light, the underlying works on which they are based. [3] More so, it's becoming pretty clear that LLMs are more than -- to use a well-loved phrase -- "stochastic parrots". As a recent example, one built a C compiler [3] in Rust. I believe there used to be ~3 compilers that could build Linux, none of them written in Rust, and none of them translatable to Rust due to the particularities of the language. So while it might have had GCC in its training set, it couldn't have reproduced it. And it's not like humans are perfect at avoiding copyrighted code. Try to write a binary search, or quick sort, or a Web Mercator conversion function that's not identical in spirit (at least) to a published version. Or look at how people used to copy-paste snippets from Stack Overflow before LLMs got popular. The AI cat is out of the bag, and no policy trying to ban LLMs will put it back in. That's not to say that LLM-written contributions are always of high quality, quite the opposite. But LLMs have been getting better (writing even a toy compiler would have been a pipe dream just one year ago), so their quality is going to improve in the long run. And, as I mentioned before, putting LLM-based completions [5] in the same basket as the AI writing a whole new feature from scratch feels absurd. Laurentiu [1]: https://www.nortonrosefulbright.com/en/knowledge/publications/afb0e10b/two-us-decisions-find-that-reproducing-works-to-train-large-language-models-is-fair-use [2]: as opposed to feeding it nearby text from the original and asking for a completion like in https://arxiv.org/pdf/2505.12546 [3]: https://en.wikipedia.org/wiki/Transformative_use [4]: https://www.anthropic.com/engineering/building-c-compiler [5]: not a great example, but https://youtu.be/hSFeDdZWHt0?t=179 From pigrecoinfinito at gmail.com Fri Feb 6 10:06:45 2026 From: pigrecoinfinito at gmail.com (=?UTF-8?Q?Tot=C3=B2_Fiandaca?=) Date: Fri, 6 Feb 2026 19:06:45 +0100 Subject: [QGIS-Developer] QGIS Full Stack Developer Report from January 26th to February 6th, 2026 In-Reply-To: References: Message-ID: Grazie mille! Il giorno ven 6 feb 2026 alle ore 17:37 Lova Andriarimalala via QGIS-Developer ha scritto: > Hello everyone, > > Please find some highlights regarding the development and maintenance of > the QGIS Websites for the last two weeks, from January 26th to February > 6th, 2026. > > *QGIS.org:* > > - Fix duplicate Ubuntu/ Debian packages > [Deployed] > - Individual Contributors Map > [Deployed] > - Add new supporting contributors from Dec 2025 > [Deployed] > - Add a contributor badge for commercial support > [Deployed] > - Add contributor filter and search functionality with UI updates > [New PR] > > *QGIS plugins:* > > - Upgrade Metabase to a recent version > [Deployed] > - Improve Qt6 support for RPC and metadata value > [Deployed] > - Fix auto approval logic for version create view > [Deployed] > - Add support for screenshots on plugins > [New PR] > - Improve documentation clarity in plugin publishing guidelines > [New PR] > - Disable pointer events for right ribbon overlay > [New PR] > - Improve API response handling for token based upload > [New PR] > - Fix code formatting in security scan result > [New PR] > > *QGIS hub:* > > - Show animated GIFs in details and review page > [New PR] > - Show download button for reviewer in review details page > [New PR] > - Upgrade metabase docker image > [Deployed] > > *QGIS planet:* > > - Add Hfc QGIS to subscribers > [New PR] > > *QGIS feed:* > > - Upgrade metabase docker image > [Deployed] > - Enhance image preview functionality by adding cropping and scaling > [Deployed] > > *QGIS Infrastructure Maintenance:* > > - QGIS Release Timeline Improvement > > > Have a nice weekend, > > Lova Andriarimalala > > > *QGIS Full Stack Developer * > *T *: +27(0) 87 809 2702 *E *: lova at kartoza.com *W* : > kartoza.com > > > > *This email and any attachments are confidential and intended solely for > the use of the individual or entity to whom they are addressed. If you * > *have received this email in error, please notify the sender immediately > and delete it from your system. Unauthorised use, disclosure, or copying* > *of the contents is prohibited.* > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > > -- > *Salvatore Fiandaca* > > Questo documento, allegati inclusi, contiene informazioni di propriet? di > FIANDACA SALVATORE e deve essere utilizzato esclusivamente dal destinatario > in relazione alle finalit? per le quali ? stato ricevuto. E' vietata > qualsiasi forma di riproduzione o divulgazione senza l'esplicito consenso > di FIANDACA SALVATORE. Qualora fosse stato ricevuto per errore si prega > di informare tempestivamente il mittente e distruggere la copia in proprio > possesso. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Fri Feb 6 15:30:59 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sat, 7 Feb 2026 00:30:59 +0100 Subject: [QGIS-Developer] [Poll created] Re: "Human In The Loop" Policy For AI/Tool-Assisted Contributions In-Reply-To: <556b38ab-0d35-444c-bd3e-8ba6708cb4db@oslandia.com> References: <556b38ab-0d35-444c-bd3e-8ba6708cb4db@oslandia.com> Message-ID: <2a83f100-2eca-4008-ae62-83f90bc8607c@spatialys.com> Vincent, Thanks for your feedback. Yes copyright / IP issues are a tricky problem to deal with and you make good points on how things could go wrong. That said, in practice I believe most generated code would be mostly derived from QGIS itself, QT code or doc or be non-copyrightable material. I can imagine though that contributions including non-trivial algorithms could possibly be infringing copyright. In that situation, the reviewers could ask the submitter to bring more light on the provenance of such code (the contributor may ask the LLM to dig for references for the provenance and check they are OK with GPL2 inclusion, being aware that the LLM could hallucinate them...), and if no satisfactory answer is given, reject the contribution. But that can be admitedly hard to spot for reviewers. I'd be happy to amend the QEP with that if someone can propose an adequate formulation. I've doubts a "no AI" policy is achievable in practice, or people will lie.? As you mention, we can require people to mention the tool they have used, possibly the prompt(s) they use, which manual modifications they applied on top of that.? Doesn't the paragraph starting at line 35 (https://github.com/qgis/QGIS-Enhancement-Proposals/pull/363/changes#diff-4f4102e51f04fdfc82e843c6942abe9965c03ac85a92e9becf21bcca8b5571adR35) cover enough your point about "have a mandatory mention and description of LLM usage for each contribution" ? The main driver for this QEP was to give us a tool to be able to quickly reject sloppy contributions with a solid reference to back our decisions, but we must indeed decide whether we go further than this. For that purpose, I've created a quick poll at https://docs.google.com/forms/d/e/1FAIpQLSdnVWoD5DrwCbNXqPqHsLw2jfbLkPMKBkvfyQfTQOPZkj_EaQ/viewform so we can gather opinions on the general direction we want on that subject. All, please fill! Even Le 06/02/2026 ? 18:01, Vincent Picavet via QGIS-Developer a ?crit?: > Hi, > > I would double-down on Greg Troxel's advice concerning copyright > issues, especially concerning the introduction of LLM-generated code > into QGIS codebase. > > Opensource's success is based on these main characteristics : quality, > security, trust. > > AI contributions pose a threat to quality, security and trust alike. > > A human-in-the-loop policy for contributions written with AI may help > for quality and security issues, but will still leaves a huge problem > for trust. > > Among the various aspects of trust, what worries me most right now is > the copyright issue. OpenSource software is based on intellectual > property laws, and especially on copyright, to be able to derive > copyleft and grant more rights to end-users. > > End-user trust opensource software from a legal point of view because : > > - they are backed by well-established copyright laws > > - they have clear and well established end-users contracts ( > opensource licences ) > > - they have a full record of modifications of the source code, hence a > full lineage and certification of IP rights for the code > > - also, foundations like OSGeo additionnaly put a stamp on the > software to guarantee that process and initial IP can be trusted > enough to have a legal insurance concerning the software > > Introducing IA black boxes into the development process breaks the > ability to control the lineage of the code and guarantee that it is a > genuine invention, and therefore allowed to be licenced under the GPL. > > For quality and security, a developer can always intrinsically assess > that the generated code has the required level of quality, and that it > does not include any security flaw. > > But **there is no way for a developer to evaluate the IP rights on a > code generated by a LLM**. How would one do it, since the code has > been generated through a total opaque black box ingesting > non-identified enormous volumes of data ? > > Today, we definitely know that LLMs ( ChatGPT, Claude and others ) > have been trained on illegal copyrighted material. It is proven that > they trained LLMs on pirated books. Furthermore, every time someone > complaints about IP violation by LLM, big corps settle a financial > arrangement with the copyright owners and move on. > > There is therefore no doubt that they have also trained LLMs on > proprietary code. And also on opensource code not compliant with GPLv2+. > > Big corp. currently hide behind a "fair use" argument, but this is > clearly rubbish, otherwise why would they bother to settle large > financial deals with copyright owners ? > > So, LLM-generated code contributed to QGIS will at some point be > plagiarized from random code available on the internet, and neither > QGIS.org nor the contributor will be able to know. > > If we start accepting such code without being able to check provenance > or copyright issues, it will end up buried deep inside QGIS, and the > day we will discover that it infringes copyright, it will be a > nightmare to solve : in this case we will want to revert all > incriminated code, and also all code depending on the plagiarized code > **and have it rewritten from scratch by someone who has never read the > plagiarized code** ( ref : SCO/UNIX for example ). This is almost > impossible. > > This would be a nightmare, just for one identified contribution. > > Even more, if/when the fair-use principle of LLMs falls down, then all > LLM-generated code should be removed from QGIS, and all code depending > on it. This is a really high risk with high impact. > > You may say : "ok but everyone does it, the chances of being caught > are low, why not benefit from the opportunity ?" > > Then what about "everyone copies GPL code into proprietary code, the > chances of being caught are low, why not benefit from the opportunity ?" > > Copyright is at the foundation of OpenSource software, and especially > GPL-based software. If we choose to deny it, then we loose our core > principle. > > In the text Even propose, there is a copyright section, pushing the > responsibility of IP compliance control back to the contributor. It > may protect QGIS.org or other developers from being sued whenever > there is a problem, or they could sue back the faulty contributor, but > this is not enough : > > - the faulty contributor has no way to ensure his generated code has > no IP issue ( other than NOT using LLMs ) : responsibility without any > mean of action is not fair and sustainable > > - even if the QGIS projet can avoid being convicted by transferring > responsibility, then the situation would still be open and be a > nightmare : removing plagiarized code entangled down the core of the > software and all its dependency code, and rewrite it without IP issue > is really hard > > Therefore, I do not think this mention is enough for IP protection. > > This rationale concerns the generated code itself, contributed to QGIS > or other software in the ecosystem. LLMs may be useful and without IP > risks to help find bugs, write parts of documentations where there is > no risk of plagiarism, or other use cases. > > But I would definitely **forbid any generated code to be introduced > into the main source code because of IP risk**. > > Also, the least we can do for any contribution, is not only to have a > human in the loop, but also to have a mandatory mention and > description of LLM usage for each contribution. This would at least > give traceability. It does not solve anything, but in case of a > problem, we could at least start to investigate. > > A am glad this conversation takes place, and willing to pursue the > discussion, sorry for having been long. > > Have a nice weekend, > > Vincent > > > > > > On 31/01/2026 01:01, Greg Troxel via QGIS-Developer wrote: >> I would suggest a much stronger policy: >> >> ?? no LLM-generated code or discussion may be submitted to any QGIS >> forum >> >> >> The idea that LLM-generated code has been "reviewed" intends to be that >> it is of high enough quality that it is reasonable for *humans* to spend >> time reviewing it.? But I don't believe that asking that it be reviewed >> will achieve that in practice. >> >> I've already had the experience (in a different project) of seeing a >> posted PR(ish, patch on list), taking the time to comment, and getting >> LLM-generated (vacuous) replies to my comments. >> >> Besides the ethical problems with asking humans to review, improve, >> judge or in any other way pay attention to LLM output, there's the >> problem of copyright.? While machine-generated text isn't copyrightable >> as is, LLM output is a derived work of stolen human work, scraped >> and used without permission, often as DDOS. >> >> On the basis of each reason, I believe the policy about LLM should just >> be "no". >> _______________________________________________ >> QGIS-Developer mailing list >> QGIS-Developer at 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 at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- http://www.spatialys.com My software is free, but my time generally not.