Pressione isto: Seus plug-ins do WordPress são compatíveis com GPL?

Bem-vindo ao Press This, o podcast da comunidade WordPress do WMR. Cada episódio apresenta convidados de toda a comunidade e discussões sobre os maiores problemas enfrentados pelos desenvolvedores do WordPress. A seguir está uma transcrição da gravação original.

Desenvolvido por RedCircle

Doc Pop : Você está ouvindo Press This, um podcast da comunidade WordPress no WMR. Toda semana destacamos membros da comunidade WordPress. Sou seu anfitrião, Doutor Pop. Apoio a comunidade WordPress por meio de minha função no WP Engine e de minhas contribuições no TorqueMag.io. Você pode assinar Press This no RedCircle, iTunes, Spotify ou seu aplicativo de podcasting favorito, ou pode baixar episódios diretamente de WMR.fm.

Se você já contribuiu para um projeto de código aberto, sabe que tudo se resume a colaboração e inovação, mas há um desafio pouco conhecido que muitos desenvolvedores podem enfrentar para garantir que seus plug-ins permaneçam no lado direito da GPL, GNU, Licença Pública Geral. Não é apenas uma questão de conformidade. Trata-se de preservar o espírito do código aberto.

Portanto, hoje temos um convidado especial, Jeff Paul, diretor de código aberto da 10up, que compartilhará uma solução revolucionária que apresentou no WordCamp US este ano. Imagine ter uma ferramenta que verifica sua base de código automaticamente para garantir a compatibilidade do seu plugin com a GPL, mesmo quando você adiciona novos recursos e dependências.

É sobre isso que vamos falar hoje. Mas antes de mergulharmos nisso, Jeff, você pode nos contar sua história de origem do WordPress?

Jeff Paul : Claro. Não sei se tenho o ano exato. Provavelmente foi no início dos anos 2000. Eu tinha um site pessoal que estava em um antigo CMS, acho que se chamava Geeklog. E entre isso e meu provedor de hospedagem na época, e quem sabe quantos outros fatores, houve, você sabe, um colapso de conteúdo no CMS.

E então eu estava apenas procurando por algo para substituir isso na época. Eu encontrei o WordPress e funcionou para o que eu precisava. Você sabe, não segui o caminho de construir um CMS sozinho, o que parece ser uma boa história de origem para muitas pessoas. Mas isso foi, chame-o, não sei, de 2004 a 2007, em algum lugar nessa faixa, mas não o fiz, meio que cruzei a barreira para contribuir até o lançamento do WordPress 4.7, quando me juntei ao time de lançamento lá com Helen Hou-Sandi e Aaron Jorbin. Então, passei muitos anos sendo um consumidor do projeto, e só depois de algum tempo é que me tornei um contribuidor e, você sabe, continuei nesse caminho desde então. Bem, você sabe, duplo consumidor e contribuidor neste momento.

DP : E você também tem sido um contribuidor muito ativo do núcleo do WordPress. 10up mantém dezenas de plugins no repositório de plugins, incluindo ElasticPress, Distributor, ClassifAI. Todos estão disponíveis no repositório wordpress.org e são mantidos no GitHub, publicamente e usando práticas de código aberto.

Você está muito familiarizado com o tópico que iremos abordar. Por que não começamos com o repositório do WordPress, como o repositório de plugins do WordPress? Diga-nos rapidamente, o que é o repositório WordPress e quais são as regras para poder fazer upload de qualquer coisa para ele?

JP : Claro. Portanto, o repositório WordPress é hospedado pelo WordPress.org, o projeto de código aberto, separado do WordPress.com, separado de qualquer outro host no ecossistema, separado de empresas ou distribuidores de plug-ins terceirizados. E é o que está diretamente vinculado ou vinculado a cada instalação do WordPress que existe. Quando alguém está no administrador do WordPress e está procurando por um plugin ou tema, essas pesquisas são feitas por meio do repositório de plugins e do repositório de temas do WordPress.org, disponível no administrador do WordPress. E da mesma forma no WordPress.org. Efetivamente, a mesma pesquisa, o mesmo conteúdo, está disponível ali.

Em termos de obter algo listado lá, a equipe de revisão de plug-ins do wordpress.org tem um conjunto de diretrizes detalhadas sobre o que fazer e o que não fazer para desenvolvedores de plug-ins. E então há um fluxo de trabalho de envio real para fazer o envio inicial ao repositório de plugins wordpress.org. Depois que isso for aprovado, há um repositório SVN criado para o seu plugin. E, você sabe, quaisquer atualizações, lançamentos, etc. são enviadas para o SVN. E é aí que tudo vive e respira atualmente para coisas que estão disponíveis para pesquisa no WordPress.org ou no administrador do WordPress.

DP : Uma das primeiras regras que acredito é que tudo o que você coloca no repositório do WordPress precisa ser compatível com a GPL, incluindo fontes e imagens, não apenas o código. Isso está correto?

JP : Correto. Certo. Então, literalmente, a primeira regra da equipe de plugins é que todos os plugins devem ser compatíveis com GPL. Essa é a mesma licença que o WordPress segue e, como você mencionou, código, imagens e bibliotecas de terceiros devem ser compatíveis com GPL. Não precisa ser necessariamente a licença GPLv2 real, existem outras que são compatíveis com GPL, mas sim, fontes, imagens, bibliotecas de terceiros, dependências, tudo isso precisa ser compatível com GPL e não apenas o código que um desenvolvedor de plugin escreve, certo? Todas essas outras coisas também precisam ser compatíveis com GPL.

DP : E só para não deixarmos os ouvintes esperando, poderíamos simplesmente começar. Sua palestra foi sobre como verificar a compatibilidade da GPL usando ações do GitHub. Você pode nos orientar nesse processo?

JP : Sim, isso decorre um pouco do meu papel como diretor de código aberto na 10Up. Talvez não seja algo que um autor de plug-in comum, você sabe, um único plug-in ou mesmo vários possa estar ciente ou incomodá-los. Mas acho que em algum momento eu acordei quase literalmente no meio da noite pensando: “Não sei se tenho certeza de que você sabe, todas as imagens, todas as dependências de terceiros, todas as fontes , etc., são compatíveis com GPL e estão tentando descobrir uma maneira em escala para nós no 10up, onde temos, como você mencionou, dezenas de plug-ins que estão disponíveis no repositório wordpress.org ou no GitHub também. A fonte aí.

Eu não queria ter que passar por tudo isso com um pente fino e verificar quaisquer dependências upstream que estávamos usando para os plug-ins e descobrir, você sabe, como eles são licenciados. Isso pode ser um incômodo para um único plugin, quanto mais para vários. E através de algumas pesquisas on-line, identifiquei que havia algumas ferramentas, algumas ações do GitHub que poderiam ser usadas para ajudar a automatizar efetivamente esse processo para que, você sabe, não apenas uma única verificação única de um repositório para dizer, sim, você é compatível ou não, você não é, mas verificações contínuas para que quaisquer futuras correções de bugs, melhorias, etc., que possam adicionar uma nova dependência ou talvez eliminar uma dependência em seu plugin que talvez tenha mudado a forma como algo era licenciado, ser capaz de verificar isso continuamente e fazer esse tipo de passagem pela primeira vez era algo que eu estava tentando descobrir para que não se tornasse apenas um processo manual e intensivo e uma espécie de pesadelo contínuo para garantir que , essa compatibilidade.

Então, sim, quero dizer, acho que a preocupação inicial que tive foi: eu não sabia disso - não tinha como saber que algum recurso que adicionamos, se incluirmos uma nova dependência, era compatível com GPL , e então percebemos que poderia ter havido um cenário ainda pior, onde tínhamos plug-ins que foram lançados, iterados e que já apresentavam incompatibilidades em seus softwares.

E esse foi o primeiro problema que eu queria tentar resolver. Aquela primeira varredura inicial, certo? Nossos plug-ins individuais, e todos aqueles que o 10up suporta, são realmente compatíveis com a licença que declaramos? E, esperançosamente, cruzamos os dedos. E então, você sabe, a partir daí, aquela verificação contínua para garantir que futuros PRs, sejam eles da minha equipe e da prática de código aberto no 10up, amplamente com outros 10upers contribuindo para os projetos, ou apenas qualquer pessoa na comunidade, garantindo que estes mantivessem o licenciamento que declaramos nos próprios plugins.

DP : E só para esclarecer aqui, se você não fez isso, se você descobriu através disso, que havia, uh, alguma dependência existente ou algo lá que não era compatível, a ramificação é meio que vergonhosa do comunidade ou há possivelmente danos punitivos que você poderia sofrer por não seguir as regras?

JP : Então não sou advogado, certo? Então, você sabe, eu não tenho a função de advogado para fazer esse comentário, então, você sabe, não é um conselho jurídico válido, mas a abordagem que tomei enquanto executava essas varreduras em nossos plug-ins, porque, novamente, não o fiz. sabe, na verdade eu estava muito nervoso ao executar tudo isso, quais seriam os resultados.

Meu plano era se eu descobrisse que havia um plugin que estava usando algo que não era compatível com GPL, que a melhor abordagem seria remover essa dependência, trocá-la por outra coisa, efetivamente limpar isso, qualquer que fosse o problema foi e lançar rapidamente uma nova versão, certo?

Não havia muito que eu achasse que pudesse ser feito pelo que já havia sido publicado e divulgado. Do meu ponto de vista, nada disso teria sido feito de forma a tentar contornar propositalmente o licenciamento. teria sido apenas, você sabe, em algum ponto ao longo do processo, um erro humano, algo semelhante a um problema de segurança que é relatado ao autor de um plugin. Tipo, a melhor abordagem é trabalhar em uma correção e lançar rapidamente um lançamento para que as pessoas que estão atualizadas sobre os plug-ins estejam em um estado mais seguro, seja por um problema de segurança ou, neste caso, por uma preocupação de licenciamento. Certamente, se por acaso houvesse um plugin que gerasse receita significativamente, e se talvez pudesse haver, razões para mostrar que era um erro conhecido ter algo não licenciado, à parte, não acredito que alguém no espaço está fazendo isso de propósito, mas acho que os únicos que potencialmente estariam em risco legal seriam aqueles que geram receitas significativas, que seriam alvo de licenciamento.

Então, sim, resumindo a história, se alguém executar uma varredura e encontrar um problema em sua base de código existente, acho que a melhor abordagem é realmente emitir um lançamento, uma versão atualizada, você sabe, chamar no log de alterações, diga nas notas de lançamento o que foi alterado e por quê, seja transparente sobre isso. Mas nesse ponto, acho que isso é realmente o melhor que um autor de plugin pode fazer nesse caso. Felizmente para os plugins do 10up, não encontramos esse cenário. Felizmente, tudo era compatível, e eu espero que a grande maioria das pessoas que seguem esse caminho, configurando alguma automação para lhes proporcionar esse nível de conforto, tenham uma experiência semelhante.

Pode ser um pouco nervoso e ansioso esperar alguns segundos ou um minuto para que as ações do GitHub sejam executadas. Mas, você sabe, uma vez que isso mostra que tudo passa, acho que a maioria das pessoas provavelmente acabaria nesse estado.

DP : Falando em ficar confortável, vamos fazer uma pequena pausa. Então sente-se e relaxe, e estaremos de volta após o curto intervalo comercial com mais entrevistas com Jeff Paul, diretor de iniciativas de código aberto da 10up, sobre como manter seus plug-ins compatíveis com GPL. Fique ligado para mais informações após este breve intervalo.

DP : Bem-vindo de volta ao Press This, um podcast da comunidade WordPress. Eu sou o Doutor. Estou conversando com Jeff Paul sobre o uso de ações do GitHub para garantir que seu código e seus plug-ins sejam compatíveis com GPL. Antes do intervalo, nós mergulhamos um pouco nisso e conversamos sobre as ramificações se você não estiver totalmente em conformidade. E acho que queria voltar a esse assunto específico. Existem ações do GitHub que qualquer pessoa pode criar. Mas Jeff, você mencionou em sua palestra no WordCamp que usa a ação oficial do GitHub, acho, com algumas pequenas mudanças. Você pode nos dizer qual é o nome da ação que as pessoas deveriam procurar para poder fazer isso?

JP : Claro. É uma ação de revisão de dependência. Então, GitHub.com, ações de barra, dependência de barra, revisão de hífen, ação de hífen. Esperançosamente, a transcrição acerta isso. Se houver algum problema em descobrir que tenho anotações sobre isso em meu site, em uma postagem que cobre a palestra. Portanto, existem links disponíveis, mas se você procurar por ações de revisão de dependências no mercado de ações do GitHub, esperamos encontrar o oficial que usei, e ele faz mais do que apenas verificar as dependências do plugin. Ele verificará mais do que apenas as licenças. Ele também pode verificar vulnerabilidades e outras coisas nas dependências do seu plugin. Mas a única coisa para a qual eu o uso, a principal coisa para a qual eu o uso, é verificar se há licenças inválidas nas dependências de nossos plug-ins.

DP : E esta é uma ação que você pode configurar que tipo de GPL você deseja seguir. Você pode incluir uma licença e ela verifica isso. E também existe a possibilidade, se você mantiver, digamos, dezenas de plug-ins, de ainda poder obter a mesma coisa. Você pode ter todos esses plug-ins que você mantém ainda chegando a esse diretório, então você não precisa ir e atualizá-los todas as vezes, certo?

JP : Correto. Sim. Vejo que você assistiu à minha palestra no WordCamp US, parabéns por estar na plateia, acordado e ouvindo, ou você assistiu no YouTube ou WordPress.tv, mas sim, existem dois fluxos padrão que eu esperaria, pessoal para acompanhar aqui.

Um, um autor de plug-in que é responsável por um ou um número muito pequeno de plug-ins, ou alguém que tem mais na escala de um para n, eles têm tantos plug-ins que suportam. Portanto, para pessoas que têm apenas uma, a ação do GitHub, conforme você a definiu, pode efetivamente dentro daquele arquivo de fluxo de trabalho onde você está efetivamente chamando aquela ação de revisão de dependência e fazendo com que ela varra seu repositório, há duas variáveis ​​ambientais ou parâmetros que você pode fornecer. Essa ação é permitir licenças e o corolário disso é negar licenças. Você não pode fazer as duas coisas ao mesmo tempo. e a abordagem que adotei foi optar pelas licenças de permissão em vez das licenças de negação. O pensamento era… Eu preferiria ter um caso em que me esquecesse de incluir uma licença compatível com GPL na lista de licenças permitidas e obtivesse efetivamente um falso positivo, certo? Como ter uma dependência sinalizada como não compatível com minhas licenças porque sua licença foi apenas algo que esqueci de adicionar na lista, em vez de usar a lista de licenças negadas e esquecer de negar uma licença que não quero, então isso poderia significava que uma dependência passaria, não seria detectada por esta verificação.

Portanto, minha recomendação extremamente forte é seguir essa lista de licenças permitidas. E no caso de alguém manter um único plugin, basta usar esse parâmetro e aquela lista de licenças em seus arquivos de fluxo de trabalho. Então, para o 10up, para nossos plug-ins, esse é o diretório ponto GitHub e, em seguida, o subdiretório workflows. E então temos o fluxo de trabalho de revisão de dependência que chama essa ação de revisão de dependência, tem a lista de licenças permitidas, você pode acessar minha apresentação no meu site ou encontrar a palestra online e ver a lista de licenças que temos. Você também pode explorar qualquer um dos repositórios do 10up no GitHub e ver as licenças que exploramos.

Nossos arquivos de fluxo de trabalho são bastante bem documentados e explicam como identificamos o que consideramos licenças compatíveis com nossos plug-ins. Então, as pessoas seriam bem-vindas para usar a lista que temos, seriam bem-vindas para usar um subconjunto dessa lista, seriam bem-vindas para fazer suas próprias pesquisas, talvez para sentir esse nível de conforto. Mas fizemos uma pesquisa bastante extensa para ter certeza de que o que estávamos usando em nossa lista de licenças permitidas é realmente compatível com o que declaramos. E praticamente por padrão para 10up, usamos GPLv2 ou posterior e, portanto, todas as licenças que listamos são compatíveis com GPLv2, especificamente.

Então esse é o caso, novamente, do autor do plugin com um único plugin que está mantendo. Como você mencionou, para o caso em que alguém tenha mais de uma, múltiplas, você pode ter um arquivo de política de licença separado que efetivamente contenha todas essas licenças declaradas. E então você faz referência a esse arquivo de configuração, a esse arquivo de política de licença, no fluxo de trabalho em seus plug-ins, para que, como você mencionou, você realmente tenha apenas um local necessário para manter a lista de licenças compatíveis. Se acontecer de haver, você sabe, uma nova licença de código aberto aprovada por iniciativa que seja compatível com GPLv2 para nós, certo? Se um novo entrar em cena, ele poderá ser adicionado à lista, ou talvez se alguém precisar ser removido por qualquer motivo, você não precisa fazer isso em dezenas de locais. Você faz isso em um local e, em seguida, todos os arquivos de fluxo de trabalho que fazem referência a essa configuração são atualizados imediatamente, usando essa nova lista de licenças.

DP : Tudo isso é automatizado, então se alguém fizer uma solicitação pull, ele fará isso só para você. Certo?

JP : Correto, correto. Assim, à medida que criamos nossos arquivos de fluxo de trabalho em nossos repositórios, temos um gatilho em uma solicitação pull. Então, talvez você também possa configurá-lo para ser executado em uma programação CRON, você pode executá-lo semanalmente ou mensalmente, mas, na verdade, depois de fazer a primeira execução, você verifica toda a base de código das dependências e realmente vai daqui para frente, você realmente só precisa verificar as solicitações pull que estão chegando. Você provavelmente também pode verificar commits individuais se não estiver usando um sistema bastante rigoroso de exigência de PRs em quaisquer que sejam suas ramificações padrão ou estáveis ​​para seus plug-ins.

Portanto, pode haver gatilhos adicionais que as pessoas possam querer usar. Para o 10up, tendemos a exigir estritamente que PRs desenvolvam e troncos de ramificações para que possamos usar essa ação de maneira confiável e saber que quaisquer alterações nas dependências que introduzam uma nova ou alterem uma versão que altere a licença serão capturadas por isso . Então, sim, nós usamos, dinamizamos ou acionamos solicitações pull, mas dependendo de quão rigorosas as pessoas são, você pode, talvez, ter aquela verificação de commits individuais em um branch específico, ou até mesmo executar uma programação diária, semanal, mensal, apenas ter aquele conforto de saber que seu código ainda está passando, que não existem licenças incompatíveis com, neste caso, GPLv2 para 10up.

DP : Faremos outra pequena pausa aqui. Quando voltarmos, encerraremos nossa conversa com Jeff Paul sobre licenças GPL e talvez retomaremos algo que não abordamos anteriormente. Portanto, fique ligado para saber mais após este breve intervalo.

DP : Bem-vindo de volta ao Press This, um podcast da comunidade WordPress. Estamos encerrando o show e vamos mudar um pouco de assunto. Tem havido alguma conversa ultimamente sobre o processo de revisão no repositório de plugins e, basicamente, afirmando que é um pouco mais lento do que no passado.

Algumas pessoas estão dizendo que sabem que está demorando, você sabe, meses para que algo seja revisado, onde acho que vi o pico em talvez quatro semanas na maior parte dos meus anos no WordPress. Então, Jeff, eu sei que eles conversaram sobre talvez algumas mudanças que farão nisso. Você pode nos dizer no que a equipe está trabalhando agora?

JP : Claro. Sim. E eu, você sabe, ampliei o que você disse. Acho que, historicamente, vi que todas as coisas que enviei demoraram menos de duas semanas e foram muito mais rápidas do que normalmente é relatado. E isso dura cerca de 88 dias ou algo lamentável para todos os envolvidos.

