Snap package licenses

[Gustavo Niemeyer]

Using the license ids from SPDX seems straightforward, and that's what
AppStream seems to encourage. But it doesn't mention support for SPDX
license expressions (has a custom and/or rule), or what to do on custom
licenses. So the harmony seems shallow, if you see what I mean. Or am I
missing something?

On Tue, Jan 31, 2017 at 4:24 PM, Neal Gompa <ngompa13 at gmail.com> wrote:

> SUSE has their own list of non-standard references[1], but my
> understanding is that SPDX is working on making this a bit more
> flexible in this regard. This was one of the reasons we haven't
> switched to it in Fedora (the other being the mismatch of BSD/MIT tags
> to SPDX equivalents). AppStream metainfo files shipped with software
> include the SPDX license tags[2].
>
> One of the reasons I personally favor the Fedora tags more is because
> it's not obnoxious with dealing with classes of licenses. However,
> AppStream does mandate SPDX, and harmonizing snap metadata with
> AppStream metadata makes it easier to keep things sane and in sync,
> especially if developers want to use their metainfo files as input for
> generating parts of the snap metadata. Of course, maintaining harmony
> does not imply that SPDX license tags need to be used in snap data,
> only that some kind of automatic mapping from SPDX to another system
> is available. Richard Hughes' appstream-glib (used by GNOME/Ubuntu
> Software) has such a mechanism for going from Fedora/SUSE-classic to
> SPDX[3], and the other way around is considerably simpler.
>
> [1]: https://github.com/openSUSE/obs-service-format_spec_file
> [2]: https://www.freedesktop.org/software/appstream/docs/chap-
> Quickstart.html
> [3]: https://github.com/hughsie/appstream-glib/blob/master/
> libappstream-glib/as-utils.c#L555
>
> On Tue, Jan 31, 2017 at 11:43 AM, Gustavo Niemeyer
> <gustavo.niemeyer at canonical.com> wrote:
> > That's an interesting idea.  Is there a known repository for license
> texts
> > which are not standard?  I see SPDX uses a LicenseRef-<ID> kind of
> > reference, but it's not clear what that is referencing. Just another
> field
> > inside the XML in the case of AppStream, I suppose?
> >
> > On Thu, Jan 26, 2017 at 9:58 PM, Neal Gompa <ngompa13 at gmail.com> wrote:
> >>
> >> On Thu, Jan 26, 2017 at 5:35 PM, Mark Shuttleworth <mark at ubuntu.com>
> >> wrote:
> >> >
> >> > We should allow a plaintext field there for this situation. Yes, go
> >> > ahead with "Other open source".
> >> >
> >>
> >> It would probably make sense to support SPDX license tags and
> >> expressions[1]. This is used in AppStream, so a great amount of
> >> software is already classified in this manner. Furthermore, openSUSE
> >> uses SPDX tags for their license metadata for packages, and Debian
> >> uses a subset of it as part of the copyright file structure in Debian
> >> Source Control packaging.
> >>
> >> While we in Fedora use our own license tag list[2] that predates SPDX
> >> (used by a great deal of Linux distributions), we maintain a mapping
> >> to SPDX for AppStream support.
> >>
> >> Having verifiable license information (either Fedora style or SPDX
> >> style) is also useful for ensuring things are "compatible" or
> >> "desired" on a system, depending on whatever preference you may have.
> >>
> >> [1]: https://spdx.org/licenses/
> >> [2]: https://fedoraproject.org/wiki/Licensing:Main#Software_
> License_List
> >>
> >> --
> >> 真実はいつも一つ！/ Always, there's only one truth!
> >>
> >> --
> >> Snapcraft mailing list
> >> Snapcraft at lists.snapcraft.io
> >> Modify settings or unsubscribe at:
> >> https://lists.ubuntu.com/mailman/listinfo/snapcraft
> >
> >
> >
> >
> > --
> > gustavo @ http://niemeyer.net
> >
> > --
> > Snapcraft mailing list
> > Snapcraft at lists.snapcraft.io
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/snapcraft
> >
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
> --
> Snapcraft mailing list
> Snapcraft at lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/snapcraft
>



-- 

gustavo @ http://niemeyer.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20170131/d6c8f50e/attachment.html>