-
Notifications
You must be signed in to change notification settings - Fork 16
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
Metadata licenses should be required before adding new modules to ecosystem #19
Comments
So it's a license just for the meta file? We already state the addition of a dist to the ecosystem means the user allows redistribution of it: https://github.com/perl6/ecosystem#legal We can add to that paragraph whatever particular license describes the permission better. I don't see the point of adding yet another confusing tag users will be forgetting to add. As for naming any meta META file fields, I'd prefer this format instead of a "meta": {
"blah": "blah"
} AFAIK this problem space is well explored in Perl 5, so we should take a look. One thing brings to mind: versioning of the metafile spec. |
Yep it is for just the meta file. And yes it states that on the ecosystem legal page, but that is besides the point, since that cannot be confirmed by looking at the META file as to which license the META data is, and just seems like putting off this issue until later. I am curious how Perl handled this issue. |
I'm on my phone right now, but don't see meta license in the Perl 5 meta spec. They seem to have a bunch of fields that apply to the meta file (like version) we could put the license field in there. The CPAN::Meta dist has all the relevant info; thw ::Spec module in particular: https://metacpan.org/pod/CPAN::Meta::Spec |
So far I like this best: "meta": {
"license": "MIT"
} The Perl 5 meta has a meta-spec, and I feel if we used that it would not be clear that the license relates to the meta file itself and not to the META specification. |
Thinking more of it, perhaps we should spell out that this is a license for the META file. Unless you know better, it's possible to assume
Or your original proposal, but inside the meta key:
|
I like |
OK, back to this. I think I'm moving it to the problem-solving repo, because it looks more appropriate there now. |
<bikeshedding> |
I like this idea. Inside of having the hierarchy in the name, just making a new higher level for the meta file could be good. |
Since Perl 6 is a language for the future, and our ecosystem is not a permanent solution, we need to ensure that we have a metadata license category, and ensure that it is a permissive license which is suitable for redistribution by a wide variety of other projects.
See: https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sect-Quickstart-DesktopApps
From freedesktop.org:
Recommended metadata file contents
<metadata_license/>
The <metadata_license/> tag is indicating the content license that you are releasing the one metainfo file under. This is not typically the same as the project license. Omitting the license value can result in your data not being incorporated into the distribution metadata (so this is a required tag).
A permissive license ensures your data can be combined with arbitrary other data in one file, without license conflics (this means copyleft licenses like the GPL are not suitable as metadata license). Possible license identifiers include:
FSFAP
CC0-1.0
CC-BY-3.0
CC-BY-SA-3.0
GFDL-1.3
MIT
The license codes correspond to the identifiers found at the SPDX OpenSource License Registry. Take a look at <metadata_license/> for more details about this tag.
Proposal
I propose a
metadata-license
tag, and that this be required for newadditions. And they should use one permissive licenses on this list (so not the GPL ones):
https://wiki.debian.org/DFSGLicenses (this includes the Artistic 2.0 license btw).
OK Metadata licenses:
Artistic 2.0
FSFAP
CC0-1.0
CC-BY-3.0
CC-BY-SA-3.0
GFDL-1.3
MIT
This is totally removed from the license of the project itself. The metadata files need a more permissive license to ensure as wide a distribution as possible and future looking. The project can be whatever the project's creator chooses, but the metadata file itself must be under a permissive license OK for redistribution.
The text was updated successfully, but these errors were encountered: