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

Make the "/or" optional in "and/or" (0BSD) #1174

Closed
wants to merge 2 commits into from
Closed

Make the "/or" optional in "and/or" (0BSD) #1174

wants to merge 2 commits into from

Conversation

ghost
Copy link

@ghost ghost commented Jan 31, 2021

0BSD is just a conditionless ISC, so there can be a chance that some people don't use "/or".

@mlinksva
Copy link
Contributor

I'm curious what the SPDX philosophy is on pre-documenting/matching variations that could in theory exist in the wild, but haven't been observed yet for a particular license. Unless there's already a predisposition to doing that, I don't love it, though it's just a feeling -- perhaps that pre-documenting variation encourages variation, which is in general a pain.

@mlinksva
Copy link
Contributor

As to the CI failure it looks transient and not related to this PR https://travis-ci.org/github/spdx/license-list-XML/jobs/756942201#L212 if re-run it'd probably pass.

@goneall
Copy link
Member

goneall commented Jan 31, 2021

@mlinksva Agree that the build error is probably transient. I just restarted the build.

@goneall
Copy link
Member

goneall commented Feb 2, 2021

Well ... This doesn't seem to be transient since it failed twice. I also got the same error on a different PR.

I do not get this error when running the same software locally on my machine. It may be something specific to the Travis environment.

@goneall
Copy link
Member

goneall commented Feb 2, 2021

It seems like it is having a problem reading this JSON Context file - which I'm able to access just fine.

@zvr @wking @iamwillbar any ideas?

@goneall
Copy link
Member

goneall commented Feb 4, 2021

I added issue #1176 to track the CI failures - please add any related findings, comments, suggestions to that issue.

@goneall
Copy link
Member

goneall commented Feb 4, 2021

@kem4li The build issue has been resolved in the master branch. If you could merge the changes from master into this PR, it should resolve the issue. Note that the builds have been migrated from travis-ci.org to travis-ci.com.

@jlovejoy
Copy link
Member

jlovejoy commented Feb 5, 2021

I'm curious what the SPDX philosophy is on pre-documenting/matching variations that could in theory exist in the wild, but haven't been observed yet for a particular license.

The general philosophy is that we do not accommodate variations that could exist in theory. That would be a rabbit hole (and potentially veer into legal drafting) that we don't want, nor need to go down :)

Unless the submitter @kem4li can point to actual use of this scenario, we can probably close this?

(also given this license was submitted in its form by the license author, I would defer to his view on this as well)

@waldyrious
Copy link
Contributor

(also given this license was submitted in its form by the license author, I would defer to his view on this as well)

/cc @landley

@landley
Copy link

landley commented Feb 6, 2021

I have no real objection, but don't see the point either?

I got that phrasing from the OpenBSD suggested template license (which got it from ISC), and the point was to minimize the delta from an existing (approved and professionally lawyer-reviewed) license with a single self-contained change. Plus I got Kirk McKusick's permission to call it a BSD license with the original phrasing (https://landley.net/toybox/0bsd-mckusick.txt) and I really don't want to reopen the can of worms that was the OSI approval/naming process either. (Plus the github license recognition regex thing is picky, ala landley/toybox@b31192fd73b3 and I don't want to poke THEM to update either...)

If anything should be optional it should probably be the copyright notice (which is often in the individual files not the license, or in the github metadata), and probably shouldn't specifically be my name but a more generic phrasing in any case. But again, I wasn't going to poke after it shipped...

@swinslow
Copy link
Member

swinslow commented Feb 7, 2021

Thanks all. @jlovejoy, agreed, until there is substantive evidence of this in the wild I don't think we would proactively add markup for matches. I'll go ahead and close this.

@landley Thanks for your comments here. Just as FYI, since the copyright notice in the markup is already within a copyrightText tag, it will already get treated as optional text under SPDX matching guidelines. That's why it shows up as red text on the generated page at https://spdx.org/licenses/0BSD.html.

@swinslow swinslow closed this Feb 7, 2021
@waldyrious
Copy link
Contributor

the copyright notice [...] probably shouldn't specifically be my name but a more generic phrasing in any case.

Just as FYI, since the copyright notice in the markup is already within a copyrightText tag, it will already get treated as optional text under SPDX matching guidelines. That's why it shows up as red text on the generated page at spdx.org/licenses/0BSD.html.

@swinslow does that mean that a PR changing it to a more generic phrasing would be we accepted?

@ghost
Copy link
Author

ghost commented Feb 11, 2021

Forgot about the PR so very late response, sorry.

Correct, this PR was about a variant existing in "theory". Keep this PR closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants