Non tu peux prendre le code libre des versions qui le sont
déjà, les forker, voir s'il y a eu des CVE publiées, auditer le
code, corriger les failles si tu en vois
En théorie, oui.
En pratique, je pense qu'il y a des complications assez rapidement. Par exemple, il faut s'assurer de corriger un bug avec un correctif différent, pour ne pas risquer d'être accusé d'avoir fait un backport de code non libre vers du code libre.
Et c'est pas super dur de trouver des exemples ou ça va être dur de prendre un autre correctif. Par exemple, CVE-2022-0185, il n'y a pas des tas de façons de corriger ça autrement, ou pas sans introduire des changements "pour rien":
On pourrait argumenter "ce sont des changements triviaux donc le copyright ne devrait pas s'appliquer", comme on pourrait le dire pour une typo évidente que n'importe qui pourrait trouver (car il faut un minimum de créativité pour pouvoir bénéficier des protections via le mécanisme du copyright, au moins en droit US et sans doute ailleurs).
Mais ça me semblerait difficile à défendre quand il y a tout une industrie visant à trouver les changements triviaux et qui fait payer ça "cher". Et vu que le business model de la boite qui a choisi la BSL est aussi de vendre la maintenance sur ces changements triviaux, il est probable qu'elle ne verrait pas ça d'un bon œil, donc le risque est la.
Et je pense que c'est le but de la BSL, augmenter le risque pour servir de dissuasion à des concurrents.
[^] # Re: BSL, Mariadb et Cockroach
Posté par Misc (site web personnel) . En réponse au journal Tout le monde (ou plutôt, trop de gens) continue de se foutre des licences en 2023. Évalué à 6.
En théorie, oui.
En pratique, je pense qu'il y a des complications assez rapidement. Par exemple, il faut s'assurer de corriger un bug avec un correctif différent, pour ne pas risquer d'être accusé d'avoir fait un backport de code non libre vers du code libre.
Et c'est pas super dur de trouver des exemples ou ça va être dur de prendre un autre correctif. Par exemple, CVE-2022-0185, il n'y a pas des tas de façons de corriger ça autrement, ou pas sans introduire des changements "pour rien":
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=722d94847de2
Autre exemple, le correctif de la faille CVE-2018-13053:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=5f936e19cc0ef97dbe3a56e9498922ad5ba1edef
Ou celui la pour CVE-2017-18257:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b86e33075ed1909d8002745b56ecf73b833db143
On pourrait argumenter "ce sont des changements triviaux donc le copyright ne devrait pas s'appliquer", comme on pourrait le dire pour une typo évidente que n'importe qui pourrait trouver (car il faut un minimum de créativité pour pouvoir bénéficier des protections via le mécanisme du copyright, au moins en droit US et sans doute ailleurs).
Mais ça me semblerait difficile à défendre quand il y a tout une industrie visant à trouver les changements triviaux et qui fait payer ça "cher". Et vu que le business model de la boite qui a choisi la BSL est aussi de vendre la maintenance sur ces changements triviaux, il est probable qu'elle ne verrait pas ça d'un bon œil, donc le risque est la.
Et je pense que c'est le but de la BSL, augmenter le risque pour servir de dissuasion à des concurrents.