<div dir="ltr">Hi Joseph,<div><br></div><div>The discussion above felt like painting an incorrect picture of what we're aiming at. We *definitely* want to track license information inside the snap format in a proper location. We want to support both basic cases such as just listing a well known name, custom licenses, and all the way up to requiring an explicit agreement with the provided text.</div><div><br></div><div>We're not there yet, but this is in our short to medium term roadmap for sure.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 6, 2017 at 10:46 PM, Joseph Rushton Wakeling <span dir="ltr"><<a href="mailto:joseph.wakeling@webdrake.net" target="_blank">joseph.wakeling@webdrake.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 07/02/17 00:24, Kyle Fazzari wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The fact that an empty directory is created here is a bug[1]. It should<br>
only create that directory if there's something to put in there. What<br>
Sergio is saying is this:<br>
<br>
Snapcraft-specific things, like hooks from snapcraft parts, command<br>
wrappers (eventually, not yet) will end up in the snap/ directory of the<br>
built snap. This has no bearing on the snap format, it's something<br>
internal to snapcraft (it could just as easily have chosen to place<br>
those things in the foo/ directory).<br>
<br>
The things in meta/ are specific to snapd. This directory is literally<br>
what defines "this random squashfs image" to be a snap.<br>
</blockquote>
<br></span>
OK, makes sense.  BTW, I hope I didn't come over as overly negative in my reply to Sergio: if so it wasn't intended.<br>
<br>
Can I however raise a plea that `meta/` should contain licensing information as a requirement?  Even if it's not actively used by snapd right now, it makes sense as a location and it would also make sense (in future) to be able to do things like<br>
<br>
    snap license whatever<br>
<br>
to check the available licensing information.<br>
<br>
More generally, it seems like a good idea to me that (i) snap packages must contain licensing information, (ii) it will be available in a standardized location both in the snap package definition and the generated snap package, and (iii) this will be enforced/guaranteed by snapcraft.<div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
Snapcraft mailing list<br>
<a href="mailto:Snapcraft@lists.snapcraft.io" target="_blank">Snapcraft@lists.snapcraft.io</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/snapcraft" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailm<wbr>an/listinfo/snapcraft</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><br>gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a></div>
</div>