Re: branch master updated: licenses: Export license record.

[zimoun]

On Thu, 23 Apr 2020 at 23:47, Ludovic Courtès <address@hidden> wrote:
> zimoun <address@hidden> skribis:
> > On Thu, 23 Apr 2020 at 21:57, Ludovic Courtès <address@hidden> wrote:
> >
> >> address@hidden skribis:
> >>
> >> > commit f0779922ff260df2404c90504986aa59553154fb
> >> > Author: zimoun <address@hidden>
> >> > AuthorDate: Thu Apr 23 16:09:00 2020 +0200
> >> >
> >> >     licenses: Export license record.
> >> >
> >> >     * guix/licenses.scm (<license>): Export it.
> >> >
> >> >     Signed-off-by: Mathieu Othacehe <address@hidden>
> >>
> >> > -  #:export (license? license-name license-uri license-comment
> >> > +  #:export (license license? license-name license-uri license-comment
> >>
> >> I see two issues:
> >>
> >>   1. The commit log doesn’t match the change.  :-)
> >
> > Which part?
>
> ‘<license>’ vs. ‘license’.

My bad.
I misunderstood because the term exported is 'license'.

>
> >>   2. It’s on purpose that the constructor is not exported.  It’s so that
> >>      genuine license objects have to be defined here.  (Likewise, record
> >>      type descriptors like <license> are generally kept private to
> >>      maintain encapsulation.)
> >
> > How to extend the list by custom licenses without defining them there?
>
> Like I wrote, it’s not possible, except via a procedure like ‘fsf-free’
> or ‘fsdg-compatible’.

Why the licenses of custom packages living in custom channels can only
be 'fsf-free' or 'fsdg-compatible'?
I understand about the packages that Guix provides.
But not for custom channels.


> >> I’m in favor of reverting.

Sorry, I did not think that the subject was so touchy. :-)
You could revert until we reach a consensus.


> >> What’s the use case, Simon?  (Apologies if I missed the discussion!)
> >
> > I want to be able to have custom licenses for custom packages living
> > in custom channels.
> >
> > More or less for example such use case; for reference [1].
> >
> > (define-module (my-module)
> >   #:use-module (guix packages)
> >   #:use-module (guix licenses)
> >   #:use-module (gnu packages))
> >
> > (define mine
> >   (license "mine"
> >        "https://my.domain.com";
> >        "My weird license that no one uses"))
>
> I see.  I guess one of the procedures above would work, right?

You mean apply 'fsf-free' or 'fsdg-compatible' to all these custom
licenses, right?

Then it is more difficult to filter because all the custom licenses
are FSF-free or FSDG-compatible.

And from a custom channel point of view, I am not sure to be
interested to look after what the FSF considers free or not. (I mean,
personally, I am; generally speaking for e.g., a scientist developing
scientific code in academic context.)


> > My point is: license should not be different from the API point of
> > view than origin or package records; for extension purpose.
>
> Not exposing the ‘license’ constructor allows us to make sure that, for
> instance, there’s only one <license> record for each license.

Other concrete examples from custom channels: the ugly [a] or the tricky [b].

--8<---------------cut here---------------start------------->8---
(license (nonfree:non-free
          (string-append "http://support.illumina.com/content/dam";
                         "/illumina-support/documents/documentation"
                         "/software_documentation/bcl2fastq/"
                         "bcl2fastq2-v2-16-EULA.pdf")
          "This is an extremely restrictive license and it would
be better to avoid using this proprietary program.  I encourage people
to write a free software alternative rather than using this tool."))
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
(define license (@@ (guix licenses) license))
--8<---------------cut here---------------end--------------->8---


[a] 
https://github.com/BIMSBbioinfo/guix-bimsb-nonfree/blob/master/bimsb/packages/bioinformatics-nonfree.scm#L145
[b] 
https://github.com/BIMSBbioinfo/guix-bimsb-nonfree/blob/master/guix/licenses-nonfree.scm#L34


> And we gladly accept additions to that file!  :-)

Do really we? :-)

For example, are we ready to include Artistic 1.0 [c]? To name one
commonly used in the BioConductor archive.

[c] https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00400.html


> How does that sound?

I agree that licenses.scm has to only list free licenses.
I agree that exposing the constructor should lead to conflicts -- even
if I am not convinced.
I disagree to constraint to only the licenses in licenses.scm for
custom packages -- or to use the ugly or the tricky to license these
very custom packages.


Does it make sense to add and export a new procedure? e.g., in licenses.scm

--8<---------------cut here---------------start------------->8---
(define (custom-license name uri comment)
  (license
    name
    uri
    (string-append "Check free blabla " comment)))
--8<---------------cut here---------------end--------------->8---

and then in custom channels

--8<---------------cut here---------------start------------->8---
(define mine
  (custom-license "Mine" "http" "beurk"))
--8<---------------cut here---------------end--------------->8---


Even if I find the exposition of the license constructor the least
controversial because it is up to the custom channel to do right and
its responsability if they does not.


What do you think?


Cheers,
simon