Forbid assigning license for EmbargoedAccess

[yarikoptic]

Seeing a very permissive licenses alongside with Access Information: dandi:EmbargoedAccess on https://gui-staging.dandiarchive.org/#/dandiset/101126/draft made it feel wrong: I can download, forget that it is embargoed, look into metadata for license field, see that is nice free and open and then go sell it for a 1 million $.
I think we should better disallow setting (especially open) license to embargoed dandisets, and setting a license should be a part of the "Unembargo" process: if you assign open license, means dandiset is no longer restricted in its redistribution.

[satra]

remember that the only people who can download are owners of the dandiset. and a license is for others, not owners when embargoed. the dandi archive members don't count as others.

what i would suggest is simply not showing the license on the UI till unembargoed instead of restricting validation at the schema level.

personally i think those two elements mean very different things.

[yarikoptic]

personally i think those two elements mean very different things.

I think they do relate, hence this issue: embargoed status means restrictions to access (and hence redistribution), license (especially open) lists permissions for access and redistribution. Thus they are in conflict ATM from my PoV.

what i would suggest is simply not showing the license on the UI till unembargoed instead of restricting validation at the schema level.

not showing in web UI would then still make it available/visible in dandiset.yaml or metadata dumps from API, thus IMHO would not clarify the situation.

remember that the only people who can download are owners of the dandiset. and a license is for others, not owners when embargoed. the dandi archive members don't count as others.

Indeed license is for the "others", which could be reviewers/collaborators etc. But in some cases, in particular whenever owners have many dandisets, having "conflicting" information in metadata might cause confusion even for the "owners" and thus mistakes (sharing what is not intended yet to be shared etc). That is why I think it would be just cleaner to not have license assigned for embargoed and assigning license as part of "unembargoing" process would streamline it.

[waxlamp]

FWIW, I tend to agree with Yarik, though I don't know how much of a real-world impact this policy would make.

In terms of validation, a license that restricts distribution while under embargo would allow for embargoed assets to pass validation (but unembargoed assets under that license would fail to validate). Alternatively, we could allow for non-licensed assets (thus, implicitly "all rights reserved" to the owners) to pass validation only if embargoed. Then, upon unembargo, we either force a license choice or allow the unembargoed asset to fail validation, thus prompting the owner for a license choice.

To balance against all this: we already treat the review of embargoed data as a kind of trust imbued in the reviewer. If such a reviewer has a tendency to sell other folks' scientific data just because it's CC-licensed, they probably shouldn't be entrusted with such reviews in the first place. This is what I meant above about real-world impact.

[djarecka]

should we have a separate class for embargoed dandisets?

[satra]

perhaps just override the validation of license.