| Summary: | net-misc/seafile: Possible copyright infringement / wrong license | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Kristian Fiskerstrand (RETIRED) <k_f> |
| Component: | Current packages | Assignee: | Licenses team <licenses> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | flow, gentoo, jstein, moschlar, proxy-maint |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.debian.org/928975 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Kristian Fiskerstrand (RETIRED)
2019-05-14 07:42:15 UTC
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 https://github.com/haiwen/seafile/issues/666 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. IIUC both net-misc/seafile and net-misc/seafile-client are part of the client code, and the versions in the tree don't contain any of the offending code. Closing for now. Still, I have an uneasy feeling about that upstream, see previous comments and links in there. |