Erik Huelsmann wrote:

Hi,

In various occasions I have seen that you plan to make the metadata arbitrary string or even general values. While I think that's okay, to provide lists of suggested values so that use of the values gets easier and if most people use the suggested values, the value system could end up centralized around those values. In my opinion, that would add value, especially for machine interpretation.

Note that this isn't something that I have planned. It is something that is the de facto current standard. To date, all the metadata are given simply as strings, and they aren't of use for other than human inspection.

If someone would suggest a list of keywords for the licenses, we could certainly incorporate that in some fashion. But it would complicate any introspection code. Presumably that code would be taking the metadata and formatting it for the user. So it would now have to consider the possibility of keywords, which should be translated, and probably lists of keywords (per Fare's email), as well as strings. That would complicate the work of anyone trying to make use of the code.

Now, if there was something where someone might want to say:

(find :gnu-gpl (mapcar #'asdf:component-license my-systems))

[actually, that wouldn't work because of the possibility component-license is list valued]

and do something with the results, then it might be worth making such an effort. But I haven't seen any "pull" for such a feature in ASDF.

cheers, r

Regards

Erik

On May 27, 2015 8:54 PM, "Robert P. Goldman" <rpgoldman@sift.net mailto:rpgoldman@sift.net> wrote:

Faré wrote:
>> OTOH, it's probably A Bad Thing if you depend on a system for
something
>> you are doing, and don't know what license it uses.
>>
> Well, we haven't codified any format for :license. I suppose we
could adopt
> the nomenclature used by Debian. Except what in Lisp circles goes by
> the name "MIT"
> (as notably used by ASDF itself) in Debian-speak is called "Expat".
> Also, we don't have a story for multi-licensed code either.
> For instance, I have code under LLGPL or bugroff, or BSD or bugroff.

I didn't mean that we needed a codified format.  I just meant that if
you are using a system, and the humans involved don't know if your usage
is legal (e.g., are you using pure GPL in a commercial application? are
you delivering source for libraries when you deliver your code? etc.),
that's a Bad Thing.

Given that :LICENSE is currently arbitrary string valued, we can just
make a string that indicates multiple possible licenses.

We could certainly add some standard values (keywords?) for common
licenses, and allow people to specify a list of such values (and an
optional string), but I'm not sure what we would gain by this.

I don't yet see a use case for machine-introspection on the :license,
but I'm open to suggestions.

>
>> But that's why I created a special class of CONDITION for this
case --
>> so you can muffle it if you don't care.  It would be nice if
there was
>> some way to detect the distinction between internal systems (fix
them!)
>> and external systems (muffle).
>>
> At ITA, we started with muffling the external systems, but quickly
> enough decided to fix them instead; code quality matters for libraries
> we depend on, too. But we did have a list of style-warnings to muffle
> and some of them were based on dependencies indeed.

For now a programmer could match the name of the system in my
MISSING-METADATA condition, and use that to make his or her decision
about muffling.
>
>> I'll push my topic branch today.  It needs a test script, and I'd
like
>> to make it skip signaling on "slashy" subordinate systems, but
I'd love
>> comments in the meantime.
>>

I pushed this as the QL-metadata-warning topic branch.

Best,
r