...
The need we identify is existing and real. There is a strong risk that other organizations who are in a stronger position to communicate and to create a standard, will produce a license with the same goal. Eg OSI is also in the process of creating a definition of open source as it relates to AI.
...
Requirement | User Story | Importance | Status | Jira Issue | Comments |
---|---|---|---|---|---|
Form related | |||||
Ability for potential contributors to go the UC HubSpot website page and choose an option to fill out Federated Data license. | P1 | Done | The form is a gated HubSpot form so that only authenticated users can fill it out. | ||
Ability for potential contributors to fill out the Federated Data license with information specific to their organization. | P1 | Done | Note that the form is already built by the marketing team within HubSpot. | ||
Ability to automatically email the license to the user once the form has been completed. | P1 | Done | Part of the HubSpot workflow | ||
Ability to store the form in HubSpot to the organization, once the form is filled out. | P1 | Done | Is the form attached to the company, CCH account, UC 4.0 workspace, or other? Yes. For example here’s the HubSpot URL for the form I filled out. | ||
Ability to update the HubSpot contact intent to reflect that they have filled out the Federated Data license. | P1 | Done | Part of the HubSpot workflow | ||
Ability for the UC 4.0 product to have access to the Federated Data license. | P1 | In design | |||
Ability for authorized users of the workspace to view the license. | P2 | Not started | Anyone in the company should be able to see their own license. | ||
Ability to require the customer to fill out the form prior to contributing content. | P1 | In design | For customers that do not intend share, there is no need to fill out the Federated Data license. Could be a link to the same website form and once filled out would be attached this workspace. | ||
Ability to forward the draft license to another person in the company eg legal | |||||
General terms / EULA | |||||
Ability for each user (contributor or not) be able to confirm they have read the terms (aka EULA) | P1 | Done | |||
Ability to require each user (contributor or not) to re-confirm they have read the terms (aka EULA) if/when the EULA has been updated. | P3 | Not started | |||
Ability for an end user to view the current terms at any time. | P1 | Done | |||
License and Attribution | |||||
Ability to automatically attach the license to any content that is shared with the community. | P1 | In design | Includes any existing content such as PlantUML and glossaries and sets framework for any future content type that would be added later. Will not do in the first stage. | ||
Ability to automatically assign attribution for content sourced from content contributors. | P1 | In design | Includes dictionaries (e.g., OED, MW …) or other content providers like PCI, GRI … | ||
Ability to automatically assign attribution for any content created within the platform. | P2 | In design | Example, if an AT&T user creates a PlantUML diagram, AT&T is attributed to the creation of that diagram. Will not do in first stage. | ||
Ability to automatically assign attribution for any content transformed within the platform. | P2 | Partially done for Dictionary term definitions. | Initially for any content that a user transforms (e.g., updates a term definition) and will set groundwork for additional transformation to content such as tagging and mapping to common controls. Will not do in the first stage. | ||
Ability for users to manually assign attribution (could be multiple) to content created (or later updated) within the platform. | P1 | Completed for Dictionary terms but not PlantUML | Example, if an AT&T user creates a PlantUML diagram, but used sources from two other company’s websites, the user must be able to site both sources by name and source URL. | ||
Ability for users to copy shared content and make changes while keeping the attribution chain. | P2 | Need to review | Example, if an ACME user copies and modifies an OED attributed dictionary term-definition pair, the copied term-definition pair will indicate that OED was the original source and ACME attributed to the updates. Will not do in the first stage. | ||
Ability for any user to see the attribution chain within the user interface and within API results. | P2 | Need to review | Example, if an ACME user copies and modifies an OED attributed dictionary term-definition pair, the attribution chain will show that OED was the original source and was modified by ACME. Will not do in the first stage. | ||
Ability for any user to see (through the UI and API response) the license associated with each attributable source per shared content. | P1 | Need to review | Example: if a PlantUML diagram was originally created by AT&T, then copied and modified by IBM, any user can see the attribution chain (in the UI and API response), but also see the licenses from both AT&T and IBM. Example: if an ACME user maps in a PCI authority document, each enrichment task (e.g., tagging terms, matching to common controls) is attributed to ACME. End-users are able to see attribution to PCI as the authority source and ACME as the content enrichment provider including links to licenses for both PCI and ACME. | ||
Ability for any user to view and download their organization’s license from within the workspace (e.g. PDF) to share with legal, compliance, or other teams. | P2 | Will not do in the first stage. |
...