-
Notifications
You must be signed in to change notification settings - Fork 287
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
Conversation
useless space
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. |
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. |
@mlinksva Agree that the build error is probably transient. I just restarted the build. |
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. |
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? |
I added issue #1176 to track the CI failures - please add any related findings, comments, suggestions to that issue. |
@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. |
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) |
/cc @landley |
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... |
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 |
@swinslow does that mean that a PR changing it to a more generic phrasing would be we accepted? |
Forgot about the PR so very late response, sorry. Correct, this PR was about a variant existing in "theory". Keep this PR closed. |
0BSD is just a conditionless ISC, so there can be a chance that some people don't use "/or".