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

unclear license #1

Open
vapier opened this issue Jul 23, 2020 · 5 comments
Open

unclear license #1

vapier opened this issue Jul 23, 2020 · 5 comments

Comments

@vapier
Copy link

vapier commented Jul 23, 2020

the README says "BSD license", but that is ambiguous: there are 5 variants based on the number of clauses
https://en.wikipedia.org/wiki/BSD_licenses

please add a LICENSE file to the repo so it's clear which one exactly you want to use

@vaeth
Copy link
Owner

vaeth commented Jul 24, 2020

Thanks for the report. I clarified in the README.md which license I meant.

@vapier
Copy link
Author

vapier commented Jul 24, 2020

if it's not too annoying, having a dedicated "LICENSE" file makes tooling a lot easier. GH for example will detect & add a chip for the right license. automated source code scanners (which CrOS uses) looks for dedicated license files, especially when attribution is required in documentation/releases (which BSD usually requires). when the Copyright lines are smashed into source files, it's much harder to automatically & reliably extract.

@vaeth
Copy link
Owner

vaeth commented Jul 25, 2020

I see the argument, but I dislike adding a file to every archive which is longer than the whole source code.
Would re-licensing help? (From my non-lawyer POV, the artistic license or the MIT license would be same, and I am currently the only author.)

@vapier
Copy link
Author

vapier commented Jul 25, 2020

MIT has the same attribution requirements as BSD-2.
Artistic 2.0 does not have attribution requirements.
Apache 2.0 also does not have attribution requirements, and depending on what licensing model/aspects are important to you, that might be a good alternative to consider.

related, for the README & source files, i'd recommend adding SPDX-License-Identifier tags. those are succinct & clear which sounds like what you want. they help with automating compliance checking tools, although they don't help with automating attribution :/.

to be clear: i have no problem with any of these licenses, or the fact they require attribution in documentation, or if you wanted to use them. it's just that the current code structure in this repo is nigh impossible to automate, so anyone utilizing this package has to manually audit/enumerate it. i grok your pref to keep the checkout lean even if it's not the choice i would make.

vaeth added a commit that referenced this issue Jul 25, 2020
@vaeth
Copy link
Owner

vaeth commented Jul 25, 2020

Thank you very much for your remarks, and especially for the hint to the SPDX-License-Identifier tags which I was not aware of.
I added them now for this package and will in the course of time add them to my other packages as well.
For consistency, I will not change the license in the moment.

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

2 participants