Giters

haiwen / ccnet-server

Internal communication framework and user/group management for Seafile server

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

libccnet status in ccnet and ccnet-server repositories

niol opened this issue · comments

commented

Hi,

libccnet can be built from the ccnet-server and ccnet repositories, however it is nearly the same code. This split can lead to maintenance issues (such as bugfixes or new features not making it to one of the repositories, such as the recent ccnet_email_user_{get,set}_reference_id). It would be great if there was only one repository holding this code. It can be a new repository, or one of ccnet or ccnet-server.

However, there is a small licensing issue that may arise:

  • seafile (client) is licensed under the GPL-2 and thus cannot link to libccnet under the AGPL-3
  • seafile-server is licensed under the AGPL-3 and thus cannot link to libccnet under the GPL-2
  • libccnet is present in ccnet (GPL-2 with OpenSSL exception) and ccnet-server (AGPL-3 with OpenSSL exception) repositories, therefore I conclude that it is dual-licensed. Am I right? Can this be made explicit in the license files (I'll propose patches if this can help) ?

Thanks for reading.

commented

Just to reiterate for others: In https://forum.seafile.com/t/seafile-server-and-seafile-client-packaging-guidelines/662/10, it was suggested that the code from ccnet-server would be a valid substitute for ccnet, so one solution would be to just drop the ccnet repo altogether. (Maybe just having a ./configure switch for building server or client or both stuff.)

commented

ccnet is intended to be used by the client only, while ccnet-server is intended to be used by the server only. So when someone releases the software, there should be no licensing incompatibility. We mention that libccnet from ccnet-server can also be used with the client in the context that someone wants to build and install client and server in the same machine. This is technical, not from licensing perspective.

We're going to deprecate ccnet dependency in the upcoming 6.3 syncing client. Ccnet is currently only used for syncing libraries created before 3.0 servers. Because it uses TCP sockets to communicate with seaf-daemon (the syncing daemon), it prevents users from running multiple instances of syncing clients on Windows. So there would be no ccnet in the client in the future. By the way, the drive client doesn't rely on ccnet already.

commented

I think this bug is related to https://github.com/haiwen/seafile-server/issues/181
There is a different number of parameters for ccnet_get_groups_by_user function (ccnet-server vs ccnet).

Can you release it as a standalone share library instead and call it from both projects if required?

commented

This issue is no longer relevant since we've removed ccnet component from the client.