snap info showing "unset" license for snaps

[Alberto Donato]

Some of my snaps show "license: unset" in snap info output, although the license is set on the store.

Specifically, I see this happening on "sshoot" and "h2static" snaps.

[Adam Collard (adam-collard)]

$ snap info sshoot
name: sshoot
summary: Manage sshuttle VPN sessions
publisher: Alberto Donato (ack)
contact: https://github.com/albertodonato/sshoot
license: GPL-3.0+
description: |
  Command-line interface to manage multiple sshuttle VPN sessions.

  sshoot allows to define multiple VPN sessions using sshuttle and start/stop
  them as needed.
snap-id: NHCu10y1SjRam7ECz2NTKfHtkgU0nPjr
channels:
  stable: 1.4.1 2018-12-12 (89) 8MB classic
  candidate: ↑
  beta: ↑
  edge: 1.4.1 2018-12-07 (89) 8MB classic

[Adam Collard (adam-collard)]

snapd seems to not understand the license that the store does, so that when the snaps are installed it thinks the license is unset.

I correctly saw the license for both snaps when they were uninstalled:

$ snap info h2static sshoot | grep license
license: LGPL-3.0
license: GPL-3.0+
$ snap install sshoot --classic
...
$ snap info h2static sshoot | grep license
license: LGPL-3.0
license: unset

[John Lenton (chipaca)]

When the snap is installed a number of fields in `snap info` come from the installed snap; license is one of these.

Unfortunately snapcraft still doesn't understand license (last tested with 3.0 a few days ago building icdiff), so unless the developer has gone out of their way and used passthrough, most snaps won't have a license. But the license of the thing that was installed is what snap info presents, and that license comes from the snap.yaml, and if it's unset there it's unset as far as snapd is concerned.

Note that license is, or should be, per revision; at least that is my memory of the discussion around this. The store treats it as if it were per snap, meaning that it lets a publisher unilaterally change the license of something, which is not ideal.

So, er, yes. Working as intended? maybe. I'm not sure.

[Adam Collard (adam-collard)]

> The store treats it as if it were per snap, meaning that it lets a publisher unilaterally change the license of something, which is not ideal.

The license field is not authoritative, it reflects what license the code is under. The store allows the publisher to rectify mistakes, and update the license to reflect reality.

Note the discussion about license being per-revision or per-snap is best had on https://forum.snapcraft.io/t/snap-license-metadata/856/52

I also believe that snapcraft *does* support license, but only when actually running 3.x code (i.e. base: keyword is present).

[John Lenton (chipaca)]

> I also believe that snapcraft *does* support license, but only when actually running 3.x code (i.e. base: keyword is present).

huh, just tried again and it worked. Sweet.

[Sergio Schvezov (sergiusens)]

That is correct, as evidenced by this test:
https://github.com/snapcore/snapcraft/blob/master/tests/spread/general/license-valid/task.yaml
and this one
https://github.com/snapcore/snapcraft/blob/master/tests/spread/general/license-invalid/task.yaml

[John Lenton (chipaca)]

Not sure what combination I tried and failed, last weekend; I'm glad it's working in snapcraft.

Now we need to sort it out in the store and snapd...

[Gustavo Niemeyer (niemeyer)]

The behavior of snapd seems correct, in the sense different revisions of the snap may have different licenses. "Rectifying" a license in a way that future information affect past code seems very bogus in this context.

With that said, we might have a special case for "unset".

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.