search

haiwen / seafile

High performance file syncing and sharing, with also Markdown WYSIWYG editing, Wiki, file label and other knowledge management features.
http://seafile.com/
Other
12.25k stars 1.54k forks source link

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

Closed abartlet closed 7 years ago

abartlet commented 10 years ago

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: /*

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 commented 10 years ago

@killing

oerdnj commented 10 years ago

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 10 years ago

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

freeplant commented 10 years ago

Hi @oerdnj Can changing to GPLv2 solve the issue?

abartlet commented 10 years ago

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

freeplant commented 10 years ago

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 10 years ago

@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, ...).

yol commented 10 years ago

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 :)

ghost commented 10 years ago

Hi all,

Affected files known to us are: GPLv2:

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!

freeplant commented 10 years ago

@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.

ghost commented 10 years ago

@freeplant got it

ghost commented 10 years ago

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.

killing commented 10 years ago

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.

ghost commented 10 years ago

it's fine for me to switch to GPLv2.

oerdnj commented 10 years ago

@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 10 years ago

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 10 years ago

@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 10 years ago

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).

freeplant commented 10 years ago

@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 10 years ago

@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 9 years ago

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.

killing commented 9 years ago

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

killing commented 9 years ago

Hi everyone,

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

Seafile:

Ccnet:

LibSearpc:

Any feedback is welcomed.

abartlet commented 9 years ago

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

killing commented 9 years ago

@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:

oerdnj commented 9 years ago

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.

killing commented 9 years ago

@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.

openpaul commented 8 years ago

@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.

killing commented 8 years ago

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

oerdnj commented 8 years ago

@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 8 years ago

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 8 years ago

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

oerdnj commented 8 years ago

@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.

killing commented 8 years ago

@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 8 years ago

@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.

adamries commented 8 years ago

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.)
geor-g commented 8 years ago

@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!

killing commented 7 years ago

@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 7 years ago

@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.

killing commented 7 years ago

@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 7 years ago

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

freeplant commented 7 years ago

The licenses are cleaned.

tildeslash commented 6 years ago

In the new project, we completely replaced libzdb with our own code

This is a stretch, isn't it? As far as I can see you have shuffled around some code, but based everything on libzdb code and structure. This is morally objectionable at least.