Hi Philippe,

Comments below:

For the last two calls:

http://wiki.spdx.org/view/Legal_Team/Minutes/2015-07-23
[...]
3) Mark-up bug raised on tech team call- bug filed requesting that the mark-up be
done to facilitate automation vs. human readable. Good goal that tech team will look
to see if it can be prioritized for next year. Gary will also talk with Jilayne about the
possibility of making mark-up changes something that others can do and then
submit as a patch
[...]

http://wiki.spdx.org/view/Legal_Team/Minutes/2015-08-06
[...]
2) Kris had raised request via tech list regarding markup on licenses and matching rules and joined to discuss some issues
matching guidelines that are programmatically difficult to implement, wanted to be
able to make suggestions
global review or make small improvements
examples: ISC License - now default license for NPM, has reference to ISC in text (needs markup);
one link broken on SPDX list and one goes to link with slightly different text (generic v. specific to ISC)
[...]

Adding matching markup inside the reference license texts will
eventually lead to un-resolvable conflicts:

There is already markup in about 15% of the licenses, as per our in depth discussions a couple years ago. The conversation on the call was about improving some of the existing markup, adding markup that should have been there but isn’t (in at least one case), and adding some markup for other matching guidelines.
I think everything that was recommended by Kris and discussed on the call was probably something discussed at the original meetings on how to implement the markup for the matching guidelines at Collab Summit a couple years ago (Daniel German’s ears are ringing!) - As I explained as part of the background: we admittedly took a conservative approach as to what we could markup up on the initial release of this, always easier to add later, than remove. My memory was that the people directly involved various tools (license scanners) wanted more markup, as that eliminates having to make a determination.

- markup will make a license text no longer a reference
- it will make it less readable or unusable as such
- it may damage or transform a reference text in unwanted ways

I’m not sure what you mean here by the license text no longer being a reference or damaging it? Can you explain or provide an example? If we’ve missed a use-case that more markup could frustrate, we definitely want to discuss that.

It would be simpler to separate the two cleanly:

1. Reference license texts, not modified for matching.
They may contain lightweight markup for the purpose of clarity, not
for matching.

We already have licenses with markup - do you consider what we have now as what you describe above?
I do understand that having a “clean” license text with no markup could be desirable (cut and pasting…) but we do have that on the HTML pages. as the actual markup does not show up there (only in colored text for the visual).

2. Arbitrarily marked-up texts for matching modified as needed.
They may contain heavy markup to the detriment of clarity.

I don’t think we need arbitrarily marked-up texts, nor would we have that. We need accurately marked-up texts, that have been vetted, just as we did for the markup that we currently have - this won’t change.

Each can then have their own contribution and review paths: texts with
the legal team, markup with the tech team.

That is not tenable - if someone suggests additional markup, the legal team will need to review it to ensure that, for example, text that is proposed to be marked as replaceable does not change the meaning of the license - a cross-team approach (tech and legal) is needed.

A given was that there would be a review process for any recommendations - perhaps I did not capture that in the meeting minutes (or other assumptions that didn’t warrant much discussion, as we all agreed). will try to bear that in mind for future minutes!

Jilayne