Copyright concerns on seafile (important for debian package) #666

Closed
abartlet opened this Issue Jun 2, 2014 · 42 comments

Projects

None yet
abartlet commented Jun 2, 2014

G'Day,

In my work for Catalyst IT, I've been looking at why seafile isn't yet
packaged for debian, and so I've been investigating the code to do some
due diligence on licensing.

The biggest issue is the mismatch between GPLv2 and GPLv3 licences. For
example, common/bitfield.c:
/*

  • This file Copyright (C) 2009-2010 Mnemosyne LLC
    *
  • This file is licensed by the GPL version 2. Works owned by the
  • Transmission project are granted a special exemption to clause 2(b)
  • so that the bulk of its code can remain under the MIT license.
  • This exemption does not extend to derived works not owned by
  • the Transmission project.
    *
  • $Id: utils.c 8686 2009-06-14 01:01:46Z charles $
    */

There are other more subtle examples, as common/index/index.c (and a
number of other files) is copied from GIT, which is GPLv2-only. It may well be possible to get an exception to get a GPLv2+ and openssl licence exception for this file from Linus, but if you take that path that needs to be done explicitly and clearly documented.

(Other examples, such as the common/avl/avl.c code just need
debian/copyright updated).

Oh, and this will cause problems with the incompatbility of GPLv2 and
GPLv3 (it's a pity, as it is 'just' a header file, this will still cause trouble):

Files: net/common/list.h
Copyright: 1991-2012 Linus Torvalds and many others
License: GPL-2

It would also be useful, I think, to get a better understanding of the history of the whole codebase, as it seems to be written in a number of different styles (some using glib heavily, others not at all, for example). It would be helpful to have clarified if other parts are also an aggregation of software from other places, and if so, a clear statement on the licence they were obtained under.

Seafile seems like great bit of software, and if we could get these
things resolved.

Thanks,

@freeplant freeplant added the bug label Jun 3, 2014
oerdnj commented Jul 14, 2014

Please resolve the licensing issues. The seafile binaries are in violation of the license and cannot be legally distributed.

I understand you wanted to have your work under a free license, but this is not something that could be taken lightly and it needs to be resolved, or you need to stop distributing the seafile binaries and this would be a real shame, since seafile is a great piece of free software.

oerdnj commented Jul 14, 2014

e.g. This is not just important for Debian, it's important to anybody who is distributing seafile including the authors.

Owner

Hi @oerdnj
Can changing to GPLv2 solve the issue?

On Wed, 2014-07-16 at 21:06 -0700, Daniel Pan wrote:

Hi @oerdnj
Can changing to GPLv2 solve the issue?

Changing the licence requires that you get permission from every
contributor (or the holder of the copyright for the work by that
contributor), preferably in writing.

Andrew Bartlett

Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba

Owner

Hi,

Since the code we copied from GIT is modified a lot and many parts are not used at all. We will delete the code and rewrite a new one.

oerdnj commented Jul 17, 2014

@abartlet @freeplant I the seafile team is the only author of GPLv3ed code that might work. But you must be sure that you had no other contributors, or have all those contributors to agree.

Also you would have to relicense whole codebase of seafile to GPLv2 since linking GPLv3 libraries with GPLv2 creates same problem.

For bitfield.c you can ask the copyright authors whether the allow GPLv2+ and thus use GPLv3. But that might be problematic since Mnemosyne LLC has closed operations in 2009.

Rewritting the GPLv2 code seems to be the best option at the moment.

Also please same license checks in the underlying libraries (searpc, ccnet, ...).

Hi,
I am maintaining the fedora/rpm binary packages of seafile.
Please do fix this as soon as possible as I will be forced to take down the rpms otherwise.
I really appreciate your work and it would be a pity to remove it because of this :)

Contributor

Hi all,

Affected files known to us are:
GPLv2:

  • STATUS: unknown FILE: net/common/list.h
  • STATUS: waiting for review FILE: common/bitfield.c
  • STATUS: waiting for review #745 FILE: common/avl/avl.c
  • STATUS: unknown FILE: common/index/index.c

