-
Notifications
You must be signed in to change notification settings - Fork 3
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
Relicense under Apache-2.0. #56
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #56 +/- ##
==========================================
+ Coverage 93.83% 94.20% +0.37%
==========================================
Files 3 3
Lines 697 742 +45
==========================================
+ Hits 654 699 +45
Misses 43 43
Continue to review full report in Codecov by Sentry.
|
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.
Many of these comments apply to the other related PRs. I suggest getting one repo good to go then update others.
Files: *.md .gitignore .npmrc package.json test/.npmrc test/mocha/.eslintrc | ||
test/package.json .editorconfig .github/* test/static/*.html |
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.
- Is there a wildcard format that would be easier?
- Does the reuse linter check this for extra files? The
.eslintrc
files are.eslintrc.cjs
in this project and have license text. Don't need to be in this list. - How is a reader supposed to know to look at this obscure file for license info? If going all in on this meta info, is best practice to use direct comments and
.license
files where practical?
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.
- Is there a wildcard format that would be easier?
The danger of Files: *
is that it would apply to anything in the future also--which may not be the case (as with the logo you added to the core bedrock repo). So, being explicit (or somewhat explicit as with *.md
) seems better...if annoying at times.
The reuse helper tool does a good job of highlighting what's been missed, and those can be easily added to this list or in a new section for whatever license they're supposed to be under.
- Does the reuse linter check this for extra files? The
.eslintrc
files are.eslingrc.cjs
in this project and have license text. Don't need to be in this list.
So, when things appear in both list the reuse helper tool does throw an error. We can certainly be more consistent here.
- How is a reader supposed to know to look at this obscure file for license info? If going all in on this meta info, is best practice to use direct comments and
.license
files where practical?
Reader's of the REUSE spec would know/care to look, and we could explain that a bit in the readme's or an "OSS Policy" repo we could/should make.
I chose not to go with the .license
file option because of the "clutter" and concerns around needing to avoid them when bundling, etc. Happy to discuss using those instead, but I found a verbose .reuse/dep5
to be preferable.
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 had not heard of the REUSE spec until you started using it here. I suspect that is the case for most people. And none of them will look at a random .reuse
file since we are numb to tons of dot files we can ignore in every repo. Would you you look there for license info? I think it needs to be clear in docs, or somewhere, if a magic file is the official source of license info. It's also strange the dep5 file doesn't cover all the files, like I think it would in Debian.
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.
They're actually moving to a reuse.yaml
file, but that won't be much different for your concern. We can and should explain our OSS policy/process/compliance and mention it in the README's. However, any/all of this is going beyond (deliberately) the same statement/claim made in the LICENSE file--which people are familiar with.
The REUSE specification is one of many options for being thorough and explicit in stating ownership and licensing and it's one of the few that I've found that provides this capability along with the code--many others require storing claims elsewhere in a compliance database of some kind.
REUSE is standardized, has an active community, and is in use. It also fully supports creating SPDX Software Bill of Materials (SBOMs)--which is the real goal here.
Hopefully that explains the choice more. Happy to chat if you still have concerns.
README.md
Outdated
You can use Bedrock for non-commercial purposes such as self-study, research, | ||
personal projects, or for evaluation purposes. Many Bedrock libraries (including | ||
the core) are licensed as open source under the [BSD-3-Clause](LICENSE.md). However, | ||
some components use a custom non-commercial source available license: see the | ||
[Bedrock Non-Commercial License v1.0](https://github.com/digitalbazaar/bedrock/blob/main/LICENSES/LicenseRef-bedrock.md) for details. |
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'd reword this.
- Take out the intro text that, I think, was from guidance on using the
Bedrock-NC-1.0
license. - A
BSD-3-Clause
package should say this code is using theBSD-3-Clause
license, leave the understand of that to the license text itself, or any of the web resources on the topic. As written the text does not say what license this package is using. - Mention that some Bedrock modules use
BSD-3-Clause
but others use theBedrock-NC-1.0
license. I'd avoid the more subjective "many". - This text is claiming a license on the whole package, but this REUSE system is enforcing per-file and
.reuse/dep5
claims. Does this need to refer to REUSE or those somehow?
You can use Bedrock for non-commercial purposes such as self-study, research, | |
personal projects, or for evaluation purposes. Many Bedrock libraries (including | |
the core) are licensed as open source under the [BSD-3-Clause](LICENSE.md). However, | |
some components use a custom non-commercial source available license: see the | |
[Bedrock Non-Commercial License v1.0](https://github.com/digitalbazaar/bedrock/blob/main/LICENSES/LicenseRef-bedrock.md) for details. | |
This module, and some other Bedrock modules, are licensed under the | |
[BSD-3-Clause License](LICENSE.md). Note that some Bedrock modules | |
are under a non-commercial source available license. See the | |
[Bedrock Non-Commercial License v1.0](https://github.com/digitalbazaar/bedrock/blob/main/LICENSES/LicenseRef-bedrock.md) for details. |
Or if you prefer structure for the whole License section, and listing possible exceptions. I'm unsure if having the reference to the Bedrock License helps or confuses in these BSD modules. This is all getting verbose.
* [Bedrock][]:
* Copyright (c) 2011-2024 Digital Bazaar, Inc.
* This Bedrock module, unless otherwise noted:
* Copyright (c) 2013-2024 Digital Bazaar, Inc.
* [BSD 3-Clause License](LICENSE)
* See individual file comments, `*.license` files, and [.reuse/dep5](.reuse/dep5) for exceptions.
* Other Bedrock modules may be under other licenses including the source available
[Bedrock Non-Commercial License v1.0](https://github.com/digitalbazaar/bedrock/blob/main/LICENSES/LicenseRef-bedrock.md).
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.
Here's an attempt at a rework upstream: digitalbazaar/bedrock#117
If that looks good (at the root/trunk), then I can apply that approach here also.
README.md
Outdated
|
||
Bedrock and all Bedrock modules are: | ||
|
||
Copyright (c) 2011-2024 Digital Bazaar, Inc. |
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.
Git history for this module starts in 2013. Where did 2011 come from? I this this should be correct per-module and not copied for all Bedrock modules.
Copyright (c) 2011-2024 Digital Bazaar, Inc. | |
Copyright (c) 2013-2024 Digital Bazaar, Inc. |
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.
The plan in digitalbazaar/bedrock#117 is to remove this copyright line for the README as it's confusing and a pain to maintain.
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.
Reminder that this (and other changes?) need to be synced over.
LICENSE.md
Outdated
|
||
CONDITIONS | ||
========== | ||
Copyright (c) 2011-2024, Digital Bazaar, Inc. |
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.
Copyright (c) 2011-2024, Digital Bazaar, Inc. | |
Copyright (c) 2013-2024, Digital Bazaar, Inc. |
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.
Again, there's know way to know which is more correct. My assumption is that @dlongley had put code into Bedrock before he added it to git--based on these dates appearing in files from the beginning.
I tried to leave the dates I found intact to avoid needing to unearth history outside the reach of version control.
Not sure how these licenses interact. I'm guessing it'd be good to update the peer deps so a BSD release requires BSD deps. Doing that probably means releasing packages in order and updating the deps as you go. Is that a good plan? |
The core is BSD licensed (as of yesterday). Many other modules are also being released that way. A developer would only now need a Bedrock license when using a library that is not BSD licensed. That said, the non-commercial license does include name usage requirements--which would be lacking form these repos--so we'd need to provide additional clarity around the naming (or move to an OSS license that contains a similar restriction such as the Apache-2.0 license). |
c2ec3ef
to
efdabff
Compare
Co-authored-by: Dave Longley <dlongley@digitalbazaar.com>
Implements the REUSE v3.0 specification to license this repositories current files under the Apache-2.0 license.