License of Hurd's common lisp bindings

[Maxime Devos]

Hi,

I was wondering if the Common Lisp bindings by "Flavio Cruz" would
make a nice start for GNU Guile bindings.  I have questions on the
license: according to

https://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/hurd.asd?h=clisp

the bindings are "GPL v3.0".  Does this mean "GPL v3.0", and only that
version, or is this "GPL v3.0"-or any later version (at your choice etc.)?
Personally, I would prefer "GPL v3.0"-or-later.

Maxime.
p.s. I'm reading mach/message.lisp right now.  Nice interface!
Converting the clisp to scheme shouldn't be much trouble.


signature.asc
Description: This is a digitally signed message part

Re: License of Hurd's common lisp bindings

[Maxime Devos]

On Thu, 2021-02-25 at 22:22 -0800, Flávio Cruz wrote:
> [...]
> On Wed, Feb 24, 2021 at 11:42 AM Maxime Devos  wrote:
> > Hi,
> > 
> > I was wondering if the Common Lisp bindings by "Flavio Cruz" would
> > make a nice start for GNU Guile bindings.  I have questions on the
> > license: according to
> > 
> > https://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/hurd.asd?h=clisp
> > 
> > the bindings are "GPL v3.0".  Does this mean "GPL v3.0", and only that
> > version, or is this "GPL v3.0"-or any later version (at your choice etc.)?
> > Personally, I would prefer "GPL v3.0"-or-later.
> 
> To be frank, I'm not well versed on the consequences of making it GPL
> v3.0-or-later.
> Can you elaborate why you prefer that? I don't have a strong preference and 
> can
> make it "-or-later".

Some pro's and con's of making it "-or-later" as I understand them, and
some links to explanations of other people ...

First, there is the explanation on
<https://www.gnu.org/licenses/gpl-faq.html#VersionThreeOrLater>,
with this pro as I understand it:

* Pro: if for some reason the FSF decides to publish a GPL v4.0
  (after the GPLv2.0 came the GPLv3.0, so it's quite possible
  there will be a GPLv4.0 at some point in the future),
  then the GPLv4.0 will be compatible with "cl-hurd" if "cl-hurd"
  is released as GPLv3.0-or-later.

  Note that the different versions of the GPL are incompatible with
  each other, unless GPL-v$X-or-later is used instead of GPL-v$X-only.

* Con: If the Free Software Foundation becomes evil, then they could
  release a GPLv4.0 that ???.

  I'm a bit at a loss what the ??? would be.  Perhaps a MIT-style
  license?  I would put a link with an explanation on why this
  situation isn't realistic and why (due to legal reasons) the FSF
  cannot stop being the *Free Software* Foundation, but I cannot find
  the link anymore ...

  Also, I believe contributing to the Hurd involves some kind of
  copyright assignment (or something similar) to the FSF,
  so the FSF could decide by itself to release "cl-hurd" as GPLv4.0
  I think.

* Perhaps some other pro's and con's I forgot?

I think I'll use the yet-to-be-written port of "cl-hurd" to Guile Scheme
in some personal projects (https://notabug.org/mdevos/scheme-gnunet)
and use ‘notify ports’
(https://www.gnu.org/software/hurd/gnumach-doc/Message-Send.html#Message-Send)
to reduce blocking in <https://github.com/wingo/fibers> without
requiring threads.  Maybe I'll also use it in GNU Guix for creating
containers.  GNU Guix is GPLv3.0-or-later, so a GPLv3.0-only dependency
may be problematic ...

Thanks,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: License of Hurd's common lisp bindings

[Maxime Devos]

Ricardo Wurmus schreef op do 29-04-2021 om 17:29 [+0200]:
> Hi Maxime,
> 
> are you still interested in working on Guile bindings for the 
> Hurd?

I'm still interested, but the conversion Common Lisp -> Scheme
was a lot more tedious and tricky than expected at first, so I
stopped actively working on it. The last commit was three weeks
ago.

>   If so, do you have a public repository where we could 
> collaborate?

 (branch: scheme-guile)

The current plan is to, in no particular order:

(1) gradually implement more of Common Lisp in "hurd-cl-compat.scm",
such that more code ‘just compiles’ without source code tweaks
(2) when necessary or more convenient, convert the code to Scheme.
For example, Scheme conditions do not support multiple inheritance,
and :before and :after is not supported in GOOPS.
(3) Adjust the public API in mach/, hurd/, ... to Scheme conventions.
For example: foo-p -> foo?, foo-set --> foo-set!.
(4) Add docstrings

If you create an account at notabug.org, I could grant you commit
access, or we could just use the pull request system.  Commits should
be signed. If you create an account, can you send me a PGP-signed
message with your user name to confirm you're not some imposter?

(Your current key is BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC,
right?)

> I second the request for license clarification.  With the GPL, 
> strict versioning without the upgrade clause makes combining works 
> difficult.  One example is the use of Linux code in the Hurd.  If 
> an updated GPLv4 came along, all that GPLv3 only code could not be 
> easily combined with GPLv4 code, which is a complication that is 
> best avoided in the free software realm.

Agreed.  Our intention should probably be documented somewhere and
more formally, in case someone of us meets an untimely demise, preventing
the licensing switch.

Greetings,
Maxime.


Maxime Devos.pgp
Description: application/pgp-encrypted


signature.asc
Description: This is a digitally signed message part

Re: License of Hurd's common lisp bindings

[Maxime Devos]

Ricardo Wurmus schreef op do 29-04-2021 om 23:33 [+0200]:
> [...]
> Are you compiling this on a Hurd system?  Or do you build it on 
> GNU+Linux first?

On GNU+Linux first.  I don't have a good GNU+Hurd setup yet.
I can create a childhurd, but then I still have to send patches
from the childhurd to the parent system somehow .

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: License of Hurd's common lisp bindings

[Maxime Devos]

Ricardo Wurmus schreef op vr 30-04-2021 om 17:19 [+0200]:
> Hi Maxime,
> 
> I looked at the code and wonder if perhaps we should just rewrite 
> the CL code to do without multiple inheritance and instead use 
> compound conditions where necessary.

I don't feel particularily attached to clisp-hurd's usage of conditions.
Whatever works, I guess.

> Another option is to write plain Guile bindings using the CL bindings only 
> for reference.

That's a possibility, sure.  Though I expect practice, I would expect this to be
partially a conversion of clisp -> guile.  For example, mach/mmap.lisp sems 
easy to
convert from clisp to scheme ... which I'll do right now.

I've made a pull request that converts some code from mach/*.scm
in somewhat idiomatic (Guile-)Scheme, using module imports, and sometimes
adding imports.  I left the complicated CLOS / GOOPS and condition bits out
for now, and picked the ‘low-hanging fruit’ (-:.



> There are also a couple of C wrappers in the libs directory, which 
> we would implement differently in Guile (e.g. by using the FFI 
> directly).
> 
> What do you think?
I haven't looked at those yet.  But that seems a good idea, yes.

> I ran into a few minor problems with the build.  I ran “hall dist 
> -x” to generate build system files, but there are errors when 
> running “autoreconf -vif”.
> 
> “doc/scheme-hurd.texi” does not exist,
Fixed.  (Empty for now).

> I also had to manually link the README file with “ln -s README.org 
> README”.
Likewise.

> The real problems start, of course, with the condition types in 
> cffi/src/early-types.lisp etc… :)

I have some hacks for that, though I don't really like them.
They are pushed now. (09cec57a9671c13c13772a89e58fb982c4624e16)
If you run "make cffi.go", it should end up farther than it did
before.

I often encounter issues with (eval-when ...), so I would like to
remove them altogether.  The ones in cffi/src/early-types.scm can
probably be removed if make that a module (cffi early-types).
And maybe make cffi/src/utils.lisp a module as well?

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Regarding copyright assignment to FSF

[Maxime Devos]

Damien Zammit schreef op do 12-08-2021 om 12:18 [+1000]:
> Hi Ludo,

I'm not Ludo, but here's my response anyway.

(I'm interested in doing some small and larger things with the Hurd,
but I keep being occupied by other things and I'm having a hard time
understanding the inner workings ...)

> On 11/8/21 11:01 pm, Ludovic Courtès wrote:
> > It would be interesting to consider dropping the copyright assignment
> > requirement for Hurd/Mach/MiG.  For what remains primarily a hobby
> > project, this looks to me like a hindrance more than anything else.
> 
> I imagine it is slightly inconvenient for new contributors, but not a 
> hindrance in my opinion.
> It ensures that FSF has complete control of the licensing.
> For example, how will FSF upgrade the project to GPLv3 if multiple people 
> hold the copyright?
> (There are plans to remove the GPLv2-only code btw, as Samuel said).

When the code is GPLv2-or-later, replace v2 with v3 in the license notices.
If the code uses GPLv2-only code, first upgrade the GPLv2-only code to 
GPLv3-or-later.

Upgrading the GPLv2-only code might be dificult if multiple people hold
the copyright, so for the GPLv2-only code, it might be a good idea to still
require copyright assignment.

> PS: Why are you promoting a widespread drop of FSF copyright assignment 
> anyway?
> In my opinion, FSF is a better steward for copyright authorship than any 
> company
> would be assuming you are working on free software on an employer's time and 
> don't
> mutually agree with your employer to keep your own authorship.

FWIW, Ludovic does not seem to be promoting assigning copyright to employers.

> Even if you do keep it yourself, it makes it more difficult for anyone to 
> enforce
> the GPL for that project.

A fair point, though I don't know how accurate that is.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part