As the maintainer of net-misc/seafile I would like to point you to the discussion on the debian-legal mailing list relating to this package: https://lists.debian.org/debian-legal/2019/05/msg00002.html
Please review the information provided and comment on its applicability to Gentoo.
I'd like to refer to my answer in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928975#17:
> Dear all,
> as maintainer of the Seafile client packages (libsearpc, seafile and
> seafile-client), I would like to thank Jan-Henrik for bringing this to
> our attention.
> There have already been such findings in the past, regarding some code
> taken from git, and the discussion regarding libzdb in the past, as you
> mentioned. I remember discussing the problems regarding linking to
> OpenSSL, too.
> However, all of the database related code is *only* contained in the
> Seafile server implementation (https://github.com/haiwen/seafile-server,
> RFP at #865830) and not in the Seafile client implementation
> (https://github.com/haiwen/seafile) that I have packaged for Debian.
and Gentoo. ;-)
> I disagree that this should serve as a reason for *not* including the
> client packages in the next Debian release.
and Gentoo. ;-)
> What do others think about that?
> I will however forward these findings to the developers at Seafile Ltd
> and ask them for a proper resolution.
I reopen after reading the ticket
Upstream was not very responsible about the license violation.
The "solutions" on the bug tracker are alarming.
We should either look into the files in a short audit, or tree clean the package.
There is a untraceable mix of licenses, forks and old, bundled libs in the upstream tree. Software like this can be very dangerous, if it is unmaintained in our tree. A look on the open bugs and the way license violations are handled motivates me rather to treeclean.
So, how are we going to proceed here? Reading the last comment of the linked Debian bug https://bugs.debian.org/928975#47 makes me cringe:
| I am very uncomfortable with having code in Debian whose upstream
| authors appear to have plagiarised some other people's software, and
| then obfuscated it, in order to evade copyright licensing. Who knows
| what other misleading practices they have engaged in, or may do in the
| future ?
| As a project, we do not have the resources to fully audit all the code
| we ingest from upstreams and redistribute to our users. We must rely
| on trust. That depends on the upstream being trustworthy.
To me it looks like the situation is everything else than resolved.