Skip to content
This repository has been archived by the owner on Jan 31, 2024. It is now read-only.

Double check licensing #67

Open
OndrejMarsalek opened this issue Jun 19, 2015 · 10 comments
Open

Double check licensing #67

OndrejMarsalek opened this issue Jun 19, 2015 · 10 comments
Assignees
Milestone

Comments

@OndrejMarsalek
Copy link
Collaborator

Let us double check that a dual GPL and MIT license is how we want to release.

The beginning of the accepted answer below suggests that having GPL allows derivative work to also use GPL, which is not possible with MIT.

http://programmers.stackexchange.com/questions/139663/confusion-about-dual-license-mit-gpl-javascript-for-use-on-my-website

@OndrejMarsalek OndrejMarsalek added this to the release-2.0 milestone Jun 19, 2015
@tomspur
Copy link
Collaborator

tomspur commented Jun 21, 2015

Hmm, I'm not so familiar with dual licenses, so I'd prefer to pick one instead. But I have no strong preference about the licensing other than having the socket/library for being used by the drivers as permissive as possible.
So I thought the socket part would be MIT and the rest GPL (see also #50).

@OndrejMarsalek
Copy link
Collaborator Author

Dual licensing permits whoever uses your code to pick which license they like, ignoring the other. There is also some way of telling if two licenses are "compatible" - MIT and GPL are.

Personally, I would prefer only GPL to make sure that any derivative work remains available. However, I have no reason to push for that if @ceriottm does not like it.

I agree that having the socket "adapter" available under something permissive is important. As far as I can tell, that includes the implementation of the client in the one C file, now possibly also in one Fortran file, and perhaps also one Python file. The Python client is now integrated in i-PI, but perhaps it would be a good idea to cut it out and have these three available somewhere separately (separate directory, same repository), under a sufficiently permissive license.

@OndrejMarsalek
Copy link
Collaborator Author

This brings up another issue, again possibly for later. The distribution of the patches might need some care as far as licensing goes. At this point, though, perhaps we don't need to include LAMMPS and CP2K patches anymore. If someone really wants the ones for older versions, the repository does not forget.

@ceriottm
Copy link
Collaborator

Agree to remove patches for cp2k and lammps.

On 21 June 2015 at 23:08, Ondrej Marsalek [email protected] wrote:

This brings up another issue, again possibly for later. The distribution
of the patches might need some care as far as licensing goes. At this
point, though, perhaps we don't need to include LAMMPS and CP2K patches
anymore. If someone really wants the ones for older versions, the
repository does not forget.


Reply to this email directly or view it on GitHub
#67 (comment).

@ceriottm
Copy link
Collaborator

ceriottm commented Feb 3, 2017

OK, in an effort to clean up archeological issues, @grhawk will remove all the patches files (that probably do not work anymore with recent versions of the codes, anyway). Re the dual license, I'm making an executive decision of keeping them both - I care that people use this, with whatever license and whatever purpose they like.

@mahrossi
Copy link
Collaborator

mahrossi commented Feb 3, 2017

All good.

@grhawk grhawk self-assigned this Feb 3, 2017
@grhawk
Copy link
Contributor

grhawk commented Feb 9, 2017

I assume that the idea is to keep the following (I found it in #50):

# This file is part of i-PI.
# i-PI Copyright (C) 2014-2015 i-PI developers
# See the "licenses" directory for full license information.

Should this be added also to non-source files? (example or stuff like that?)

@OndrejMarsalek
Copy link
Collaborator Author

MIT and GPL are compatible, so no problem there.

I would keep the three lines in source files only (all under ipi) and not clutter other, often rather short, files with them.

@OndrejMarsalek
Copy link
Collaborator Author

As for patches, only QE is actually left, we removed others earlier. It would be best to get it included upstream, of course. QE is GPL and therefore I am not sure the patch can actually be distributed under dual MIT/GPL licensing, though I suspect it cannot.

@grhawk
Copy link
Contributor

grhawk commented Feb 10, 2017

Hi,

The interface is already upstream with QE. I will check if all the files have the boilerplate and open a merge request

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

No branches or pull requests

5 participants