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

Proposal: Move data license from CreationInfo to SpdxDocument #467

Closed
goneall opened this issue Aug 4, 2023 · 3 comments · Fixed by #490
Closed

Proposal: Move data license from CreationInfo to SpdxDocument #467

goneall opened this issue Aug 4, 2023 · 3 comments · Fixed by #490
Labels
Profile:Core Core Profile and related matters Profile:Licensing Licensing Profile and related matters serialization Something about the representation of data in bytes
Milestone

Comments

@goneall
Copy link
Member

goneall commented Aug 4, 2023

In reviewing @zvr comment on change proposal 8, we may want to consider moving the data license from CreationInfo to SpdxDocument.

This would relate the data license to the serialization information which is something we are already doing with fields like the original namespace.

I believe this would solve @zvr's concern and match the semantics of both CreationInfo and SpdxDocument.

Note that the use of SpdxDocument is entirely optional which should no longer be an issue if the data license is also optional.

@zvr
Copy link
Member

zvr commented Aug 5, 2023

Why not have it a Relationship instead of a property?

@goneall
Copy link
Member Author

goneall commented Aug 5, 2023

Why not have it a Relationship instead of a property?

That is a reasonable alternative. The advantage of the relationship is that it can be attached to any element and is more flexible.

There are a couple of downsides I can think of:

  • You could have 2 different data license relationships pointing to the same element which could be confusing
  • The data license could be added by someone other than the creator of the element at a later date

If we consider properties to be "intrinsic" to the element and consider the SpdxDocument to represent a "unit of serialization", then I could make arguments both for a property and a relationship depending on your perspective.

  1. If you consider a license being assigned to a serialized SPDX document at creation time and unchanging, then a property is appropriate.
  2. If you consider the serialized data to be independent of a license and different licenses can be applied in different situations, then the relationship is more appropriate.

I personally like the property approach since as a consumer, I can more trust the license not to change over time.

I think of a data license somewhat analogous to having a license statement in a package refer to a URL rather than clearly stating what the license is (e.g. an SPDX ID or notice). As an auditor, this drives me nuts since I have to go to the wayback machine to see which license applied at the time the software was downloaded.

@goneall goneall added serialization Something about the representation of data in bytes Profile:Core Core Profile and related matters Profile:Licensing Licensing Profile and related matters labels Aug 12, 2023
@goneall goneall added this to the 3.0-rc2 milestone Aug 12, 2023
@goneall goneall linked a pull request Nov 3, 2023 that will close this issue
@goneall
Copy link
Member Author

goneall commented Nov 3, 2023

Note this is implemented in PR #490

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Profile:Core Core Profile and related matters Profile:Licensing Licensing Profile and related matters serialization Something about the representation of data in bytes
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants