3) License matching templates/markup: 

We have a task to add markup to some of the standard headers and have also had input to add/edit markup on existing licenses.  As a result of the latter, it has been raised that perhaps the markup could be improved. Before adding more markup (to standard headers, license text or both), it seemed prudent to start a discussion as to whether the existing markup is effective.  Please ponder the following questions:

            a) have you used the existing markup for matching purposes?

                        i) if no, why not?

                        ii) if yes, has it been helpful/effective?  Could it be improved, and if so, how? (this will likely involve putting forward a proposal for review)

[Gary] Yes - For the SourceAuditor commercial tools, the markup is used to validate that 2 licenses are equivalent per the matching guidelines. The open source SPDX tools uses the markup is used in a number of ways.  The "compareSpdx" and "compareMultipleSpdx" commands use the markup to determine if the licenses are equivalent.  There are library methods implemented to compare license text and report if the license text matches any of the SPDX LicenseList.

In all cases above, the markup is used to compare 2 existing known license text.  It is NOT used to match license text against a library of possible license matches.  In the commercial tool, a separate algorithm implements this functionality and the markup language turned out to be too inefficient for this purpose - at least for the performance requirements of our application.

Note: When we originally discussed the markup language, we debated whether to cover the use case of searching a library of possible license matches and the decision was taken not to support this.

In my opinion, the markup works fine for matching two license texts.  If we wanted to support a searching use case, we would need to modify/extend the markup language to enable this to  be efficient.

Please also add thoughts (preferably in a new section or with your initials if added to others) here: http://wiki.spdx.org/view/Legal_Team/Templatizing

I will share a few points from my experience in templatization. I currently use a different templatization syntax that predates SPDX, but the principle of using regular expressions embedded within the license text is similar.

The major barrier to me adopting the SPDX templates is insufficient templatization within the existing licenses. The SPDX templates currently encode what I perceive to be the ‘official’ variations, i.e. organization name, person name, product name etc. However, real-world licenses contain may minor variations that may be inconsequential from a legal perspective, but nonetheless do not warrant separating out as separate licenses. Here is an example from the GPL-3.0 notice where it is common to see two variations in one of the sentences:

distributed in the hope that it will be useful

distributed in the hope that they will be useful

The example above is fairly uncontroversial, I would hope. However, there are plenty of other examples that border on having a legal impact. For example, in these two BSD-2-Clause variations it is necessary to consider whether the additional word constitutes an acceptable minor variation or warrants a different classification altogether:

Redistributions of source code must retain the above copyright notice, this list of…

Redistributions of source code must retain the above copyright notice unmodified, this list of…

It is the grey cases like these that make expanding the use of templating difficult. Inevitably it leads to having to make some judgements about the impact of a particular word or phrase on the legal interpretation, something that I am aware SPDX tries to avoid.

Whether it is worth templating all the cases like these primarily depends on the goals of the SPDX templates. If they are for human use to see what official variations are permitted, then they are not necessary. On the other hand, if they are to be used by automated license scanning tools, then covering these cases is essential in order to have a tool that works effectively on real-world code. So I think an important point is to gain clarity on the purpose of the templates.

In terms of the current application of the templates, I have a technical concern over the use of unbounded regular expressions, for example:

<<var;name=copyrightHolderAsIs;original=THE COPYRIGHT HOLDERS AND CONTRIBUTORS;match=.+>>

This is unbounded because it will match any number of characters for the copyrightHolderAsIs field. The practical consequence of this is that regular expression matching can explode in terms of time. I don’t have a concrete example to hand, but my own experience with using the same unbounded regular expressions on real-world licenses is that I have seen it take minutes just to process one regular expression on a single file, and this does not scale well when there are millions of files to process. Clearly, in terms of English language there is no maximum size on the length of a copyright statement. Using an unbounded regular expression is therefore correct in theory but difficult to use in practice. I have had to use size bounded regular expressions in order to have a scanning tool that will complete in a reasonable time. The problem in switching to bounded regular expressions is in deciding on what is an acceptable upper bound on the size, and this can really only be judged by experimentation against real-world licenses, and does then require on-going tweaking as new license variations are discovered.

[Gary] Extremely good point - Performance would be greatly improved if we bounded the RE's.  Something which is within the spec, but is not implemented in the templates.  I would support implementing bounding all RE's in an upcoming release and changing the spec to encourage bounding.  I think we could pick a pretty practical upper bound that would improve the performance.

Also note - this is more of an issue with the "matching against a library of licenses" issue than simply comparing two license texts since the former is more performance sensitive.

Neither of these are problems with templatization per-se, and they are more to do with the extent and way in which they are currently applied.

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782