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

[zimoun]

Hey Ludo,

On Sun, 26 Apr 2020 at 22:19, Ludovic Courtès <address@hidden> wrote:

> >> Perhaps this suggests we should document it, maybe in the “Coding Style”
> >> section?  WDYT?
>
> I was really thinking about this pattern of not always exposing raw
> record constructors or record type descriptors.

You mean add a bullet point in "Coding Style" saying about record
constructors ``kept private to maintain encapsulation`` as possible.
Grepping 'define-record' and looking if the record is exported, well,
there are some: bag, build-system, store-info, elf-dynamic-info, etc.
or package, origin, etc. and for good reasons I imagine.
Well, it is hard for me to draw a line: why this one is ok and this
other one not.
Therefore, I do not know how to state this or document it in the
"Coding Style" because it seems case-by-case.

As I said, I do not see a difference between package or origin and
license. Except about freedom and you made the point clear. :-)


> > I have read the Channel section again. Maybe there in the big Red Warning 
> > place.
> > Something saying that the API exposes what it necessary to extend
> > respecting user freedom (better worded);
>
> I think this particular bit is implied by the current text, no?

>From my understanding no.

What I understand:
 1. Please submit to Guix instead of creating your own channel.
 2. The API can change so the channel can break.
 3. Broken channel will not be fixed by Guix project.
 4. Channel allows to use user's freedom to extend Guix by their own packages.

What is ambiguous* is the bit: "and to share your improvements, which
are basic tenets of free software." pointing to 'What is free
software?'.

a) I do not understand this bit as: the custom packages defined in
custom channel have to respect the licenses defined by GNU, i.e., only
all the free** or fsf-free or fsdg-compatible ones.
b) I do understand that the underlying license problem is similar than
linking library or the past warning about Emacs package.el*** or the
recent API for extending Emacs in C.

*ambiguous: now we have this discussion. :-)
**free: in the meaning of GNU.
***package.el: however the channel maintainers (MELPA) do not write
"impolite" code as '@@' to license the non-free** packages.


Well, I do not want to reproduce here the pros and cons discussion
about channels nor any licenses debate. And because I do not have
better to suggest as improvement, I propose to let the status quo and
if it is really an issue for me then start to re-read all the
discussion about channels and then open a discussion on guix-devel as
mentioned in the manual. ;-)


> > with a footnote mentioning that non exported functions can be reached
> > with @@ with a reference to the Guile manual.
>
> Using private bindings is always at the user’s own risks, I’ll never
> suggest using @@ to “break the rules”.  :-)

I missed "@@ can be thought of as the impolite version of @ and should
only be used as a last resort or for debugging" in the Guile manual.
:-)


Thank you for all the clarification and helping to clear my mind.
I apologize for that.

Cheers,
simon