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

Metadata licenses should be required before adding new modules to ecosystem #19

Open
samcv opened this issue Apr 19, 2017 · 9 comments
Open
Labels
fallback If no other label fits

Comments

@samcv
Copy link

samcv commented Apr 19, 2017

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 new
additions. 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.

@zoffixznet
Copy link

zoffixznet commented Apr 19, 2017

This is not typically the same as the project license.

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 metadata- key prefix:

    "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.

@samcv
Copy link
Author

samcv commented Apr 19, 2017

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.

@zoffixznet
Copy link

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

@samcv
Copy link
Author

samcv commented Apr 20, 2017

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.

@zoffixznet
Copy link

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 "meta": "license" is the license for dist.

"meta": {
    "license-for-metadata":   "MIT"
}

Or your original proposal, but inside the meta key:

"meta": {
    "metadata-license":   "MIT"
}

@samcv
Copy link
Author

samcv commented Apr 20, 2017

I like metadata-license very much. Makes it very clear it's a license for the metadata itself, and can't be misinterpreted easily. +1 from me

@JJ
Copy link
Contributor

JJ commented Apr 29, 2019

OK, back to this. I think I'm moving it to the problem-solving repo, because it looks more appropriate there now.

@JJ JJ transferred this issue from Raku/ecosystem Apr 29, 2019
@AlexDaniel AlexDaniel added the meta Changes to this repo and the main document label Apr 29, 2019
@AlexDaniel AlexDaniel self-assigned this Apr 29, 2019
@AlexDaniel AlexDaniel added fallback If no other label fits and removed meta Changes to this repo and the main document labels Jun 3, 2019
@AlexDaniel AlexDaniel changed the title Metadata licensees should be required before adding new modules to ecosystem Metadata licenses should be required before adding new modules to ecosystem Jun 19, 2019
@AlexDaniel
Copy link
Member

AlexDaniel commented Jun 19, 2019

<bikeshedding> metadata-license can be a bit misleading if your repo contains some other project-specific metadata… Maybe meta-file-license? Or maybe the node on a higher level should be meta-file.

@samcv
Copy link
Author

samcv commented Oct 26, 2019

Or maybe the node on a higher level should be meta-file

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.

@AlexDaniel AlexDaniel assigned jnthn and unassigned AlexDaniel May 14, 2020
@lizmat lizmat unassigned jnthn Oct 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fallback If no other label fits
Projects
None yet
Development

No branches or pull requests

5 participants