A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

[Proposal] Set html with license

Anonymous2292900
2022-12-16

Hey everyone!

Intro & problem

A crazy, random idea I had today would be to have an html tag for license. Usually when we access a website there is no possibility of knowing whether certain content is licensed or not - or html is licensed or not.

Partial or final solution

The proposal I have today is to solve the problem of determination and right of content by the html license tag - below is a list of license tags. For example:

option 1: set body or head with license

<!DOCTYPE html>
<html>
<head license-type="GPL-3.0">
<link rel="license" href="GPL-3.0.txt"> 
<!--- 
 or href="MIT.txt" 
 or href="Copyright.txt" 
...  
--->
</head>
<body license="GPL-3.0">
<p>Content licensed with GPL-3.0 license </p>
</body>
</html>

option 2: set meta html with license

<!DOCTYPE html>
<html>
<head>
<meta license="GPL-3.0"/>
<license type="GPL-3.0"/>
<license type="GPL" version="3.0"/> 
<!---  
or
<license type="MIT"/>
<license type="Copyright"/>
<license type="MIT" version="2.1"/>
<license type="Copyright" version="1"/> 
---->
</head>
<body>
<p>Content licensed with GPL-3.0 license </p>
</body>
</html>

option 3: set html elements with license

<!DOCTYPE html>
<html>
<head>
<input type="file" license-type="GPL-3.0"/>
<input type="file" license-type="GPL" version="2.1"  />
<audio type="file" license-type="GPL-3.0"/>
<audio type="file" license-type="GPL" version="2.1"  />
<video type="file" license-type="GPL-3.0"></video>
<video type="file" license-type="GPL" version="2.1"></video>
<div type="file" license-type="GPL-3.0"></div>
<div type="file" license-type="GPL" version="2.1"></div>
<!---  
or
<input type="file" license-type="MIT"/>
<input type="file" license-type="Copyright"/>
<input type="file"="Copyright" version="2.1" />
<input type="file"="MIT" version="2.1" />
---->
</head>
<body>
<p>Content licensed with GPL-3.0 license </p>
</body>
</html>

option 4: set html with license from cdn

<!doctype html>
<html>
<head>
    <meta charset="utf-8">
    <title>Cdn and license</title>
    <link rel="license" href="GPL-3.0.txt"> 
    <link rel="license" href="https://democdn1.com/GPL/3/license.txt"> 
    <link rel="license" href="https://democdn2.com/GPL/3/license"> 
    <license type="GPL-3.0"/>
    <license type="GPL" version="3.0"/> 
    <!-- Imports license with democdn2 external license -->
    <link rel="import" href="https://democdn2.com/GPL/3/license">
</head>
<body>
    <!-- Runs custom element from democdn1, democdn2 --->
    <license type="GPL" version="3.0"/> 
    <license type="GPL-3.0"/>
    <img src="/logo.txt" license="https://democdn2.com/GPL/3/license"/>
</body>
</html>
suns
2022-12-20

This is definitely not random. In Web 3.0 the different vendors content is mixed into web application with own license requirements. This content is not only comes from 3rd party vendors but also served from different hosts/CDN/repositories. For Declarative Custom Element and Declarative Web Application served from outside, the license data definitely have a sense and would be a part of components acceptance protocol for portals or CMS.

Going further, I would imagine the styling (outline, background, etc. ) based on this tag in DCE on edit mode in visual designers.

To make it more coding-friendly, it worth to be added to own namespace exposed as to HTML as to XML with matching DTD.

XSLT 4 proposed ability to mix namespaces as long as tags are not overlapping, same can be assumed in HTML.

suns
2022-12-20

What kind of data the license need?

  • type - with package.json schema
  • version
  • href - URI to text
  • icon as in GitHub
  • description - for accessibility via screen reader, etc.
  • media to be selected by screen reader, “about application” inspector, etc.
suns
2022-12-20

If the license on proposal, symmetrical entities have to be considered as well.

As most of those could have multiple and complex entries, embedding would be needed.

The Declarative approach for those kind of data needs abstract container with section type. The meta tag is self closing and does not allow to include relative and long content. While it is possible to inject several license(or another) related info using prefix, repeated keys would be clunky cloning

<meta contributors-name="aaa" contributors-email="a@b.c" />
<meta contributors-name="bbb" contributors-email="b@b.c" />

Which given us a need for metagroup as structured content

<metagroup contributors>
    <meta name="aaa" email="a@b.c"/>
    <meta name="bbb" email="b@b.c"/>
</metagroup>

The metagroup is not an ideal word, in meta definition the metadata refers to the abstraction layer where meta is just a holder for key-value pairs.

Anonymous2292900
2022-12-21

Hi suns.

Interesting

I had a perhaps strange or unique vision is: a document type definition(dtd) is a set of markup declarations that define a document type for an SGML, GML, IBM_Generalized_Markup_Language, SGML, XML, HTML Because a dtd defines the valid building blocks of an XML document. It defines the document structure with a list of validated elements and attributes. A DTD can be declared inline inside an XML document, or as an external. DTD is similar to package.json

We can see this here:

<!--- file license.dtd --->
  <?xml version="1.0" standalone="yes"?>
  <!DOCTYPE HELLO [
     <!ELEMENT HELLO (#PCDATA)>
     <!ATTLIST HELLO NAME LICENSE CDATA #REQUIRED>
     ]>

  <HELLO LICENSE="GPL"> Hello text with licensed GPL </HELLO>

and here:

<!-- Imports dtd with license with democdn2 external, license -->
<link rel="license" href="https://democdn1.com/DTD/GPL/3/license.dtd"> 

or here too:

<!--- another file license.dtd --->
 <?xml version="1.0" ?>
 <!DOCTYPE hello SYSTEM "contributors.dtd">
 <hello> hello licensed with contributors.dtd </hello>

or here too:

<!--- another file license.dtd --->
 <?xml version="1.0" ?>
 <!DOCTYPE hello SYSTEM "metagroup.dtd">
 <hello> hello licensed with metagroup.dtd </hello>

I imagine that our package.json would be a dtd file specifying the areas where a certain content or html element is licensed.

Or… In another case, I imagine that our package.json would be a web-component file specifying the areas where a certain content or html element is licensed.

Each cdn network can specify certain html elements with some license or even each web compoenent within a cdn network must specify certain html elements with some license too, so I realized the use case of dtd and web component as necessary for license

use case here:

<!-- use case 1: Imports dtd with license with democdn2 external, license -->
<link rel="license" href="https://democdn1.com/DTD/GPL/3/license.dtd"> 

<!-- use case 2: Imports web component with license with democdn2 external, license -->
<link rel="import" href="https://democdn2.com/GPL/3/license"> 
suns
2022-12-21

I am looking into license and other fields from consumer point of view. Same html document could have 0+ licenses itself and web components / WC libraries own ones.

As an application code programmer I need those to be exposed coherently in HTML DOM. XML annotations, comments and other non-dom methods do not fit into usual DOM processing routine, leaving tag-based syntax as most convenient for purpose.

The external and embedded definitions are definitely needed. Each would serve own purpose: external is reusable and cache-able, embedded easier to process. Ideally embedded and external formats would use same syntax so “if not embedded, load external reference and process in same fashion” would be applicable. Which takes JSON like package.json or webcomponent.json out of equation as the consumption of inline and external would differ.

Just a reminder, the proposal is about declarative syntax, no need to circle back to JSON as a format.

XML-like format would make internal and external preference a matter of same single expression in XPath or JS.

Anonymous2292900
2022-12-22

Hi suns.

  • How can I pitch this idea as a real proposal?
  • Could you help me create an rfc document about this idea?

I would like to create a document in w3c or wicg about this idea, if you can help me to compose the document

suns
2022-12-22

@Anonymous2292900 , You of course can start proposal in scope of WICG. But at this stage there is so little review. Perhaps it worth to prepare the proposal but wait on publishing till mid of January when folks back from holiday break?

As for the help, would be glad to chime in but it would not be much efficient as I have not done the formal W3C proposals yet.

Anonymous2292900
2022-12-22

Hi suns.

  • How do I do that? (How to start the proposal in the WICG scope?)
  • There is have a readme template to document this proposal or any proposal?

I agree with you, you’re right. thanks for the comment… I will wait then.

Anyway if you can help me with the WICG documentation I would be happy.

Anonymous2292900
2022-12-22

Hi suns.

A curious question: Do you think this proposal can help things like DRM?

suns
2022-12-22

The license support itself is definitely not sufficient to cover DRM needs. The abstract structured metadata like metagroup would. There are several standards of DRM. [MS-DRM]: XML Schema for Version 7 License Response , Use Case 2 - XSD for DRM - W3C eGovernment Wiki - just to name a few.

Having XML data island as part of metadata associated either with a HTML document (page) or any of its components would be helpful. Those components with own metadata could be any video, OBJECT, Declarative Custom Element, etc.

Anonymous2292900
2022-12-29

like this?


<metagroup id="resource1" contributors>
  <meta name="aaa" type="" version="" href="" icon="" description="" content="Example Resource" media="" email="a@b.c"/>
  <meta name="bbb" content="1.0.0.0" email="b@b.c" />
  <meta name="language" content="en-US" />
  ...
</metagroup>

?

Anonymous2292900
2023-02-26

Hi suns.

Thank you for your help. I’m happy with the idea of the proposal but I don’t think it makes sense, considering that the WICG has a proposal similar to the html by the href.

If everyone wants to comment here too: Set html with license · Issue #85 · WICG/proposals · GitHub - I got some feedback there on GitHub.