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 <ngomp...@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 <gust...@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 <ngomp...@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.nieme...@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 <ngomp...@gmail.com> > wrote: > >> >> > >> >> On Thu, Jan 26, 2017 at 5:35 PM, Mark Shuttleworth <m...@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@lists.snapcraft.io > >> >> Modify settings or unsubscribe at: > >> >> https://lists.ubuntu.com/mailman/listinfo/snapcraft > >> > > >> > > >> > > >> > > >> > -- > >> > gustavo @ http://niemeyer.net > >> > > >> > -- > >> > Snapcraft mailing list > >> > Snapcraft@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@lists.snapcraft.io > >> Modify settings or unsubscribe at: > >> https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > > > > > > -- > > > > gustavo @ http://niemeyer.net > > > > -- > > Snapcraft mailing list > > Snapcraft@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@lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- gustavo @ http://niemeyer.net
-- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft