-
-
Notifications
You must be signed in to change notification settings - Fork 27
Propose CFEP-21 license packages for static/header libraries #47
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
Open
carterbox
wants to merge
4
commits into
conda-forge:main
Choose a base branch
from
carterbox:license-packages
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,60 @@ | ||
|
|
||
| <table> | ||
| <tr><td> Title </td><td> Export license packages for static and header-only libraries </td> | ||
| <tr><td> Status </td><td> Proposed </td></tr> | ||
| <tr><td> Author(s) </td><td> Daniel Ching <carterbox@users.noreply.github.com></td></tr> | ||
| <tr><td> Created </td><td> Jul 9, 2022</td></tr> | ||
| <tr><td> Updated </td><td> Jul 25, 2022</td></tr> | ||
| <tr><td> Discussion </td><td> NA </td></tr> | ||
| <tr><td> Implementation </td><td> NA </td></tr> | ||
| </table> | ||
|
|
||
| ## Abstract | ||
|
|
||
| This CFEP proposes that header-only and static libraries should be required | ||
| to run_export an empty package (containing their license) called "{{ name | ||
| }}-license" in order to ensure/automate attribution and to satisfy the license | ||
| requirements. | ||
|
|
||
| ## Specification | ||
|
|
||
| Header-only or static library packages should include an output called | ||
| "{{ name }}-license" which is added as a run_export for the library. | ||
|
|
||
| ## Motivation | ||
|
|
||
| Attribution for header-only and static libraries on conda-forge is not well | ||
| enforced because unlike shared libraries which are also required to be | ||
| installed again at runtime (with license included), these libraries need manual | ||
| intervention to ensure that the license of the header-only or static library is | ||
| concatenated to the license metadata of the downstream library which uses it. | ||
| This should obviously be done and is easy to notice for static libraries (whose | ||
| names end in "-static"), but for header-only libraries it is less obvious | ||
| because the name of the library does not obviously mark the library as | ||
| header-only. | ||
|
|
||
| Libraries like Eigen and Pybind11 are commonly used, but probably not | ||
| attributed beyond their mention in the host section of the recipe. Mention in | ||
| the requirements section of a recipe probably does not meet the | ||
| licensing/attribution requirements. | ||
|
|
||
| ## Rationale | ||
|
|
||
| run_exports is the obvious way to deliver the license information into the | ||
| environment of downstream packages; this is already how the license information | ||
| is included for dynamically linked libraries. | ||
|
|
||
| "{{ name }}-license" matches the exisiting naming scheme for "{{ name }}-static" | ||
| "{{ name }}-includes". | ||
|
|
||
| ## FAQ | ||
|
|
||
| ### How does this affect current builds of packages? | ||
|
|
||
| It doesn't. The changes will slowly be implemented over time as packages and their | ||
| downstream packages are rebuilt with regular releases. Migrations are a tool | ||
| that could be used to if desired for certain packages. | ||
|
|
||
| ## Copyright | ||
|
|
||
| All CFEPs are explicitly [CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/). | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not all licenses require the distribution of the license when the code is distributed in binary form.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for pointing this out. Common licenses like BSD3 and MIT do require distribution of the notice and or license with the binary form though. My thought is that it is easier to require all packages to attribute, than to have reviewers check against a running list of which licenses require attribution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mmm, I think we should encourage people to be looking at and thinking about the licenses, rather than not. It shouldn't be hard to keep a list of licenses that do/don't have requirements, and if there are gray areas, I think we should be looking into them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we state that packages whose licenses require license file distribution must use a run export or other mechanism to do this.
Others are free to not. There is no reason for us to require more work from folks when the underlying package does not require it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a very good point, maintainers should understand the license of their packages, but then why keep a list of licenses that require attribution, that would discourage people from looking at the licenses because they would just look at the list.
As I stated, I think it is more (human) work overall to determine on a case-by-case basis whether a license requires attribution than to just export a license package for every header library. I also don't see any harm in attributing when it is not required.
As a compromise, I propose that header-only libraries without license packages are required to have a comment that the license does not require attribution. Otherwise, it is unclear whether the maintainers have considered this CFEP.