Default to MapLibre and load Mapbox externally

[bwstefano]

Summary

• default the JEO runtime to MapLibre, require a Mapbox API key before saving the Mapbox option, and surface the settings validation error in the admin UI
• remove the bundled Mapbox SDK/React wrapper, load Mapbox GL JS externally from the Mapbox CDN when requested, and keep runtime fallback notices, smoke assertions, and bundle-size budgets aligned with the unified mapgl bundles
• make map previews autosave-aware and align popup, fullscreen, attribution, and compact-control behavior across maps, storymaps, and Discovery while keeping the Mapbox attribution requirements explicit
• converge repository and package metadata on GPL-3.0-only and document Mapbox as an optional external integration rather than bundled plugin code

Testing

• npm run check:env
• npm run build
• npm run build:report
• npm run test:unit -- --passWithNoTests
• vendor/bin/phpcs --standard=phpcs.xml.dist
• php scripts/check-php-compat.php
• WP_CLI_PHP=/opt/homebrew/opt/php@8.4/bin/php WP_DIR=/tmp/jeo-plugin-wordpress-smoke bash scripts/wordpress-smoke.sh

Stack

• Base branch: codex/jeo-public-metadata-sync
• Stacked on Standardize JEO public metadata and sync prerelease package manifests #513
• Commit: a397616

[leopiccionia]

default the JEO runtime to MapLibre, require a Mapbox API key before saving the Mapbox option, and surface the settings validation error in the admin UI

Mudar a biblioteca padrão para MapLibreGL, apesar de ser positivo (pois é FOSS e pode facilitar a aprovação da loja), torna a atualização do plugin mais arriscada para instalações existentes, pois o MapLibreGL não é 100% compatível com algumas funcionalidades mais novas do Mapbox Studio.

remove the bundled Mapbox SDK/React wrapper, load Mapbox GL JS externally from the Mapbox CDN when requested, and keep runtime fallback notices, smoke assertions, and bundle-size budgets aligned with the unified mapgl bundles

Deve causar degradação de desempenho em usuários usando MapboxGL, mas, de resto, 👍 .

make map previews autosave-aware and align popup, fullscreen, attribution, and compact-control behavior across maps, storymaps, and Discovery while keeping the Mapbox attribution requirements explicit

Vou testar com cuidado essas questões.

Acho que o principal ponto de atenção será a compatibilidade do bloco de storymap com as opções de alinhamento.

converge repository and package metadata on GPL-3.0-only and document Mapbox as an optional external integration rather than bundled plugin code

O WordPress é licenciado sobre GLPv2. Código GPLv2 não pode incluir (por exemplo, como plugin) código GPLv3, pois as licenças são mutuamente incompatíveis (segundo posição do próprio Projeto GNU, autor da GPL).

Por isso, plugins WordPress são licenciados ou em licenças permissivas (MIT, BSD, ISC, etc.), ou GPLv2, ou GLPv2+ ("GPL v2 or later"). Até onde sei, a loja do WordPress não aceita plugins com licença "GPL v3 only".

Além disso, salvo engano, o PR não atualiza o texto do arquivo de licença na raiz do repositório.

Conseguimos reverter esse último ponto?

[leopiccionia]

Estou categorizando esta issue na milestone 3.0 pois considero essa mudança uma breaking change.

[bwstefano]

@leopiccionia, você trouxe alguns temas importantes e vou explicar com cuidado em tópicos:

Licenciamento do Mapbox

A mudança que vocês desenvolveram e disponibilizaram até a versão 3.0.0-rc3 do plugin em setembro adicionou suporte ao MapLibre. Isso foi ótimo para aumentar a compatibilidade do plugin com o código livre, mas, em termos de licenciamento, faltava considerar um aspecto: na versão 3.0.0-rc3 nós ainda estávamos distribuindo a SDK do Mapbox, como fizemos desde o início do plugin do JEO.

No início, era possível incluir o SDK do Mapbox GL JS porque ele era distribuído sob uma licença aberta BSD. Depois que este SDK foi atualizado da versão 1.13 para a 2.0, a gente não deveria ter continuado a distribui-lo com o nosso plugin, como fizemos no commit 0126ef1, incorporado no release 2.11.0. Isto porque o Mapbox GL JS passou a usar a licença Mapbox Terms of Service. Esta licença não é livre pois os ativos licenciados sob ela podem ser usados apenas com os produtos Mapbox, por desenvolvedores com conta ativa e em boa situação. Portanto, é incompatível com licenças GPL.

