agreeing a policy for maintainers and hackageDB

[Gwern Branwen]

On 2008.07.01 22:08:52 +0300, Antti-Juhani Kaijanaho <antti-juhani at kaijanaho.fi> scribbled 2.9K characters:
> (As I've asked before, please don't send me copies of list emails,
> unless you have reason to believe I am not subscribed.)
>
> On Tue, Jul 01, 2008 at 02:03:51PM -0400, Gwern Branwen wrote:
> > The alternative is worse: why is it better to have three values
> > ('Specifically unmaintained', 'Maintained by foo', 'not specified
> > either way/omitted field')?
>
> Arguing by question, hmm?  I think I answered that one in my original
> mail, and you don't give any reason for me to reconsider.
>
> > At least with the omitted field being significant, users can proceed
> > knowing that if there is a maintainer of a package with omitted
> > maintainer field, they haven't been too diligent about packaging the
> > program.
>
> Failing to check for a trivial error is indiligence?  Perhaps.  I prefer
> that such trivial errors be checkable by program - and that requires
> that a missing value is distinct from a null value.

Yes, it is. Given that by the time a package is uploaded to Hackage, a dev will have seen the warnings at least twice (once on the upload, and once for each and every test-compile-from-tarball), a dev would have to be quite unobservant to not even notice it

> > And we already have a situation where omissions are significant.
> > Consider the license: field. If a license isn't specified, it must,
> > legally, be AllRightsReserved. That's the law.
>
> You are making an analogy that supports my position, not yours.
>
> A missing Cabal license field says "there is no information about
> license here", not "all rights reserved": thus, the field distinguishes
> between a missing value and a null value (indeed, if this analogy
> supported your position, there would be no AllRightsReserved value!).

You were the one who was saying that things should be machine checkable. Three values is ambiguous. With an omitted field, either omission or AllRightsReserved is enough to know that the copyright situation is either unclear (and hence you must assume AllRightsReserved) or outright hostile (in which case you cannot use it). Otherwise, omission is just... omission.

If you propose that there should be an explicit Unmaintained value, then any tool or website needs to handle the omitted case; the only reasonable approach is to assume that omitted maintainer field means Unmaintained - at which point all Unmaintained has done is introduce yet more verbosity.

(I actually disagree with AllRightsReserved, but I know enough to pick my battles - there is no way I will be able to convince the Cabal devs to remove the value, when it is in active use and has been for some time; arguing against inaugurating a new value is much more doable.)

> It is true that if the package comes with no license, then you don't
> have any rights beyond what the law provides you (it does some, but it
> depends on the jurisdiction).  However, there are more ways than just
> the Cabal license field to specify your license.

Sure, but do not all Linux package managers (and others) insist on having important metadata in a standard format? To go back to the license example, they do not let the package say ¨oh, the license info is some file 5 directories down and generated by the configure script¨, but it is the file LICENSE, in debian/.

> Personally, I would regard the Cabal license field as informational only
> and check the package for the actual license statement before doing
> anything that requires a license.  Likewise, I would never release a
> Cabal package which contains no license statement beyond the Cabal
> license field.
>
> --
> Antti-Juhani Kaijanaho, Jyväskylä, Finland

--
gwern
Rule TA Morwenstow rita co ERR CTU walburn Fukuyama IRA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.haskell.org/pipermail/libraries/attachments/20080712/5088c829/attachment-0001.bin