Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Registry Inclusiveness #393

Open
egekorkan opened this issue Jan 8, 2025 · 5 comments
Open

Registry Inclusiveness #393

egekorkan opened this issue Jan 8, 2025 · 5 comments

Comments

@egekorkan
Copy link
Contributor

As part of #378 , a discussion started on how inclusive the linked bindings should be, i.e. is any link to a binding with any access and usage permissions are allowed? The points raised so far are:

  1. Should the binding document be required to follow W3C copyright rules, and should the document follow the exact template and look and feel?

    • Ege: No as we want other organizations to also submit bindings. -> TD TF seems to be fine with this requirement.
  2. Should the binding document be publicly available and for free? What about the license, e.g., can I write a binding driver without any fees, etc. The dimensions we thought of are: Reading the binding document, reading the protocol specification, implementing a device/Thing, implementing a Consumer application/driver, building a commercial product with the binding, making a statement about your product's supporting that binding.

  • Ege: At least the custodian and the reviewers should be able to access it for free. This is either with a liaison so that the WG can read it, or the reviewer has access to the binding as they are affiliated with an entity who is a member of the other organization.
  • Koster: Requiring everything to be free to use would limit the amount of bindings. At the very least, the entry should contain a freely available summary document that explains the protocol and how WoT is used there, ideally with an example. The reader should know to what extent the binding goes (e.g. reading device data or device management).
  • Cris: We should promote open protocols and be more restrictive

The minutes of the relevant meetings:

@lu-zero
Copy link
Contributor

lu-zero commented Jan 8, 2025

A binding that has usage or access restriction cannot really be part of the registry, we (w3c) have to be able to store, format and redistribute all the bindings in the registry otherwise the registry itself does not have many reasons to exist.

@mmccool
Copy link
Contributor

mmccool commented Jan 8, 2025

For legal matters, we need to talk to @plehegar

@sebastiankb
Copy link
Contributor

sebastiankb commented Jan 8, 2025

Should the binding document be required to follow W3C copyright rules, and should the document follow the exact template and look and feel?

We may follow the same approach what is IANA is asking for. E.g., https://w3c.github.io/wot-thing-description/#iana-section But I'm not sure if IANA force to have same exact template and look & feel.

Should the binding document be publicly available and for free?

The registry should make this clear if there are some access limitations. E.g., there are fees associated with accessing and acquiring IEC standards

@mmccool
Copy link
Contributor

mmccool commented Jan 13, 2025

My personal opinion on this is that while the registry itself of course should be open, there are many "closed" standards (or paywalled standards) in the IoT space, and in addition to restricted access to standards documents, standards themselves may not be free to use. To take two examples, ISO standards are paywalled, and I believe Matter requires a license fee to use.

Whether or not we agree with such policies, the fact is such standards are important in the IoT space and a "descriptive" standard like WoT should be able to be used with them for maximum applicability, if the adopter is willing to do so. Note also that TDs themselves do not need to be publicly distributed, so it's possible to use it with a standard which does not allow public release of details (in theory).

My proposal is that we should allow and link to such bindings, but record the status of the documents, providing links (e.g. to policies or licenses where appropriate). We can (a) indicate whether the standard itself is free to access or not (b) indicate whether the use of the standard requires a license fee/agreement or not (ideally by linking to the relevant license). Hopefully by making the status visible we can encourage submitters to make their documents as open as possible... Adopters of the TD standard to describe devices following particular standards would have to (separately) agree to the legal terms related to those standards.

In summary, I think we should aim to have the maximum applicability and impact and recognize that royalty-free standards are the exception, not the rule.

@egekorkan
Copy link
Contributor Author

TD Call 16 January:

  • Main Question: Should the custodian host the binding documents?
    • McCool and Kaz: We cannot do it for legal reasons
    • Luca: If the custodian hosts, the implementation is easier. If not, it is easier to write the documents but more difficult to implement.
      • If the document is detected to change and not fulfill the requirements, it can be delisted. TODO: Ege write it into the requirements document PR.
    • DECISION: Custodian does not have to host the binding documents.
  • Question 1 about the copyright and "look and feel" of the linked registry entries, i.e. the binding definition itself. What kind of document are we referring to?
    • Question 1.1: Should the linked binding document have W3C copyright?
      • Luca: Registry entries should follow the all rules as all W3C documents.
      • DECISION: As the custodian does not host it, it cannot enforce the W3C copyright. Thus, the linked binding document does not have to follow W3C copyright.
    • Question 1.2: Should the linked binding document have the same "look and feel" of W3C documents
      • Cris: Should have the similar content and way of reading
      • McCool: The order and the content of sections we want should be defined
      • Luca: Also it should be machine readable/parsable so that the look and feel can be generated. Having the similar documents would reduce the implementation burden.
    • DECISION to be made later

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants