linking to non-normative external code seems incorrect

[thejohnjansen]

I think some implementers may not have permission to view an open source code project, and even if they do a bug fix here or there will mean implementations that do not have those bug fixes will be out of compliance. I think these steps need to be written out as part of the actual spec itself.

[andreastt]

I think @shs96c wanted to inline the code, but found it was too hard to sensibly extract in a readable manner from the Closure compiler (please correct me if I’m wrong). We could include the (unreadable) minified code in a file stored in the repository and continue to give a hashsum of it like we do today, possibly with a non-normative reference to the Selenium project?

[shs96c]

This was discussed in #413 and #714, but it's worth exploring again. We ended up with three options:

1. Write out the algorithm "long-hand", taking the JS code and attempting to convert it to English.
2. Relicense the spec under Apache 2.0
3. Relicense the code from the Selenium project, and include it within the spec.
4. Include compiled versions of the code in the spec, after relicensing the Selenium code.
5. Link to the external code and say that implementations must be exactly analogous.

Our initial approach was the first. This was distinctly sub-optimal --- at best the English was deeply confusing, and left lots of room for ambiguity.

The second approach has the exact problem you're trying to avoid, and email discussions suggested that some members of the WG didn't think it was a workable solution.

We next tried the third and fourth approaches. The code in the Selenium project builds on top of Google's Closure Library. In order to include the code, we'd need permission from both the Selenium Project (via the SFC) and Google.

To add a wrinkle to the problem, all code contributions to the Selenium project are only accepted after an CLA has been signed. This basically says the the SFC has permission to relicense under Apache 2.0. While the SFC were fine with the dual licensing the code, the presumption that they had the authority to do the relicensing was flawed.

Thanks to our source control history, it would theoretically have been possible to find all contributors and ask them to agree to relicensing the code, but this was felt impractical.

This left our final option: including a normative link. In one of the review comments on #714, @thejohnjansen wrote:

My thinking is that HTML5.1 does this with a bunch of normative links; the high-order bit should be whether that link is stable or if the content is going to be changing. I feel like it's pretty concrete, and if so it seems OK to me (of course, verifying with Mike[tm] Smith makes a ton of sense as well).

So we went with the approach we have now.

Your thoughts?

[jugglinmike]

@shs96c Have you folks considered reverse engineering the script to produce a compatible version?

[shs96c]

I don't think compiling the code changes the copyright of that code, so I'm not convinced we can include the atom that way.

Reverse engineering would be possible, but may not be needed. We will rewrite the (extensive) tests from the selenium project around text handling to this spec's conformance suite, and the original code is under the Apache 2 license, which is very friendly to consumers of the code.

I'm not a lawyer, so my comments might be utterly meaningless.

The final thought: the approach we've taken was partly suggested to mirror the approach apparently taken in the HTML spec. Are we worrying about something we need not worry about?

[jugglinmike]

I'm most immediately interested in the licensing because of my work writing
tests for the Web Platform Tests project. The BSD license may be acceptable
there, but I will need to verify on the mailing list, first. I'm happy to do
this.

In the mean time, could you share a link to the Selenium test suite that you
mentioned re-writing? I imagine they are somewhere within
https://github.com/SeleniumHQ/selenium, but I'm not sure if any one language
binding has better coverage than another.

And although testing is my primary motivation for suggesting a re-write, I was
also thinking that this would be beneficial for the specification itself. It
seems to me that including source code in-line would generally be preferable to
the current solution, even if the spec is allowed to advance to CR either way.

[shs96c]

A relicense is a relicense, so would face the same hurdles as we encountered previously. The trick will be identifying the contributors and getting them to agree to the change, as well as finding something that spec implementers are happy with. Perhaps the bit under our control is the best place to start?

A reasonable number of the tests for the selenium project's text handling are here: https://github.com/SeleniumHQ/selenium/blob/master/java/client/test/org/openqa/selenium/TextHandlingTest.java though there are other tests throughout the tree.

[jugglinmike]

A relicense is a relicense, so would face the same hurdles as we encountered
previously.

I was still writing with the "re-write" idea in mind. If someone were to write
a new JavaScript implementation of getVisibleText using the Selenium
project's tests as a guide, it's my understanding that the result would
represent a new work that was wholly their own, and that they could license it
however they wished. Is that not accurate?

[shs96c]

A new implementation, written using just the tests, would be fine and wouldn't need to be relicensed.

…

Sent from my iPhone

On 9 Jun 2017, at 16:30, jugglinmike ***@***.***> wrote: A relicense is a relicense, so would face the same hurdles as we encountered previously. I was still writing with the "re-write" idea in mind. If someone were to write a new JavaScript implementation of getVisibleText using the Selenium project's tests as a guide, it's my understanding that the result would represent a new work that was wholly their own, and that they could license it however they wished. Is that not accurate? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[shs96c]

Assigning to @thejohnjansen, but I believe that we've agreed that the linking is okay provided it's possible for an implementor not to have to look at the links in an OSS project.

[AutomatedTester]

This has been discussed in web-platform-tests/wpt#6746 (comment)