Oi Ralden,
Obrigado por me esclarecer sobre GPL e obrigações de quem faz uso de software baseado nesta licença. Então agora eu preciso explicar melhor o que eu quero fazer e de que forma o plugin que tenho em mente vai trabalhar.
Eu me equivoquei, quando escrevi perguntando se poderia pedir a um programador que use o mesmo código base do plugin desenvolvido pelo Claudio Sanches. Para ser exato, eu só preciso que o painel administrativo seja parecido, ou seja, tenha as mesmas opções (se possível, na mesma ordem) e mais algumas configurações referentes ao meu plugin. A ideia é que o painel pareça familiar a quem já faz uso deste plugin tão popular.
Reconheço que não sou programador PHP nem de qualquer outra linguagem usada na web. As únicas linguagens que domino (pouco) são QBASIC e Assembly de microprocessadores de 8 e 16 bits, que aprendi sozinho na adolescência nos anos 1980. Hoje estas habilidades não servem de muita coisa, mas ao menos me permitem entender que é possível fazer um painel igual ao do plugin existente, porém usando código diferente. É claro que para oferecer opções iguais, o código seria similar em vários aspectos, porém não necessariamente igual.
Sobre a questão da monetização, eu compreendi bem as situações que me explicou. Pessoas são complicadas mesmo, eu sei como é isso. Entendo a frustração de quem faz software e o disponibiliza de graça, depois vem gente reclamando que não funciona direito. Por outro lado, também entendo o sentimento de quem pega software gratuito, esperando que funcione como deve. “Pra que essa porcaria que não funciona?” é o que alguns mais exaltados perguntam.
Especificamente sobre plugins que acessam o webservice dos Correios, tem aquela questão de quando os Correios fazem alguma mudança que compromete o funcionamento do plugin. E isso nem todo mundo leva em conta, querendo que o desenvolvedor conserte logo a droga do software grátis que ele fez. Gente chata e sem noção faz parte do negócio, infelizmente.
O plugin que tenho em mente trabalhará com apenas 3 métodos de entrega: Carta, PAC e SEDEX, que são os mais usados por lojistas. Uma tabela de frete offline não pode oferecer SEDEX 10, 12 e Hoje, porque a lista de CEPs de origem e destino válidos muda constantemente. Impressos nem podem ser usados para envio de compras (talvez para livros) e as opções internacionais também são pouco usadas. De forma que decidi limitar aos 3 principais métodos para envio, que eu acredito, devam atender mais de 95% das lojas online que entregam apenas no Brasil.
A mecânica do plugin que eu tenho em mente não fará uso do webservice para obtenção de preços. Todos os valores serão calculados por um algoritmo interno, baseado em tabelas que somam meros 234 KB. A única dependência do webservice será para obtenção de prazos de entrega, que também não podem ser armazenados em tabela offline, uma vez que mudam diariamente. Instruí o programador a incluir no código um timeout na função que aguarda pela resposta de prazos. Se a resposta do webservice demorar, então o plugin prosseguirá apenas com os preços dos envios e apresentará uma mensagem que não foi possível obter prazos de entrega. Até mesmo o link que vai obter do webservice os prazos estará disponível no painel. Caso haja alguma mudança, o próprio lojista poderá copiar e colar o novo link diretamente no painel.
Estou sendo cauteloso e tentando pensar no máximo de possibilidades que conseguir, para dar liberdade ao lojista de resolver problemas por conta própria. Antes de começar a fazer qualquer cobrança, seja pelo uso do plugin, seja pelos dados que ele usará, eu conduzirei um período de testes com lojistas que desejem experimentar esta solução. Pretendo sanar todos os possíveis erros antes de colocar no mercado o meu plugin, que acredito será uma adição interessante ao WooCommerce.