Este PR resolve isto: ao deixar de distribuir o código do Mapbox e chamá-lo externamente, direto do servidor deles, a gente deixa o plugin 100% alinhado a uma licença GPL, pois todos os demais pacotes distribuídos também são compatíveis com esta licença.

Isso nunca teria sido possível sem a inclusão do MapLibre GL. Com este SDK, o JEO vira um plugin totalmente funcional apenas com software livre e o uso do Mapbox GL JS passa a ser opcional. Diz o FAQ da GPL elaborado pela GNU:

If your program depends on a nonfree library to do a certain job, it cannot do that job in the Free World. If it depends on a nonfree library to run at all, it cannot be part of a free operating system such as GNU [...] there may also be legal issues with combining certain nonfree libraries with GPL-covered free software

Ou seja: se vocês não tivessem adicionado o MapLibre, o JEO continuaria sendo incompatível com uma licença GPL mesmo que a gente não estivesse distribuindo o SDK do Mapbox GL JS e o chamasse pela fonte apenas.

Questões de compatibilidade

Em essência, para quem já usava o JEO até a versão 2.15.1, nada muda: o plugin já exigia inserir uma chave API do Mapbox para ser usado, então a totalidade dos usuários vai continuar usando o Mapbox como opção, tal como vocês desenvolveram para a versão 3.0.0-rc3. Essa preferência e a chave API ficam salvas e as duas coisas são levadas de uma versão para a outra na atualização. Por isso, não considero que haja uma quebra, não é uma breaking change.

O MapLibre entra como padrão para novos usuários: quem não usava o JEO antes, pode começar a usar independentemente do Mapbox. Mas sempre existe a opção de trocar a SDK usada do MapLibre para o Mapbox. O MapLibre só entra "forçado" como contingência: caso, por algum motivo, o usuário não consiga conectar ao servidor do Mapbox, o MapLibre, que é disponibilizado localmente, é carregado. Quando isso acontece, o editor do WordPress e o console do navegador mostram uma aviso, além da mudança também poder ser notada nas atribuições do mapa.

Compatibilidade com licença do WordPress

É verdade que a licença do WordPress é GPLv2, mas ele e todos os pacotes relacionados estão licenciados sob a GPLv2 (or later), como você pode conferir aqui, aqui e aqui, por exemplo. Isso está declarado nos pacotes também, como aqui.

Então, o JEO passa a ser compatível com qualquer pacote que, entre aqueles que estão em licenças GPL, sejam GPLv2 (or later) e GPLv3.

O WordPress passou a ser GPLv2 (or later) em janeiro de 2011, enquanto a GPLv3 foi lançada em junho de 2007. Como as duas coisas aconteceram há bastante tempo, me parece que o ambiente já está bem consolidado para a gente ir para uma licença mais moderna para distribuição, e acho difícil que a gente algum dia precise depender de um pacote GPLv2 (only).

A loja do WordPress aceita plugins com licença GPLv3, sim. A diretriz, explicitada aqui, é:

Plugins must be compatible with the GNU General Public License v2 or later.

Licenciamento do plugin

Este PR de fato não atualiza a licença na raiz do plugin. Ele apenas padroniza porque a gente estava declarando várias licenças diferentes, de forma inconsistente, nos diferentes arquivos do plugin. Declarávamos:

• A licença GPLv2 (sem definir se é "only" ou "or later") no composer.json
• A licença GPLv2 (or later) em ‎src/jeo.php, src/languages/jeo.pot e src/readme.txt
• A licença ISC em package-lock.json e package.json

Enquanto isso, o arquivo LICENSE declarava, desde antes da primeira versão do plugin, que a licença usada seria a GPLv3.

[leopiccionia]

@bwstefano Pode alterar o branch de destino, para testarmos esse PR dentro do contexto da milestone 3.0. Pode ser o branch master ou, preferencialmente, o develop.

De quais PRs este depende?

[bwstefano]

Quando eu comecei a fazer esses PRs, eu não queria mexer no trabalho que vocês já tinham finalizado – até porque já tinham chegado à etapa de release candidate. Então, este PR e os outros PRs foram feitos em cascata. Este depende do 513, que depende do 512, que depende do 511 e assim vai.

Então, se eu retargetear agora para develop ou master, o PR vai passar a incluir toda essa stack no diff, e não só a mudança específica do #514. Para levar para o develop ou master eu entendo que a gente teria que fazer um rebase da mudança.

Por isso acho que o melhor caminho vai ser puxar isso pro 3.1. Ou então deixar todos os PRs em cima do 3.0.