Snap package licenses

Tue Jan 31 19:30:51 UTC 2017

Yes, that's the custom and/or rule I mentioned. This is not the SPDX
license expression format:

https://spdx.org/spdx-specification-21-web-version

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

> No, you're not missing something. AppStream doesn't really have a
> great way to represent custom licenses. But license expressions are
> supported, as you can see in this example[1]. I suspect the "proper"
> way to handle it would be to have the license bundled in the metadata
> when "Custom" or "Proprietary" is used, so that the resource is
> available for review prior to installing. With the standardized
> licenses, usually the software centers render hyperlinks that users
> can click to see the terms.
>
> I'd potentially argue that BSD and MIT licenses would probably need to
> be handled the same way, given that copyright owners are declared in
> the license text.
>
> [1]: https://gitlab.com/osslugaru/lugaru/blob/master/Dist/Linux/l
> ugaru.appdata.xml
>
> On Tue, Jan 31, 2017 at 2:03 PM, Gustavo Niemeyer <gustavo at niemeyer.net>
> wrote:
> >
> > 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-Qui
> ckstart.html
> >> [3]:
> >> https://github.com/hughsie/appstream-glib/blob/master/libapp
> stream-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
> >
> > --
> > 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/mailm
> an/listinfo/snapcraft
>

-- 

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