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

DroidBench OSS license #40

Open
ericbodden opened this issue Jun 11, 2021 · 8 comments
Open

DroidBench OSS license #40

ericbodden opened this issue Jun 11, 2021 · 8 comments

Comments

@ericbodden
Copy link
Member

Hi all.

Some of our industry partners would like to use DroidBench but currently are reluctant to do so due to a missing license. May I suggest to add one? I would suggest a liberal license, such as MIT or BSD.

Who outside Fraunhofer / TU Darmstadt / UPB contributed to DroidBench? Is there anybody else who'd need to consent?

@ericbodden
Copy link
Member Author

/cc @StevenArzt @srasthofer @linghuiluo

@linghuiluo
Copy link
Member

@ericbodden DroidBench should at-least-partially use GPL v2, since DroidBench seems to include DroidSafe, which is GPL v2:
https://github.com/MIT-PAC/droidsafe-src/blob/master/licenses.txt

@ericbodden
Copy link
Member Author

That would be bad, GPL would be no option for most commercial users, I think. What do we use DroidSafe for?

@linghuiluo
Copy link
Member

@ericbodden According to the acknowledgment:

  • 40 apps were contributed by The DroidSafe Team at MIT http://mit-pac.github.io/droidsafe-src/
  • Some inter-component and inter-application test cases were contributed by Li Li from the University of Luxembourg

@StevenArzt
Copy link
Member

That's a tricky one. When a project has a proper license, it usually (GPL, LGPL, Eclipse, etc.) defines that derived works are allowed, but only under the condition that the derived work is made available under the same license. In this case, we did not define any such provisions.

Nevertheless, I'm quite sure we can rule out GPL. The DroidSafe team contributed code to DroidBench, but in their contribution (correct me if I'm wrong), they never mentioned that they contribute under the conditions of the GPL, nor do the code files contain any reference to the GPL. You can't just implicitly assume a license. Even if they choose to publish under GPL in one channel (their own web site / repository), that doesn't mean that GPL applies to all channels (think of e.g., MySQL GPL vs. MySQL commercial license - same product, two licenses. If you pay, you get a different license).

Sadly, that doesn't make things easier. Since we host on Github, their terms apply. See the Github License Help:

You're under no obligation to choose a license. However, without a license, the default copyright laws apply, meaning that you retain all rights to your source code and no one may reproduce, distribute, or create derivative works from your work.
If you publish your source code in a public repository on GitHub, according to the Terms of Service, other users of GitHub have the right to view and fork your repository.

Let's dive deeper into Github's Terms of Service:

If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking). You may grant further rights if you adopt a license. If you are uploading Content you did not create or own, you are responsible for ensuring that the Content you upload is licensed under terms that grant these permissions to other GitHub Users.
Whenever you add Content to a repository containing notice of a license, you license that Content under the same terms, and you agree that you have the right to license that Content under those terms. If you have a separate agreement to license that Content under different terms, such as a contributor license agreement, that agreement will supersede.

Isn't this just how it works already? Yep. This is widely accepted as the norm in the open-source community; it's commonly referred to by the shorthand "inbound=outbound". We're just making it explicit.

The last paragraph is essentially what I wrote above about contributor licenses. Still, we don't have a license file and are stuck with the default coypright laws. I'll ask our institute's lawyer about his opinion, he's normally quite eager to help.

@ericbodden
Copy link
Member Author

Thanks Steven! Yet, we could also just ask the contributors whether they would be okay to licence all this under a permissive licence. Might be simpler than dealing with lawyers.

@StevenArzt
Copy link
Member

Here's the list of contributors:

  • Steven Arzt (TU Darmstadt and Fraunhofer SIT)
  • Siegfried Rasthofer (TU Darmstadt and Fraunhofer SIT)
  • Julian Schütte (Fraunhofer AISEC)
  • Eric Bodden (TU Darmstadt, Fraunhofer SIT, Fraunhofer IEM)
  • Fengguo Wei (Google)
  • William Klieber (Carnegie Mellon University)
  • Li Li (University of Luxembourg)
  • Christian Fritz (Bachelor Student)

Officially, we would need to contact them all and have the respective institutions give us permission to choose a license. We do not need permission from the individual people, if the work was done as part of their employment. This could be a simple e-mail just for documentation purposes, but it needs to be done. The student has probably had a student contract back then, i.e., is part of his institution as well, right?

Fraunhofer should be fine, regardless of the institute.

@ericbodden Do you want to send around the e-mails and put me in CC so that we a copy of the documentation at SIT and at IEM? Afterwards, we can change the license on Github.

@cfritz
Copy link
Contributor

cfritz commented Jun 17, 2021

Actually, I was a Master Student and it was the content of my Master Thesis - I don't remember a student contract. But I trust your judgement and I'm okay with any license you suggest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants