libquic license

[metze-samba]

The license of libquic is a bit unclear, the .c files say GPLv2, while the header says GPLv2+. So one would better assume it's GPLv2 only.

This makes it hard to use for others, Samba is GPLv3+.

Would it be possible to relicense libquic to be LGPLv2.1+ (the same as gnutls)? Or any other more liberal license?

[moritzbuhl]

I personally would be ok with any of the proposed license changes.

But from my experience using the quic lkm in curl and a http server, lots of projects don't benefit from this library because they already have some TLS abstractions and at <1KLoC, it is probably easier to integrate the QUIC related stuff into the existing code.

[metze-samba]

With https://github.com/lxin/quic/pull/33 I'll be able to use it in Samba, see https://gitlab.com/samba-team/samba/-/merge_requests/4019/diffs?commit_id=3aba724a3f1f668530998d8bf808235108a30bc7

But in near future I plan to have a copy of libquic under third_party/libquic in the samba tree in order to make it easier to use until it will be part of distributions.

MIT license like libngtcp2 might also be good.

[lxin]

@metze-samba The QUIC module is currently licensed under GPL-2.0+, which aligns with the upstream Linux kernel code. Initially, I aimed to keep the same license for libquic to maintain consistency. However, It seems that GPL-2.0+ is generally not ideal for libraries, I believe switching to LGPLv2.1+ (the same as gnutls), as you suggested, would be a better fit for libquic.

I'll update the license declarations accordingly:

modules/ : GPL-2.0+
libquic/ : LGPLv2.1+
tests/   : LGPLv2.1+

I'm glad to hear that you're planning to use libquic in Samba. That opens up more opportunities to refine and evolve the libquic API based on real use cases.

Thanks.

[metze-samba]

@metze-samba The QUIC module is currently licensed under GPL-2.0+, which aligns with the upstream Linux kernel code. Initially, I aimed to keep the same license for libquic to maintain consistency. However, It seems that GPL-2.0+ is generally not ideal for libraries, I believe switching to LGPLv2.1+ (the same as gnutls), as you suggested, would be a better fit for libquic.

I'll update the license declarations accordingly:

modules/ : GPL-2.0+
libquic/ : LGPLv2.1+
tests/   : LGPLv2.1+

I'm glad to hear that you're planning to use libquic in Samba. That opens up more opportunities to refine and evolve the libquic API based on real use cases.

It would be good to get that change soon, so I can move forward.

Thanks!

[lxin]

@metze-samba Feel free to review https://github.com/lxin/quic/pull/43

[lxin]

@metze-samba I'm drafting the cover letter for the QUIC module upstream submission. Would it be appropriate to mention Linux QUIC usage in Samba? If so, is there a public link I can reference?

Thanks.

[metze-samba]

@metze-samba I'm drafting the cover letter for the QUIC module upstream submission. Would it be appropriate to mention Linux QUIC usage in Samba? If so, is there a public link I can reference?

The main MR is this: https://gitlab.com/samba-team/samba/-/merge_requests/4019

It seems to function well so far, there only seems to be a latency problem on the server side, but I'll file a new issue for that later. On the client side (against a Windows Server 2025) I'm getting a lot more iops on a simple echo test compared to tcp. I haven't checked if the client and/or server tcp stack is the limiting factor here....

This is on top and introduces a quic_ko_wrapper.so based on ngtcp2, it can run on kernel udp sockets or socket_wrapper.so in order to do simulated testing without kernel support: https://gitlab.com/samba-team/samba/-/merge_requests/4035