cabal init / cabal check inconsistency in allowed licenses #1074

Open
dudebout opened this Issue Oct 20, 2012 · 12 comments

Comments

Projects
None yet
7 participants
@dudebout

cabal init allows me to specify a license that it does not recognize, by using option 11. However, cabal check, which is used by hackage, rejects an unrecognized field, such as ISC.

@byorgey

This comment has been minimized.

Show comment
Hide comment
@byorgey

byorgey Oct 21, 2012

Member

Thanks for the report. As things currently stand, I'm not sure whether this counts as a bug (or what should be done about it). The specification of the .cabal format allows unrecognized licenses. However, cabal check does not check whether a .cabal file is valid, but whether it would be accepted by Hackage. Hackage apparently does not allow arbitrary licenses. That is, the policy (as implemented -- whether intentional or not) is that only packages with one of a list of recognized license types may be distributed on Hackage.

So it is not technically an inconsistency. The question is whether Hackage should allow unrecognized licenses. I will let others weigh in there.

Member

byorgey commented Oct 21, 2012

Thanks for the report. As things currently stand, I'm not sure whether this counts as a bug (or what should be done about it). The specification of the .cabal format allows unrecognized licenses. However, cabal check does not check whether a .cabal file is valid, but whether it would be accepted by Hackage. Hackage apparently does not allow arbitrary licenses. That is, the policy (as implemented -- whether intentional or not) is that only packages with one of a list of recognized license types may be distributed on Hackage.

So it is not technically an inconsistency. The question is whether Hackage should allow unrecognized licenses. I will let others weigh in there.

@dudebout

This comment has been minimized.

Show comment
Hide comment
@dudebout

dudebout Oct 22, 2012

Ross Paterson told me Hackage was using cabal check to determine if it should accept a package. It seems that we have a circular dependency here ;-)

Ross Paterson told me Hackage was using cabal check to determine if it should accept a package. It seems that we have a circular dependency here ;-)

@byorgey

This comment has been minimized.

Show comment
Hide comment
@byorgey

byorgey Oct 22, 2012

Member

Haha! OK, point taken. =) In any case, it seems to me there are three options:

  1. Change cabal check (and therefore Hackage as well) to accept unrecognized licenses.
  2. Change cabal init so it does not allow specifying an unrecognized license.
  3. Do nothing.

I have chimed in here since as the maintainer of cabal init, I would implement option (2) if that is decided upon. But I am really not sure which option is best. Perhaps someone else with more knowledge about Hackage and the history/reasoning behind the current choice can comment.

Member

byorgey commented Oct 22, 2012

Haha! OK, point taken. =) In any case, it seems to me there are three options:

  1. Change cabal check (and therefore Hackage as well) to accept unrecognized licenses.
  2. Change cabal init so it does not allow specifying an unrecognized license.
  3. Do nothing.

I have chimed in here since as the maintainer of cabal init, I would implement option (2) if that is decided upon. But I am really not sure which option is best. Perhaps someone else with more knowledge about Hackage and the history/reasoning behind the current choice can comment.

@dudebout

This comment has been minimized.

Show comment
Hide comment
@dudebout

dudebout Oct 23, 2012

My only concern with (2) is that unrecognized licences is a feature that has been added in the last version of cabal init. This addresses the following issue: http://www.haskell.org/pipermail/cabal-devel/2011-June/007568.html

On another note, I do not see (3) as an option. Offering a choice in cabal init that cannot be uploaded on Hackage is not really friendly.

My only concern with (2) is that unrecognized licences is a feature that has been added in the last version of cabal init. This addresses the following issue: http://www.haskell.org/pipermail/cabal-devel/2011-June/007568.html

On another note, I do not see (3) as an option. Offering a choice in cabal init that cannot be uploaded on Hackage is not really friendly.

@byorgey

This comment has been minimized.

Show comment
Hide comment
@byorgey

byorgey Oct 23, 2012

Member

Ah, I see. For reference, it looks like the unrecognized license feature was added by @dcoutts in @d448be2c.

Member

byorgey commented Oct 23, 2012

Ah, I see. For reference, it looks like the unrecognized license feature was added by @dcoutts in @d448be2c.

@ttuegel ttuegel added the type: bug label Apr 23, 2015

@ttuegel ttuegel added this to the Cabal-1.24 milestone Apr 23, 2015

@23Skidoo 23Skidoo modified the milestones: Cabal 1.24, Cabal 1.26 Feb 21, 2016

@ezyang ezyang modified the milestone: Cabal 2.0 Sep 6, 2016

@colinwahl

This comment has been minimized.

Show comment
Hide comment
@colinwahl

colinwahl May 6, 2017

Collaborator

Hi all! Has any consensus been reached on where to go with this issue? I would like to begin working on this, if a direction has been decided on.

Collaborator

colinwahl commented May 6, 2017

Hi all! Has any consensus been reached on where to go with this issue? I would like to begin working on this, if a direction has been decided on.

@23Skidoo

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo May 6, 2017

Member

IIRC @dcoutts still thinks that restricting the set of allowed licenses is a good idea.

Member

23Skidoo commented May 6, 2017

IIRC @dcoutts still thinks that restricting the set of allowed licenses is a good idea.

@colinwahl

This comment has been minimized.

Show comment
Hide comment
@colinwahl

colinwahl May 6, 2017

Collaborator

So getting rid of support for Unrecognized Licenses?

Collaborator

colinwahl commented May 6, 2017

So getting rid of support for Unrecognized Licenses?

@23Skidoo

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo May 6, 2017

Member

Not in the .cabal parser (because backwards compat), but changing cabal init is OK.

Member

23Skidoo commented May 6, 2017

Not in the .cabal parser (because backwards compat), but changing cabal init is OK.

@ezyang

This comment has been minimized.

Show comment
Hide comment
@ezyang

ezyang May 7, 2017

Contributor

@colinwahl Yeah. It's a bit goofy because you just fixed the code to handle unparseable unrecognized licenses better, and now you are going to delete the code, but if you are up for it, go for it!

Contributor

ezyang commented May 7, 2017

@colinwahl Yeah. It's a bit goofy because you just fixed the code to handle unparseable unrecognized licenses better, and now you are going to delete the code, but if you are up for it, go for it!

@gbaz

This comment has been minimized.

Show comment
Hide comment
@gbaz

gbaz Feb 7, 2018

Collaborator

This should be obsoleted by the spdx license work, no?

Collaborator

gbaz commented Feb 7, 2018

This should be obsoleted by the spdx license work, no?

@23Skidoo

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo Feb 8, 2018

Member

@phadej, do you agree?

Member

23Skidoo commented Feb 8, 2018

@phadej, do you agree?

@grayjay grayjay changed the title from cabal init / cabal check inconsistency to cabal init / cabal check inconsistency in allowed licenses Jun 11, 2018

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