New version: AutocorrelationShell v0.1.2

[JuliaRegistrator]

• Registering package: AutocorrelationShell
• Repository: https://github.com/ShozenD/AutocorrelationShell.jl
• Created by: @ShozenD
• Version: v0.1.2
• Commit: 347aab76e82673986879c62e791907eb3e1efe77
• Reviewed by: @ShozenD
• Reference: Register ShozenD/AutocorrelationShell.jl#1 (comment)

[github-actions]

Your new version pull request met all of the guidelines for auto-merging and is scheduled to be merged in the next round.

---

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment.

[giordano]

Hi @ShozenD, thanks for you contribution! Please see the message above. In particular, note your package doesn't have an OSI-approved license, but your package has a custom license which restricts usage under certain conditions. While it wasn't meant to allow packages without an OSI-approved in the registry, this hasn't been automatically checked or enforced until recently and we no longer accept packages without such a license. You have a few options:

1. relicense your package using an OSI-approved license so that new versions can be included in General
2. host your package on your own registry (LocalRegistry.jl can help you with this)
3. not register the new version anywhere and let the users install your package with the URL: ]add https://github.com/ShozenD/AutocorrelationShell.jl (this will always be possible)

At the moment we don't plan to yank or remove previous versions of packages without an OSI-approved license, but this may change in the future.

Note that if you want to register a new version of your package in the General registry, you should address also the other points raised by AutoMerge (missing compat bound for CSV, and did you skip the version on purpose?)

[noblock]

[ShozenD]

@giordano Thank you so much for reviewing our package and pointing out the issues! I am currently working with my supervisors and colleagues to fix these problems!

[ShozenD]

@giordano I have talked with some people about the license issue. Is the JuliaRegistry willing to accept packages with a BSD license with an added restriction on commercialization? While we would like to keep this package open-source(in the name of science) and on the JuliaRegistry, it was developed in part under a university grant and this requires an added clause.

[DilumAluthge]

Unfortunately, the license must be in the list of licenses approved by the OSI. A full list is here: https://opensource.org/licenses/alphabetical

Are there any licenses in that list that would be acceptable for your use case?

[DilumAluthge]

Maybe something like the GPL, AGPL, or EUPL would work for your purposes? All three of those are OSI-approved.

(I am not a lawyer, and this is not legal advice.)

[giordano]

To be clear, a license like GPL does allow commercialisation, but its nature makes commercialisation of a GPL software relatively impractical.

Also, to explain the rationale of sticking to OSI-approved license: this registry is maintained by volunteers, we don't have a legal team that can thoroughly review any added clause, as simple as it may seem to you. Restriction of use (like no commercialisation), however, often goes against some definitions of open source software (it certainly violates one of the freedoms in the definition of free software). Simply using OSI-approved licenses with no added custom clauses is the best way for us to ensure we have packages legally sounding license.

[ShozenD]

@DilumAluthge @giordano Thank you very much for your suggestions and clarifications! and I see your point. I'm currently in contact with the software license/patent office at the university to see if we can use the license you suggested!

[StefanKarpinski]

I will add here that any "no commercialization" clause is almost certain to conflict with the GPL: the GPL requires that the derived work be available under terms compatible with the GPL, which guarantees a wide range of freedoms, regardless of the nature of the application. Since Julia by default ships with GPL libraries, it is very likely that any work derived from a package with this license would be illegal. While it's probably ok to have the end user load the package themselves, it is likely that any application that includes the package would not be legal. It would be necessary to compile a no-GPL version of Julia from source in order to legally create a work derived from the package.

This is one of the reasons we don't allow non-OSI licenses: it is very easy accidentally wander into legally murky territory when combining common OSI licenses like GPL with non-OSI licenses and we don't want to subject Julia users to that hazard when installing packages registered in General. Even within OSI, there are combinations of OSI licenses which are not legal to use, such as GPL2 with Apache2. Fortunately these days Julia itself is mostly GPL-free and the remaining GPL dependency (SuiteSparse) is GPL2+ which is compatible with Apache2 since GPL3 was carefully crafted to avoid the incompatibility. I'm not aware of any OSI-approved licenses that are incompatible with Julia, but essentially any non-open clause is incompatible because of the GPL2+ dependency. Even if we completely removed all GPL dependencies from Julia itself (a long-standing project), since there are GPL packages in General, we would still not allow non-OSI packages since they are so likely to be illegal to combine with GPL packages in General.

[github-actions]

This pull request has been inactive for 30 days and will be automatically closed 7 days from now. If this pull request should not be closed, please either (1) fix the AutoMerge issues and re-trigger Registrator, which will automatically update the pull request, or (2) post a comment explaining why you would like this pull request to be manually merged. [noblock]

[github-actions]

This pull request has been inactive for more than 30 days and has automatically been closed. Feel free to register your package or version again once you fix the AutoMerge issues. [noblock]