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

New version: AutocorrelationShell v0.1.2 #31549

Conversation

JuliaRegistrator
Copy link
Contributor

@JuliaRegistrator JuliaRegistrator commented Mar 9, 2021

@github-actions
Copy link
Contributor

github-actions bot commented Mar 9, 2021

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
Copy link
Member

giordano commented Mar 9, 2021

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
Copy link

ShozenD commented Mar 10, 2021

@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
Copy link

ShozenD commented Mar 11, 2021

@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
Copy link
Member

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
Copy link
Member

DilumAluthge commented Mar 11, 2021

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
Copy link
Member

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
Copy link

ShozenD commented Mar 11, 2021

@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
Copy link
Contributor

StefanKarpinski commented Mar 22, 2021

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.

UUID: 69d4c476-349e-11e9-22d5-d17d72ccee3f
Repo: https://github.com/ShozenD/AutocorrelationShell.jl.git
Tree: 84dc3e8d04f3b7596a2bfd400bc9c5a74eb9ddbe

Registrator tree SHA: e934b8c55381f28735124f23e8f7e96d09b20416
@JuliaRegistrator JuliaRegistrator force-pushed the registrator/autocorrelationshell/69d4c476/v0.1.2 branch from b06ad8a to 1e89080 Compare April 18, 2021 05:05
@JuliaRegistrator JuliaRegistrator temporarily deployed to stopwatch April 18, 2021 05:05 Inactive
@github-actions
Copy link
Contributor

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 github-actions bot added the stale label May 18, 2021
@github-actions
Copy link
Contributor

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]

@github-actions github-actions bot closed this May 26, 2021
@github-actions github-actions bot deleted the registrator/autocorrelationshell/69d4c476/v0.1.2 branch May 26, 2021 13:03
ericphanson added a commit that referenced this pull request Jul 22, 2022
Based on #31549 (comment) and #31549 (comment), which I also link to in the answer
ericphanson added a commit that referenced this pull request Jul 22, 2022
* Add license FAQ question

Based on #31549 (comment) and #31549 (comment), which I also link to in the answer

* Update README.md

Co-authored-by: Fredrik Ekre <ekrefredrik@gmail.com>

* Update README.md

* Update README.md

* Update README.md

* Update README.md

Co-authored-by: Fredrik Ekre <ekrefredrik@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants