zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <opk@zsh.org>
To: Emil Velikov <emil.l.velikov@gmail.com>
Cc: zsh-workers@zsh.org
Subject: Re: Integrating the kmod completions upstream
Date: Sun, 08 Sep 2024 17:58:00 +0200	[thread overview]
Message-ID: <92928-1725811080.428123@V0ZG.ZDVw.IOkd> (raw)
In-Reply-To: <CACvgo50uv37G1pUVx9RXkvRgOeLHBp7Mzbi=V2OVOTB6Uk_kog@mail.gmail.com>

Emil Velikov wrote:
> Hello team, I'm considering pulling the zsh completion files (as do
> bash and fish fwiw) in the upstream kmod project.

This seems to correspond to the Linux _modutils function in zsh.
(I guess modutils must have been renamed to kmod at some point)
Even if the function stays in zsh, it should be renamed.

> At a glance, a few questions come up:
> - what is the license of the completion files?

Same as the rest of zsh: a variant of the MIT license.

> - would the team be comfortable with relicensing under LGPL-2.1-or-later?

The LGPL is a superset of the zsh license so from a legal standpoint
you can do that. A good portion of the function was written by me and
I don't mind it being changed to match any OSI licence of an upstream
project wanting to pull their completions in. An alternative you might
consider is explicitly dual-licencing the completion file.

> - are there any copyright holders which I could/should add in the
> files themselves?

As a minimum, I would suggest acknowledging in the header that it has
been imported from the zsh project, crediting just "Zsh developers".
About 15 different people have contributed to that function so naming
them all might be a bit much. Or you cut that down to a shorter list.

> - is there a particular process/coordination that you'd suggest?

Not really, just import the function. Have your build system install the
file to $DESTDIR$PREFIX/share/zsh/site-functions and let us know once it
reaches a released version of kmod. It's better that there is an overlap
period when the function is available from both zsh and kmod than a gap
where users get no completion.

> In general, would you recommend me going this route, or perhaps it's
> better to rewrite them from scratch?

Yes, I would recommend that route. In most cases, the upstream project is a
better home for completions because they can better track changes in the
upstream project.

There's no point in duplicating the effort with a rewrite. The
completions included with zsh have the advantage of having been written
by people who know zsh completion well - if not the kmod project well.

Oliver


  reply	other threads:[~2024-09-08 15:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-08 14:33 Emil Velikov
2024-09-08 15:58 ` Oliver Kiddle [this message]
2024-09-08 20:16   ` Emil Velikov
2024-09-08 21:10     ` Lawrence Velázquez
2024-09-08 21:35     ` Lawrence Velázquez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=92928-1725811080.428123@V0ZG.ZDVw.IOkd \
    --to=opk@zsh.org \
    --cc=emil.l.velikov@gmail.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).