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

Can't upload package with license OtherLicense #745

Closed
patapizza opened this issue Apr 20, 2018 · 16 comments · Fixed by #1092
Closed

Can't upload package with license OtherLicense #745

patapizza opened this issue Apr 20, 2018 · 16 comments · Fixed by #1092

Comments

@patapizza
Copy link

Hi,

We can't upload a package with the license OtherLicense anymore:

Invalid package
This server does not accept packages with 'license' field set to e.g. AllRightsReserved. See https://hackage.haskell.org/upload for more information about accepted licenses.

This is related to #710.

Is this not supported anymore by design or is this just a bug?

Thanks!

@gbaz
Copy link
Contributor

gbaz commented Apr 21, 2018

Which OtherLicense in particular are you trying to use?

@l29ah
Copy link

l29ah commented Apr 22, 2018

Yeah, it doesn't let me to upload my WTFPL-licensed code now!

@gbaz
Copy link
Contributor

gbaz commented Apr 23, 2018

as per the discussion here, spdx lets you specify directly WTFPL as a license if you use cabal-version: 2.2: https://www.reddit.com/r/haskell/comments/87t7nn/releasing_packages_as_public_domain_creative/

However, wtfpl isn't osi approved, and I think the current hackage check would filter on that, as opposed to say, the superset of fsf free or osi approved.

cc @phadej @hvr, etc. We probably need a proper trustee discussion on implications of the license policy?

@phadej
Copy link
Contributor

phadej commented Apr 23, 2018 via email

@gbaz
Copy link
Contributor

gbaz commented Apr 24, 2018

My problem is really that changing license policy should have been done by a hackage admin/trustee decision rather than the process we followed, where we didn't get to have that broad discussion. I think we really should kick one off now. Further, there is data on fsf/libre licenses in the spdx datafiles -- just buried in "details". i.e.: https://github.com/spdx/license-list-data/blob/master/json/details/WTFPL.json. Note that cc0 also has the flag, so it would make our allowance of cc0 less ad-hoc to take the union of the two lists, rather than either of them.

@patapizza
Copy link
Author

I'm trying to use OtherLicense as is, as I have a PATENTS file too.

@gbaz
Copy link
Contributor

gbaz commented Apr 24, 2018

For reference, this seems to be the facebook patent license: https://hackage.haskell.org/package/duckling-0.1.4.0/src/PATENTS

Ugh, what a minefield this is :-/

This license was quite controversial when introduced, and subsequently many large facebook projects moved to MIT instead: https://code.facebook.com/posts/300798627056246/relicensing-react-jest-flow-and-immutable-js/

However, I guess not all projects did. This license is, afaik, not in the SPDX list at all, so is "legitimately" an OtherLicense. There is also no analogue to it that we could ask FB to "just" relicense to. Honestly I think it is an icky and problematic license, but I also don't think that it is something that fails to meet our general criteria for an appropriate license for hackage to redistribute.

From this discussion it looks like there's not even a clear single SPDX guideline yet on how to handle this: https://lists.spdx.org/pipermail/spdx-legal/2017-August/002123.html

I think the checking code currently prevents WITH clauses in hackage uploads with spdx: https://github.com/haskell/hackage-server/blob/master/Distribution/Server/Packages/Unpack.hs#L517

Perhaps we should loosen things up to allow these exception clauses?

@patapizza
Copy link
Author

@gbaz Thanks for debugging this. Is there a way to explicitly allow for OtherLicense in Hackage until the SPDX guidelines clear up?

@gbaz
Copy link
Contributor

gbaz commented Apr 26, 2018

I've kicked off a discussion with various hackage admin people. We should be able to sort this out soon-ish, I hope.

@hvr
Copy link
Member

hvr commented Apr 30, 2018

Effective immediately (I just redeployed Hackage a few minutes ago), license: OtherLicense is accepted again for the pre-SPDX cabal spec versions which supported it. This was an unintentional side-effect of updating the licence check to cabal 2.2's SPDX framework; it wasn't intended to affect legacy cabal spec versions before cabal-version: 2.2.

@gbaz
Copy link
Contributor

gbaz commented Apr 30, 2018

I think that should resolve this for now, but we will need a broader discussion to confirm how we intend to handle things as more packages migrate to new cabal-versions that use the spdx framework.

@patapizza
Copy link
Author

Thank you!

@l29ah
Copy link

l29ah commented Jun 8, 2020

Neither I want Hackage to be one more "license approver".

Why do you filter for licenses at all then?

@l29ah
Copy link

l29ah commented Apr 18, 2021

Still an issue today with license: WTFPL:

Error uploading dist-newstyle/sdist/hsendxmpp-0.1.2.5.tar.gz: http code 400
Error: Invalid package

This server does not accept packages with 'license' field set to e.g.
AllRightsReserved. See https://hackage.haskell.org/upload for more information
about accepted licenses.

l29ah added a commit to l29ah/hsendxmpp that referenced this issue Apr 18, 2021
@gbaz
Copy link
Contributor

gbaz commented Jun 7, 2021

I note that the issue is because this is now a cabal 3.0 file, not a legacy 2.2 file. Following the related tickets I see haskell/cabal#6878 is merged and we should be able to start using the new function licenseIsFsfLibre and take the union of osf and fsf as our accepted licenses.

@gbaz
Copy link
Contributor

gbaz commented Aug 12, 2021

Here's what we need to change. Should do it before next release

goSimple (SPDX.ELicenseId lid) = SPDX.licenseIsOsiApproved lid -- allow only OSI approved licenses.

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

Successfully merging a pull request may close this issue.

5 participants