Acho que houve alguma rotatividade nessa equipe. Algum conhecimento sênior muito experiente foi perdido. E acho que as pessoas que gentilmente intervieram para ajudar a preencher essa lacuna ainda estão chegando ao ponto em que podem ter o mesmo tipo de rendimento no processamento de plug-ins e na revisão dos envios iniciais. E há um trabalho que eles estão fazendo para tentar automatizar parte disso. Então, algumas das coisas que, você sabe, os computadores são melhores em que os humanos talvez não sejam, talvez como executar padrões de codificação do WordPress e aprimorar onde há erros realmente críticos relatados, certo? Em vez de um ser humano ter que passar e processar essas coisas, ter um verificador de plug-ins que executa e verifica coisas que podem ser automatizadas e ajudar a equipe de revisão de plug-ins a apenas fazer uma rápida pausa inicial do tipo, as coisas são automatizadas? Se sim, então tudo bem, mergulhe em sua revisão humana e acelere as coisas. Se coisas foram relatadas, sendo de natureza automatizada que não estão passando, então é, eu acho, uma resposta mais rápida para aquele desenvolvedor de plugins de, ei, nós identificamos essas coisas iniciais em nossa varredura, você sabe, por favor, resolva essas e, em seguida, envie um arquivo zip atualizado para colocar as coisas de volta no caminho certo.

Então eu sei que eles estão trabalhando para adicionar alguma automação, acho que quanto mais eles puderem fazer para ajudá-los nesse caminho, melhor, só porque neste ponto, com mais de mil plugins, o backlog é longo, e novamente , não ajudando ninguém lá. Então, sim, eles estão trabalhando em automações. Eu sei que eles querem fazer mais, e acho que se essa é uma área em que alguém é particularmente talentoso em automações e deseja contribuir, acho que a equipe de revisão de plugins adoraria ter ajuda nesse aspecto. Então, certamente entre em contato com o Slack, se for esse o caso.

DP : E falando em entrar em contato, se as pessoas tiverem dúvidas, sobre sua palestra que você deu no WordCampUS, ou apenas alguns dos projetos em que 10uP está trabalhando no espaço de código aberto, qual é a melhor maneira para as pessoas entrarem em contato com você ?

JP : Claro. Portanto, meu site é jeffpaul.com. Tenho minha apresentação aí, se você apenas pesquisar por GPL, provavelmente será um dos primeiros posts de qualquer maneira. Caso contrário, meu email é [email protected] , meu email de trabalho, hum, e praticamente todas as redes sociais. WordPress.org, GitHub, Twitter, barra X, e eu sou @Jeff Paul, e vocês podem me encontrar nas redes sociais dessa forma.

DP : Da mesma forma, se os ouvintes quiserem encontrar exemplos de talvez o trabalho do 10uP no GitHub, presumo que seja apenas o 10uP no GitHub.

JP : Correto, sim, github.com/10up. Todos os repositórios de nossos plug-ins estão disponíveis publicamente. Nossa equipe acompanha de perto novos problemas e PRs. Tudo isso é canalizado para nosso canal do Slack, então qualquer coisa, qualquer dúvida que as pessoas tenham, qualquer discussão, eles abrem lá. Nossa equipe deve ser bastante receptiva a isso, mas se não, você sabe, entrar em contato comigo no WordPress Slack, no Twitter por e-mail, qualquer um desses funciona. Fico sempre feliz em conversar sobre código aberto com pessoas da comunidade.

DP : Bem, muito obrigado por se juntar a nós hoje, Jeff, foi muito bom conversar com você e aprendi muito sobre as ações que o GitHub tem para pull requests e automatizar essa experiência. Isso é muito útil.

Se você perdeu o episódio da semana passada do Press This, conversamos com Carmen Johnson sobre as etapas que você pode seguir para preparar seu site para o fim da vida útil do MySQL 5.7 e como se preparar para o MySQL 8. Esse é um episódio muito bom para você pode conferir, e temos muito mais. Você pode encontrá-los em TorqueMag.io se quiser encontrar versões transcritas. Obrigado por ouvir Press This, um podcast da comunidade WordPress no WMR. Você pode acompanhar nossas aventuras no Twitter, na Torque Mag.

Você pode assinar Press This no RedCircle, iTunes, Spotify ou seu aplicativo de podcasting favorito, ou pode baixar episódios diretamente de WMR.fm. Sou seu anfitrião, Dr. Popular. Apoio a comunidade WordPress por meio de minha função no WP Engine e adoro destacar os membros dessa comunidade todas as semanas no PressThis.