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

Move License Template compatibility check to individual LicenseTemplates #80

Open
jdubpark opened this issue Apr 12, 2024 · 1 comment
Assignees
Labels
enhancement New feature or request license

Comments

@jdubpark
Copy link

Currently, there's a global restriction in allowing only one license template per IP.

For example, if IP attaches PIL licenses, it can't attach licenses from other templates.

if ($.licenseTemplates[ipId] != address(0) && $.licenseTemplates[ipId] != licenseTemplate) {
revert Errors.LicenseRegistry__UnmatchedLicenseTemplate(ipId, $.licenseTemplates[ipId], licenseTemplate);
}

This restriction might be very restrictive for some license templates, such as when a user wants to attach MIT licenses and some other licenses from different license templates.

Hence, we should move this check to be within each license template.

@LeoHChen LeoHChen added bug Something isn't working high priority labels Apr 12, 2024
@LeoHChen LeoHChen added this to the v1.1 code freeze milestone Apr 12, 2024
@Ramarti
Copy link

Ramarti commented Apr 14, 2024

I think for this release we are safer without this feature.

We would have to be able to have inter-template compatibility checks, with common values that mean the same for every template.

I think the minimum variables that could be reused across templates and help reduce significant compatibility issues are:

  • commercialUse
  • derivativesAllowed

An alternative is to allow templates to say if they are compatible with others, but that puts a lot of trust on the templates, especially if we want too open template registration. One template would have to trust the other template did not alter the Licensing terms after claiming compatibility, potentially rugging the user.

In beta, the solution was storing LicensePolicy data in LicensingModule and not allowing modifications from the templates (then frameworks). That way data is stored in the protocol, and templates/users can make decisions using a License without fear of being rugged by the LicenseTemplate.

We would need to find a way of doing this without complicating the DX with encoding, or doing very simple encoding.

@jdubpark jdubpark added enhancement New feature or request and removed bug Something isn't working high priority labels Apr 17, 2024
@jdubpark jdubpark removed this from the post v1.1 - parking milestone milestone Apr 17, 2024
kingster-will pushed a commit to kingster-will/protocol-core-v1-dev that referenced this issue Jan 31, 2025
* fix 3 failures
1. Shall not add IP to group if IP does not share the same licensing terms as the group
2. Dispute - Set tags to the derivative IP assets if the parent infringed
3. Dispute - Set tags to the derivative IP assets if the parent has not infringed
kingster-will pushed a commit that referenced this issue Jan 31, 2025
* fix 3 failures
1. Shall not add IP to group if IP does not share the same licensing terms as the group
2. Dispute - Set tags to the derivative IP assets if the parent infringed
3. Dispute - Set tags to the derivative IP assets if the parent has not infringed
irfand29 pushed a commit to irfand29/protocol-core-v1 that referenced this issue Feb 8, 2025
* fix 3 failures
1. Shall not add IP to group if IP does not share the same licensing terms as the group
2. Dispute - Set tags to the derivative IP assets if the parent infringed
3. Dispute - Set tags to the derivative IP assets if the parent has not infringed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request license
Projects
None yet
Development

No branches or pull requests

4 participants