Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Licensing issues #27

Closed
joepie91 opened this issue Jun 1, 2020 · 6 comments · Fixed by #28
Closed

Licensing issues #27

joepie91 opened this issue Jun 1, 2020 · 6 comments · Fixed by #28
Labels
bug Something isn't working

Comments

@joepie91
Copy link

joepie91 commented Jun 1, 2020

Bug Report

Hi,

It's good to see another homeserver project, but there seem to be some licensing issues with this project:

  • The original licensing headers including copyright statement have been removed and replaced with a new header that lists "Finogeeks Co., Ltd" as the copyright holder - but this code is clearly derived from the Dendrite codebase, and so the original copyright holder(s) should also be listed.
  • The code appears to have been relicensed from Apache 2.0 to AGPL3; I'm not sure if that's a valid license change, but even if it is, it should be stated that the parts originally from Dendrite are released under Apache 2.0.
  • The commit history has been squashed into a single "init" commit, which means that the more precise information about who contributed what changes (especially for outside contributors) was lost. This can be a copyright attribution problem.

Can you resolve and/or clarify these issues? Thanks!

(Edit: To clarify, I'm not a contributor to Dendrite, just someone from the Matrix community!)

@joepie91 joepie91 added the bug Something isn't working label Jun 1, 2020
@GenTang
Copy link
Contributor

GenTang commented Jun 1, 2020

Hi,

Thanks a lot for your issue.

Just as you mentioned in the bug report or in the README of the project. Ligase is derived from Dendrite in the beginning of 2018 and then has been developing by Finogeeks team.

As Dendrite use Apache 2.0 as license, when we decided to relicense the code, we treat the license as following:

  • If there is a license header in the script which means that it is derived from Dendrite, we just keep the original Apache 2.0 license, just like this example. We did some statistics, there is about 30% of code keeping original Apache 2.0 license.
  • If there is no license header in the script which implies that it is not derived from Dendrite, we put AGPL 3 license just like this example

Therefore our strategy of license is just as your suggestion (or requirement). However, for the example that you mentioned: original licensing headers, we lost the original header in our local branch (we checked carefully the git log, we still don't know why the header is missing). So we believed mistakenly that it is originated from Finogeeks team not Dendrite. We apologize for this mistake. We will develop a script to compare every file in Ligase to Dendrite. If there are some other mistakes, we will correct the license (It needs some time, we think).

@GenTang
Copy link
Contributor

GenTang commented Jun 1, 2020

For your third question (or suggestion), as the project will keep the original license for the code which derived from Dendrite, Maybe there is no copyright problem any more?
This is the first time that we do an open source project, we will consult other open source projects, or layers to see what we should do.

Hope that I answered your question. @joepie91


As the project is not open source during 2018-2020/05, the git history is a messy and contains some ugly code, we prefer to "squash" the git history (In fact we cannot expose these git history).

@joepie91
Copy link
Author

joepie91 commented Jun 1, 2020

  • If there is a license header in the script which means that it is derived from Dendrite, we just keep the original Apache 2.0 license, just like this example. We did some statistics, there is about 30% of code keeping original Apache 2.0 license.

  • If there is no license header in the script which implies that it is not derived from Dendrite, we put AGPL 3 license just like this example

I see. That makes sense.

We apologize for this mistake. We will develop a script to compare every file in Ligase to Dendrite. If there are some other mistakes, we will correct the license (It needs some time, we think).

👍

I would recommend reaching out to the Dendrite developers as well, they might be able to help in tracking down the mistakes.

For your third question (or suggestion), as the project will keep the original license for the code which derived from Dendrite, Maybe there is no copyright problem any more?

I think this depends on who made the contributions, and under what conditions. For example, employees of Vector Creations Ltd have probably signed a contract that transfers their copyright to the company for the work they do.

But if there are contributions from third parties not related to the company, and they did not explicitly sign an agreement to transfer the copyright, then those parties would need to be credited. They would normally be put in the license header, but if that was forgotten, then the git log would be the only place that records this.

In any case, the git log would tell people which specific code is owned by who, which is something that license headers cannot do to the same level of detail. I'm not sure how important that is legally, though.

As the project is not open source during 2018-2020/05, the git history is a messy and contains some ugly code, we prefer to "squash" the git history (In fact we cannot expose these git history).

As an open-source developer myself: I wouldn't worry too much about "ugly code". Everyone writes ugly code at some point, and that's fine, so long as it gets fixed and the end result is good!

Is the reason that you cannot expose the history because of things like credentials? If so, another solution is to fork the Dendrite repository at the original "forked commit", and keep its history intact, and then add all of your own changes on top of that as a single commit. That way all your own changes are squashed, but all of the Dendrite history is preserved.

One practical approach of doing that, would be to clone the Dendrite repository, check out the "forked commit", and then copy-paste all of the files from the Ligase repository into it. Anything that has changed since the forked Dendrite commit can then be committed as a single huge change (similar to the current 'init' commit). You can then force-push the new commit to this repository.

@GenTang
Copy link
Contributor

GenTang commented Jun 2, 2020

Is the reason that you cannot expose the history because of things like credentials? If so, another solution is to fork the Dendrite repository at the original "forked commit", and keep its history intact, and then add all of your own changes on top of that as a single commit. That way all your own changes are squashed, but all of the Dendrite history is preserved.

Exactly, it contains some credentials, we cannot expose it.

One practical approach of doing that, would be to clone the Dendrite repository, check out the "forked commit", and then copy-paste all of the files from the Ligase repository into it. Anything that has changed since the forked Dendrite commit can then be committed as a single huge change (similar to the current 'init' commit). You can then force-push the new commit to this repository.

Great idea! Thanks a lot for your advice, we will do this.

@GenTang
Copy link
Contributor

GenTang commented Jun 2, 2020

Git history is done

@joepie91
Copy link
Author

joepie91 commented Jun 5, 2020

Great, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants