|
This problem was never reported a single time on our Zulip or by email, but I'm glad you asked, because this choice wasn't obvious: - The main reason the CLA is there is that earlier versions of Libpijul saw lots of online arguments about its very reasonable GPL2 license, which made me doubt of the choice of GPL2. These arguments were often followed by "@me was there"-style contributions to Libpijul, like applying linter fixes without understanding any of the code. I got scared of having to ask all past contributors for permission to release it under (say) a BSD license (which I have even recently discussed with the FreeBSD maintainers during FOSDEM 2024). - Also, the fact that the Pijul binary is GPL2 (without a CLA) and dependent on Libpijul forces me, in the case of an evolution of the license, to choose something compatible with GPL2. Deal breaker, really? - Another goal of the CLA was to experiment with something cool and meta, at the interactions between version control and licensing: I wanted to test the idea that the CLA was a single patch (or a sequence of patches, strictly ordered by dependency), and contributors would be required to add a dependency on the CLA patch. That would make them state in their patches which version of the CLA the agreed with when they recorded. And as Pijul does a lot of dogfooding… - Other than that, the Pijul plumbing is indeed mostly meant to become just a static algorithm after a while, not many features are missing. The goal of Pijul is to have essentially three core functions, create a patch, apply a patch, unapply a patch. |
> This problem was never reported a single time on our Zulip or by email
This shouldn't be surprising; the CLA requirement drives away contributors before their first contribution. Like me. I saw no point in a person who hasn't made any contributions petitioning you for a policy change. This phenomenon is one of the insidious effects of policies which ward off contributors before they make their first contribution.
A lot of us fell for CLAs when they were new and shiny. By now we've all seen way too many examples of people getting screwed by them. Fool me once, fool me twice... https://drewdevault.com/2023/07/04/Dont-sign-a-CLA-2.html
Using artificial pijul dependency arcs as CLA acknowledgements is certainly cute. But frankly, for legal matters, something that can't be misinterpreted like a `Developer-Certificate-of-Origin:` header is probably a better idea. By the way, have you noticed that `pijul git` import loses some of the git headers, like `Committer` and `CommitterDate`? Also, importing a large repo has exposed what appears to be some significantly superlogarithmic-time behaviors in `pijul record`.
> in the case of an evolution of the license
I think you should try to let go of the idea of "evolving the license" of an open source project that invites contributions.
If you want to go the sqlite route that is absolutely fine; honestly pijul is one of the few pieces of software that is (after accounting for younger age) on the same level of sophistication as sqlite. Just explain that your project, like sqlite, is open source but not soliciting contributions.
I think that with the CLA requirement you have effectively made this choice -- but in the way which maximizes the number of people annoyed: both the people who get triggered by any mention of the GNU project as well as the people who support its goals! This is quite a neat trick to pull off, although I fear it was unintentional.
> like applying linter fixes without understanding any of the code
Yeah I saw that PR, which was obnoxious for other reasons as well. Bravo to you and felix91gr for being so polite in your responses.