No license file?

[SimonBiggs]

Can I recommend Apache with the reason being that it covers code authors for issues such as negligence, which is an important clause to include within open source code in cases that may stand before Australian courts.

I go into more detail on this within the PyMedPhys documentation website:

https://pymedphys.com/getting-started/licensing.html#justification-for-the-inclusion-of-additional-terms

[SimonBiggs]

Or GitHub link if it helps:

https://github.com/pymedphys/pymedphys/blob/master/docs/getting-started/licensing.rst#justification-for-the-inclusion-of-additional-terms

[XertroV]

Thanks for the link

There is licensed code in this repo but it's fragmented among a few licenses. I built on some AWS provided cfn templates for example and they're Apache 2; there's also some MIT code.

Not sure of the best way to document it all but can't do a repo wide license without some work I think.

For this version we'll restrict usage too to prevent certain actors from using the stack as a whole. We can always change this later.

[SimonBiggs]

Okay, should I be making contributions I would want to contribute under the Apache, not the MIT. Given the sensitive nature of how this code would be used I would like to have the protections provided by the Apache license.

Is there a robust way to mark that all my contributions are released under an Apache license?

[XertroV]

Okay, should I be making contributions I would want to contribute under the Apache, not the MIT.

I'm curious to your reasoning here. I usually go with MIT because it's highly unrestricted. What benefits do you see Apache 2.0 having? (Edit: just noticed you mentioned some above. I also read some of the post you linked back in May but haven't gone through it deeply or recently)

Is there a robust way to mark that all my contributions are released under an Apache license?

So a license header on each file is sufficient I think, particularly if it includes (c) SimonBiggs, Flux Developers, 2019 type thing on it.

example: https://github.com/voteflux/voting-alpha/blob/master/stack/flux-securevote-voting-stack.yaml - this is modified from the AWS template, and while there's a lot of changes I figured it's just easier to keep it Apache2 whenever it touches other stuff that's Apache2.

If you wanted to contribute to a part that wasn't generally under Apache2 I'd go with a new file and then very minimal contributions to other files to integrate.

I actually have no idea if this is sufficient, I just guess it is. From my intuition it should be fine. We should mention in a LICENSE file that different parts of the work are released under different licenses, and include any mandatory short descriptions and link to licenses.

One reason I think this approach is okay is that it's v similar to software that's distributed with libraries that are under different licenses. There's no reason I can think of that there is any particular reason the repository needs to be under one license (or, rather, all files in a particular state in the git history)

[BenBallingall]

Okay, should I be making contributions I would want to contribute under the Apache, not the MIT. Given the sensitive nature of how this code would be used I would like to have the protections provided by the Apache license.

Is there a robust way to mark that all my contributions are released under an Apache license?

hey,
just so you're aware, this discussion is up anew over at: voteflux/digipol#7

this is in regards essentially a tech demo we're hoping to release for free us to Australians.
might be interesting to you.