[Pkg-privacy-maintainers] Do we want to add a fork of utls (ITP #954209)?

[Ana Custura]

Hi Ulrike and Cecylia,

Thank you for looking at this!

On 16/03/2020 18:12, Ulrike Uhlig wrote:

> If I understand correctly from a quick look, Yawning distributes his
> changes under GNU GPL, while uTLS upstream has a BSD 3-Clause license
> [https://github.com/refraction-networking/utls/blob/master/LICENSE].
>
> The BSD 3-Clause is in line with the Debian Free Software Guidelines
> (DFSG)[https://wiki.debian.org/DFSGLicenses#The_BSD-3-clause_License].
>
> From my understanding, in Debian packaging, licenses generally apply to
> files but it also seems possible (I never encountered such a case) to
> have several licenses for one file
> [https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-syntax].
> Maybe someone could confirm that this is accepted.
>
> I'm now unsure to what we referred to previously when saying that there
> might be licensing issues with Yawning's fork. It does not look like
> there are. Or am I missing something crucial here? If I don't, then to move forward, one would need to open an RFP or ITP
> (Intent to Package) bug on the Debian bugtracker and then package this
> fork of uTLS.
To sum up the concerns that came from looking at it last time:

golang-yawning-utls-dev is a fork of utls, which is itself a fork of the
golang tls library. This is a hard fork, any improvements cannot be
shipped upstream due to the difference in licensing that you've
identified. The upstream is very active - go has >1500 contributors,
uTLS has >50 contributors. The fork we want to package is maintained by
very few people, if I'm not mistaken, Yawning is the only core contributor.
I think there is a security implication here - if there is a security
advisory for the golang library, the Debian Security team needs to work
with the upstreams to apply security patches to it and all of its forks
in Debian, meaning this one too. If the delta from upstream increases
with every fork this could mean a lot of pain.

However, my understanding of the dynamics could be entirely wrong, so
let me know if I'm off the mark.

Sending this to the Debian Security team, to ask if they see any
problems here. Including the source link:
https://gitlab.com/yawning/utls and ITP:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954209

If we're all good, I'd be very happy to help with packaging or even
sponsoring this (I've recently completed the process to become DD, now
under review!).

>
> → actually that package was uploaded to mentors.debian.org and could go
> to experimental.
Happy to update this to the latest policy and reupload if this is
something we want to do.
>> Hey, I'm new to the debian packaging space but am happy to help out here.
Awesome, thank you for helping with this :)

Thank you all,

Ana

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-privacy-maintainers/attachments/20200403/0f84ecc0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-privacy-maintainers/attachments/20200403/0f84ecc0/attachment.sig>