If you haven't already noticed please give this a read.

This has been a long time in coming. :)

In short... if you don't utilize an OSI approved SPDX code for @license the server will automatically reject new scripts and script updates for existing scripts. This includes pushes from GitHub via the webhook.

If you have any questions please feel free to ask them right here or have suggestions please feel free to open an issue on Development.

Thanks,
OUJS Staff

Reminder bump.

You should think of adding a message box somewhere on the update script form so people can know about it.

adding a message box somewhere

It's been in the TOS for years with everyone agreeing to it and it's actually as a help template for new scripts as a placeholder now but I only have so much time... plus you have announcements which you seem to have found. :)

Before I went away from dev station I started working on a drop box similar to the .meta.js one in Script Author Tools on every script homepage... so that everyone will know what is accepted easier than visiting external sites but ran out of time to finish before I need a break.

So please be patient and there is currently a ton of notices, so no excuses ;), in which I'll be adding some more over time. ;)

Thanks.

It rejecting alright, but it doesn't tell you why, the script editor just refreshes and all the changes are gone.
I thought it was server malfunction.

... but it doesn't...

be patient... I'll be adding some more over time. ;)

It never has for any rejections. This isn't the first rejection that we have in. The very first one is absence of @name.

the script editor just refreshes and all the changes are gone.

That gets ones attention real quick that it's definitely user error. Again always the way it has been.

Ok, it doesn't work.

My script has:

// @license      MIT; https://opensource.org/licenses/MIT

Script didn't get updated, the previous version is shown instead.

I've tried to change to:

// @license      MIT

Still doesn't work.

I've removed multiple spaces:

// @license MIT

Still no luck.

I even tried to remove this key completely (it states that MIT should be applied by default) and it still doesn't work.

What should I do?

Re: @Styx:

What should I do?

These are the culprit:

// @homepage     http://fanfics.me/index.php?section=blogs&search=%23ffme
// @homepageURL  http://fanfics.me/index.php?section=blogs&search=%23ffme
// @supportURL   http://fanfics.me/index.php?section=blogs&search=%23ffme

I'll see if I can get those validations to work with this edge case in a bit.

Btw we upmix @homepage to @homepageURL... so that is redundant.

Hmmm it looks like the sanitizer dep we utilize doesn't like that encoding. :\ This will take a bit to figure out.

Congrats... you found a bug. I've removed the usage of this dep in these areas in favor of the routine I made last night.

Might be an issue in posts though... http://fanfics.me/index.php?section=blogs&search=%23ffme ... there is your url in between these ellipsis. Will see what it does.

And one more test directly... your site.

So long story short... you were already missing Support and Homepage on your scripts homepage (they are back now)... then I added the storage check yesterday which rejected your script.

Should be good to go now.

Thanks for the report. :)

Re: @Styx:

(it states that MIT should be applied by default)

This is pre @license validation and absolute requirement. MIT is the site default but now everyone must specify it. Those older scripts are still stamped MIT as per the Terms of Service.

@Marti, thanks, it works now (I also removed @homepage per your recommendation).

Though, I think my case actually supports an opinion that rejecting script edit without any error text is not helpful at all.

Re: @Styx:

thanks

Welcome. Solving some of the older issues keeps me from tackling the current site improvements but I'm willing so far.

supports an opinion that rejecting script edit without any error text is not helpful at all.

And I'll remind those who bring this up again of the Terms of Service at https://openuserjs.org/about/Terms-of-Service#etiquette , specifically the "Do my bidding" part and the bullet before that, as well as my third time saying this:

be patient... I'll be adding some more over time. ;)

Because these opinions are treading seriously on the TOS I'm refraining from just removing users at this time. Other Admin+ aren't usually this lenient. Although my patience can be tried especially when people don't read what's already been posted multiple times.

I don't mind answering questions here but I almost missed your issue @Styx because I'm on Development which is where issues like these should be.

Properly presented issues are not complaining about something or forming an opinion. It is using the issue tracker on Development and offering pull requests if you are that impatient.

/adminbox

@Marti, I'd like to apologize if my previous comment made an impression as if I demand something from you. Honestly, I didn't.

I just wanted to point that "rejecting script without error text" is not only confusing, but could waste your time in tries to search a bug in wrong places. For example, I honestly thought that my case was a consequence of license enforcing rule, that's why I've posted it here.

And, of course, I (we) will be patient and will try to support and help you :)

Nevertheless, I will post issues in correct places from now on. Thanks again.

Re: @Marti:

the script editor just refreshes and all the changes are gone.

That gets ones attention real quick that it's definitely user error. Again always the way it has been.

And now it should not be. I've added some preliminary error code pages, which took a few days as you can all see. This is still not finished but it's a start for everyone.

The way the GH webhook works we accept a push request and if it is going to be parsed we do a response of 200. If there is a parsing error we currently have zero way to tell GH that it failed/rejected. I will mull over some thoughts, as I am already doing, for the GH import and see if there is a way of notifying GH but no promises.

Re: @Styx:

but could waste your time in tries to search a bug in wrong places.

Preaching to the choir as the aphorism goes.

I was hoping to keep this announcement on a more positive note but seeing a few stragglers come in with issues.

1. If someones licensing is present in a "fork" to here from another site (including this one)... DO NOT REMOVE IT. This is violating their Copyright and Licensing... and also a Terms of Service (TOS) violation. This is immediate grounds for account removal. If you see one of these please Flag for moderation with your proof and it will be investigated. The licensing is there for your attribution as well as continued hosted publishing rights.

2. If the license header is present and @license does not match that is a TOS violation. I understand that everyone is getting used to this "old" feature here but if a new user (or an older one especially those who are familiar with the @license key from over a decade ago) does this I'll usually make one attempt to get them to fix it in a short period of time... if it merits it. If not the script and possibly the account is eligible for removal.

Please abide by the TOS.

Re: @Marti:

these opinions are treading seriously on the TOS I'm refraining from just removing users at this time. Other Admin+ aren't usually this lenient.

I just want to reaffirm this statement. @Marti is more patient than me, and if he chooses to interact with users, then I will let him handle the situation as he sees fit. But if I see a user making statements that seem to violate the TOS, I will not give them the benefit of the doubt. I will remove them without warning.

Re: @Marti:
Thanks for the reply, I was just saying this because I was wondering (at that time) why I couldn't update my script anymore :D. So I just thought to give an idea so someone else doesn't have to look for the answer.

Anyway, you have your point and as you said, it seems there were more important things to do.

Also, I like the new input for licence in the edit form ;).

Is there some way to specify "GPL-3.0-or-later" as RMS advocates?

https://www.fsf.org/blogs/rms/rms-article-for-claritys-sake-please-dont-say-licensed-under-gnu-gpl-2

Re: @hklene:

Is there some way to specify "GPL-3.0-or-later"

Excellent question and you are ahead of the game. ;) :)

Current SPDX static dependency (dep) is at SPDX v1.x. When jslicense/spdx-osi.json#2 is resolved then we'll be bumping up to SPDX v2.x to accommodate this. If you are on GitHub and are feeling generous with a brief moment of your time please go add a thumbs up on the issue so we can migrate.

In the meantime please use the older version of GPL-3.0+, with the "+" to visually indicate "-or-later". Auto-linker will point to the deprecated SPDX but that will change with SPDX v2.x. The actual license is not deprecated just the SPDX short identifier is.

When our deps are incremented to the latest then GPL-3.0+ (and GPL-3.0 and the like) will no longer be valid... but until then we are using the "old style" which just changed around January 2018.

https://www.fsf.org/blogs/rms/rms-article-for-claritys-sake-please-dont-say-licensed-under-gnu-gpl-2

What's interesting is if you read GPL and you don't specify a version it can be any version. SPDX doesn't cover this use case although it's probably a good thing since GPL-2.0 had issues with TiVo back in the day and that would open up a hole.

See also:

• #1322

Well, I added

// @license     CC-BY-NC-SA-4.0; https://creativecommons.org/licenses/by-nc-sa/4.0/

and got

@license is not OSI primary and compatible in the metadata block(s).

Re: @Ileca:

Suppose there is a question in there. ;) Go to https://openuserjs.org/user/add/scripts/new and see which licenses are available to be primary. It's described at https://openuserjs.org/user/add/scripts#user-block-license with examples specific to your case of dual licensing.