We're making progress to cleaning up those code or replace them with GPLv3-compatible code.

What's more, any effort to solve this license issue is welcome!

Owner

@Chilledheart net/common/list.h can be deleted. It is not used now. common/avl/avl.c can be replaced by a hashtable. Let's first remove these two.

Contributor

@freeplant got it

Contributor

Hi @abartlet @freeplant @oerdnj

I looked into the latest version of bitfield.c shipped with libtransmission (or transmission), and found out has changed its license to dual license (both of GPLv2 and GPLv3 are allowed) since Jan 2014.

/*
* This file Copyright (C) 2008-2014 Mnemosyne LLC
*
* It may be used under the GNU GPL versions 2 or 3
* or any future license endorsed by Mnemosyne LLC.
*
* $Id$
*/

The authors announced their changes of license in their release note:

Licensing change: the GNU GPLv2 code can now be used under GNU GPL v2 or v3

We might just pick this very version of bitfield.c for seafile.
Look for further reviews and comments.

  • screenshot
    screen
Owner
killing commented Jul 23, 2014

I've reviewed the codebase. It's very hard to rewrite the code that we borrowed from Git. So we decide to change the license to GPLv2. That seems to be the easiest solution. We'll contact other contributors to the project. Since currently no substantial outside contribution was made to Seafile, this issue should be easy to settle.

Contributor

it's fine for me to switch to GPLv2.

oerdnj commented Jul 23, 2014

@killing Just remember you need to switch also every component of seafile (ccnet, libsearpc) and you cannot also link to any external library under GPLv3.

alfh commented Jul 24, 2014

Note that libzdb, db library used in seafil, is GPLv3, https://github.com/haiwen/libzdb, from what I can see.
The upstream repo for it is at https://bitbucket.org/tildeslash/libzdb.

Alf

oerdnj commented Jul 24, 2014

@alfh @killing That basically means that switching to GPLv2 won't help you. And you either need ask the git people if they can relicence the parts re-used from git to GPLv2+ (but I wouldn't hold my breath for that), or you really will have to rewrite those parts.

oerdnj commented Jul 24, 2014

Same for OpenSSL exception - you would have to get the git authors to grant you that exception (or just use GnuTLS instead of OpenSSL, that would make your life easier).

Owner

@alfh We have got libzdb author's permission to use the library in Seafile with license GPLv2. So the only thing left is OpenSSL.

I just wonder: the files we copied from GIT should permit the use of OpenSSL, since GIT links with OpenSSL too.

alfh commented Jul 25, 2014

@freeplant Note that there exists a https://github.com/mverbert/libzdb, which is a fork of the bitbucket repo of libzdb. So you should probably change your fork of libzdb to reference that github repo. THe libzdb author will then hopeful shortly commit a change to the COPYING file in the upstream libzdb.

oerdnj commented Dec 12, 2014

Any progress here? It's quite disappointing to see a new release of seafile, that's getting distributed even when you know it's not legally possible to do so. How do you expect the proprietary world to adhere to the open-source licenses when the open-source world don't do it itself.

Owner
killing commented Dec 13, 2014

@oerdnj Here is the current unresolved issues and their possible solutions:

  • libzdb: This library is only linked to the server. And the server doesn't use git's code. So this becomes a non-issue.
  • openssl exception: We'll add an exception to our code. The only remaining issue is git's code.
  • git code: The easiest solution is switching to GPL v2. The unresolved issue is whether git's code can link with openssl. I asked in their mailing list. But no one replies to me. I searched git's source code. But I can't even find an exception clause for openssl in it. Although git obviously links with openssl (to calculate sha1). Optimistically I can assume they just don't care about openssl either or implicitly allows linking with it. Another solution is to take the effort to remove git code from Seafile. This will break compatibility to libraries created before 3.0 version.
Owner
killing commented May 28, 2015

Hi everyone,

We've finished the clean up of copyright issues in all Seafile components. Here is a summary:

Seafile:

  • All third-party source code with license issue have been removed.
  • For the client, to be compatible with Git source code, we change Seafile project's license to GPLv2
  • Add OpenSSL exception to allow link with it. Since Git itself also links with OpenSSL, the copied over source code implicitly agrees to link with OpenSSL.
  • libzdb: It only affects the server side. We have got a written agreement from libzdb author to allow Seafile to link with it.

Ccnet:

  • All third-party source code with license issue have been removed.
  • It's released under GPL. It's library allows GPLv2 or v3 to link.

LibSearpc:

  • Released under LGPL, no third party code.

Any feedback is welcomed.

@freeplant freeplant removed the bug label May 28, 2015

On Thu, 2015-05-28 at 05:11 -0700, Jiaqiang Xu wrote:

Hi everyone,

We've finished the clean up of copyright issues in all Seafile
components. Here is a summary:

Seafile:

  * All third-party source code with license issue have been
    removed.
  * For the client, to be compatible with Git source code, we
    change Seafile project's license to GPLv2
  * Add OpenSSL exception to allow link with it. Since Git itself
    also links with OpenSSL, the copied over source code
    implicitly agrees to link with OpenSSL.

Thank you so much for putting so much effort into solving this issue.
However, I do have one concern about this part, because at least on my
system, I don't see the evidence that GIT links with OpenSSL.

  * libzdb: It only affects the server side. We have got a written
    agreement from libzdb author to allow Seafile to link with it.

Thanks. Make sure this is noted well so that it can be easily found by
an auditor in the future.

Ccnet:

  * All third-party source code with license issue have been
    removed.
  * It's released under GPL. It's library allows GPLv2 or v3 to
    link.

LibSearpc:

  * Released under LGPL, no third party code.

Any feedback is welcomed.

I will get back to you when I've checked the details in the git repo,
but it seems for now the major issue would be the OpenSSL thing. These
two links may help give you the background, in particular Debian takes a
hard line on this, and it would be sad to get this close, but not
actually meet debian's hard line on this item.

https://people.gnome.org/~markmc/openssl-and-the-gpl.html

https://lists.debian.org/debian-legal/2002/10/msg00113.html

Have you tried asking Linus about re-licensing, either for the OpenSSL
exception or GPLv3-plus (and probably an OpenSSL exception just to be
sure)?

Thanks,

Andrew Bartlett

Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba

Owner
killing commented May 31, 2015

@abartlet Yup, Git does links with Openssl. But it seems Linus doesn't think he has to make an exception for linking with it. There is an early discussion about this: http://article.gmane.org/gmane.comp.version-control.git/507

That said, I think linking with Openssl is not generally a copyright issue for Seafile, unless we want to get into Debian. Now there are 3 ways for us if want to do that:

  • Support GnuTLS library. However I doubt whether this would actually solve the problem. We use libcurl, which comes from the distribution. The libcurl comes with the OS usually links with OpenSSL. That means we indirectly links with OpenSSL!
  • Ask the Git source code authors for exception. I'll have a look. But it seems quite impractical since there are already too many authors for Git, even though we only use 2-3 files.
  • Don't try to get into Debian's official repository. Provide a PPA or similiar.
oerdnj commented Jun 4, 2015

Debian's git (the binary package) doesn't link with OpenSSL and it calls configure with NO_OPENSSL=1 and thus git uses bundled SHA1 and doesn't support IMAPS in git imap-send command. This was done for exactly this reason - a missing exception for OpenSSL in the license.

If you only use libcurl and don't link with libssl directly, you can use libcurl4-gnutls-dev package to avoid indirect linking to OpenSSL, so in fact linking with GnuTLS will solve the problem.

Owner
killing commented Jun 5, 2015

@oerdnj Thank you for clarification. I think then once we support GnuTLS, it should be ready to get into Debian. However due to a limitation of libcurl, support for self-signed certificate will not be as good as the version linked with OpenSSL. The user has to install the certificate into system CA store so that https works.

@killing the use of self signed certs should go down anyhow now, as we have let's encrypt (https://letsencrypt.org/) up and coming for our rescue.
So I think maybe this can be seen as a minor problem.

Owner
killing commented Dec 31, 2015

@openpaul Thank you for the tips. We'll wait until Let's Encrypt become more mature.

oerdnj commented Apr 6, 2016 edited

@killing @abartlet

Don't try to get into Debian's official repository. Provide a PPA or similiar.

This is so wrong on so many levels. You should not be violating GPL. You should not be using other's people (Linus's) work if you are not willing to adhere to the licensing terms. You are running business on top of violating git's GPL-2-only license and this feels so so bad. While you might think "hey, it's free, so what", just wait until somebody else will violate your rights to work you did...

The only honorable option I see is to drop the files you took from git and write a clean room replacement and then fix the licensing back to GPL-3+.

Other problem: ccnet is still licensed under GPL-3+ and thus it cannot be linked with seafile that is GPL-2-only.

We have got libzdb author's permission to use the library in Seafile with license GPLv2.

The libzdb author would have to give same permission to everybody, not just you. That helps you to not violate libzdb license, but for the software to be really free (as in DFSG-free), everybody else should be able to benefit from such exception even if they fork the software and built den of the evil overlord with it.

hydrandt commented Apr 6, 2016

It would be great if the licencing issues got finally resolved. @oerdnj I would be happy to help with the packaging once it is possible to include it in Debian.

Ultra2D commented Apr 6, 2016

Also, Let's Encrypt should be mature enough now I think?

oerdnj commented May 4, 2016

@hydrandt I have the packages almost ready, but I am not going to help distribute the software that violates original licenses so blatantly for almost two years after the first notice.

Owner
killing commented May 9, 2016

@oerdnj I agree with you opinion. The reason why we don't remove the code from git for long time is backward compatibility. Syncing old libraries (created before 3.0 version) relies on the git code. And that code is too tricky (and in my opinion not quite well written) to replicate. Now that most of our users use only new libraries and there is a way to convert old library format to new format (https://forum.seafile-server.org/t/migration-of-old-library-format-to-the-new-library-format/2094). I think it's okay to remove that old support.

oerdnj commented May 9, 2016

@killing ok, let me know, when you finish the removal. I'll check the licensing after that again and perhaps it could be finally packaged into Debian.

Hi, I've stumbled upon this discussion and am a bit puzzled as to Seafile's licensing status:

  1. Does Seafile still contain git code under GPL?
  2. Does Seafile contain other 3rd party code under GPL (e.g. libzdb)?
    If so, how is it possible to (legally) distribute a "Seafile Pro Edition" under proprietary terms? After all isn't the GPL's sole raison d'être to prevent such a situation? Just wondering...
    (Sorry if this is not the right place to ask.)
ge-fa commented Oct 10, 2016

@killing I would be more than happy to see seafile packaged in Debian. Could you clarify / elaborate on the current state of this issue? Any support and / or help needed? Thanks!

Owner
killing commented Nov 13, 2016

@ge-fa Our current strategy for getting the seafile client into Debian is that, we'll allow using GNUTLS along side OpenSSL. I think we'll have time to handle this recently. I'll keep you noticed.

oerdnj commented Nov 14, 2016

@killing This won't help, you still have the problem with libzdb being GPL3+ and you relicensed seafile to GPL-2-only. And this is still a showstopper, no matter what deal you have with libzdb author.

Owner
killing commented Nov 14, 2016 edited

@oerdnj The situation has change much since the last discussion. We have separated server code out of the client code (please find the new project https://github.com/haiwen/seafile-server). Since 6.0 version, the server is built from the new project. In the new project, we completely replaced libzdb with our own code. And that server project is released in AGPLv3 (not relevant to the copyright issue though). The "seafile" project in this repository is only for building the sync client.
Hope this clarifies things.

hex-m commented Jan 22, 2017

It seems like at least the client is going to be in Debian. https://tracker.debian.org/pkg/seafile

Owner

The licenses are cleaned.

@freeplant freeplant closed this Feb 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment