Raku / problem-solving

🦋 Problem Solving, a repo for handling problems that require review, deliberation and possibly debate
Artistic License 2.0
70 stars 16 forks source link

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

Open samcv opened 7 years ago

samcv commented 7 years ago

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

The 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 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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 5 years ago

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

AlexDaniel commented 5 years ago

\<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 commented 5 years ago

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.