> On Jan 10, 2021, at 4:06 PM, Balint Reczey <balint.rec...@canonical.com> > wrote: > > On Sun, Jan 10, 2021 at 8:41 PM Bastian Blank <wa...@debian.org> wrote: >> >> Moin >> >> On Sun, Jan 10, 2021 at 08:20:33PM +0100, Balint Reczey wrote: >>> I'm not a fan of CLAs either, but as I understand upstream requiring a >>> CLA is not a blocker for compression libraries. >> >> Well, it means that the library might get incompatible with upstream, >> because upstream will refuse patches. > > I'm not sure if I miss something, but I don't see the strict connection. > > The current upstream requires CLA, but if they make an incompatible > change that they refuse to revert, their current license allows > forking the project and fixing it (with or without requiring a > different CLA). This is why requiring a _license_ that allows forking > makes sense. > > We have also seen cases where projects refused to take patches even > though they did not require a CLA, thus not having a CLA is not a > guarantee for taking patches. > > I'm also willing to sign the CLA and propose a fix if needed. > > I agree that the CLA is not comfortable, but is hardly a blocker. > > Cheers, > Balint
Upstream is, and has been since release, very active. If there are patches that you need upstreamed, but can’t because of the CLA, you can open an issue we can solve the problem upstream. Best, Nick > -- > Balint Reczey > Ubuntu & Debian Developer > -- > I've closed #929715 before sending this email to debian-devel. > https://balintreczey.hu/blog/my-debian-devel-pledge/
