Closed phillxnet closed 1 year ago
FroggyFlox
commented
1 year ago Given that when folks use Rockstor in it's fully working, installed, variant it is comprised of both rockstor-core and rockstor-jslibs we are obliged to reflect this fact by referencing all licenses involved.
Shouldn't rockons-registry also be included there? It'll probably won't change the licenses listed but we may still need to list it.
phillxnet
commented
1 year ago @FroggyFlox
Shouldn't rockons-registry also be included there? It'll probably won't change the licenses listed but we may still need to list it.
Agreed, in part. But it's not part of what is included in the "rockstor" app. And is of course optional. And we link to the upstream of each project as we go. As-is the rockon-registry is "GNU Affero General Public License v3.0" from: https://github.com/rockstor/rockon-registry/blob/master/LICENSE But again it's not part of the rockstor package 'as-such' from the get-go. Maybe we have a header notice within the Rock-ons Web-UI that use of the Rock-ons repository (again optional) is under the SPDX defined AGPL-3.0-only as we don't (yet) stipulate the "or any later version" from what I can tell anywhere. I.e. that license file was added in a pr that references the following forum announcement on the introduction of Rock-ons: https://forum.rockstor.com/t/next-phase-of-rock-on-framework-improvements/417
So in short we wouldn't add all rock-on (e.g. Plex associated) licenses to our package, and we dont 'bundle' into the 'rockstor' package the Rock-ons repo, or any definitions from it. So I'm leaning towards a Web-UI notice and as you intimate an explanation on the differing license for the Rock-on definitions themselves (i.e. we have no other AGPL-3.0-only elements) to this issue.
How does that sound? I.e. I don't thing we need to add AGPL-3.0-only to our package license as there is nothing in there that uses that license that we distribute as part of that package. But yes we do pull in the definitions as part of an optional element of the packages' function, as we also pull-in any code within any of the associated Rock-ons themselves. In the later case we link to each Rock-on upstream to avail folks of the associated license of each project. So likewise we should similarly avail folks of the info that using the Rock-ons function involves retrieving AGPL-3.0-only licenesed definitions: ergo the Web-UI suggestion.
But all-in we are still good here as AGPL-3.0-only is still both FSF Free/Libre, & OSI approved according to: SPDX License List
Thanks for contributing to this issues discussion by the way. I'm super keen to get this all straightened out and as clear and up-front as possible. It can do no harm to do so but considerable harm to be lackadaisical on this front.
phillxnet
commented
1 year ago @FroggyFlox linking to a related issue in rockstor-core regarding our overall licensing that already includes a reference to our Rock-ons, but where I propose that we extend this to reference also our jslibs. "Expand README.md to include recent jslibs license clarifications.": https://github.com/rockstor/rockstor-core/issues/2489
We have more recently audited our jslibs repo (rockstor-jslibs) to include a full breakdown of all associated licenses and expressed them in the newly added README.md file in that repository according to SPDX License List standards. This specification has also now been expressed in our in-development (testing branch) Poetry based build system via the pyproject.toml file update in: https://github.com/rockstor/rockstor-core/pull/2449 where we summarise our respective rockstor-core and rockstor-jslibs licenses in SPDX compliant terms as:
Given that when folks use Rockstor in it's fully working, installed, variant it is comprised of both rockstor-core and rockstor-jslibs we are obliged to reflect this fact by referencing all licenses involved. As such it is proposed that we update our user facing docs in areas such as: https://rockstor.com/docs/interface/system/update_channels.html to reflect this fact and emphasise that all licenses referenced are: "... both FSF Free/Libre, & OSI approved according to: SPDX License List" as we do in the above referenced README.md in our rockstor-jslibs repo.
We likely have other references within our docs that should similarly be updated, depending on the actual number of references we may want to create instead a centralised reference where we can more easily express the exact breakdown of all components involved, however we do already have this in-place within our repositories. And the gist of it is that we have two repos that are, respectively, single licensed (rockstor-core) and mixed-licensed (rockstor-jslibs). Hence the above SPDX formatting regarding bracketing and the embedded use of the "AND" directive.