zsh-workers
 help / color / mirror / code / Atom feed
* Integrating the kmod completions upstream
@ 2024-09-08 14:33 Emil Velikov
  2024-09-08 15:58 ` Oliver Kiddle
  0 siblings, 1 reply; 5+ messages in thread
From: Emil Velikov @ 2024-09-08 14:33 UTC (permalink / raw)
  To: zsh-workers

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

At a glance, a few questions come up:
- what is the license of the completion files?
- would the team be comfortable with relicensing under LGPL-2.1-or-later?
- are there any copyright holders which I could/should add in the
files themselves?
- is there a particular process/coordination that you'd suggest?

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

Thanks in advance,
Emil


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Integrating the kmod completions upstream
  2024-09-08 14:33 Integrating the kmod completions upstream Emil Velikov
@ 2024-09-08 15:58 ` Oliver Kiddle
  2024-09-08 20:16   ` Emil Velikov
  0 siblings, 1 reply; 5+ messages in thread
From: Oliver Kiddle @ 2024-09-08 15:58 UTC (permalink / raw)
  To: Emil Velikov; +Cc: zsh-workers

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Integrating the kmod completions upstream
  2024-09-08 15:58 ` Oliver Kiddle
@ 2024-09-08 20:16   ` Emil Velikov
  2024-09-08 21:10     ` Lawrence Velázquez
  2024-09-08 21:35     ` Lawrence Velázquez
  0 siblings, 2 replies; 5+ messages in thread
From: Emil Velikov @ 2024-09-08 20:16 UTC (permalink / raw)
  To: Oliver Kiddle; +Cc: zsh-workers

Greetings Oliver,

Thanks for the prompt reply o/

On Sun, 8 Sept 2024 at 16:58, Oliver Kiddle <opk@zsh.org> wrote:
>
> 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.
>

modutils is the old project which went EOL ~2011 and kmod superseded
it. I don't think it makes much sense to rename at this point.

> > 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.
>

Looking through https://spdx.org/licenses/ - there are a bunch of MIT
variants. Can you let me know which is the correct one?

> > - 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.
>

Right, let me see if upstream kmod is OK with the (to be confirmed)
MIT license. And if needed will get back to you.

> > - 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.
>

Instead of extensive lists, covering decades and dozens of people, I'm
considering adding the following for fish.
What would a zsh equivalent look like - there is no official git repo afaict.

If you can suggest something I can copy/paste that would be great.

```
This file is based on the completion from
https://github.com/fish-shell/fish-shell, git tag 3.7.1.
See the repository for the original authors and copyright holders.

```

> > - 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.
>

Ack will do. As you can see from my other email, upstream dkms was
released with the zsh completion already.

> > 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.
>
Indeed that's my train of thought as well.

> 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.
>
On the other hand, since we're not zsh experts, some of the
micro-optimisations might go away.
Apologies in advance if that happens :-)

Thanks for all the help,
Emil


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Integrating the kmod completions upstream
  2024-09-08 20:16   ` Emil Velikov
@ 2024-09-08 21:10     ` Lawrence Velázquez
  2024-09-08 21:35     ` Lawrence Velázquez
  1 sibling, 0 replies; 5+ messages in thread
From: Lawrence Velázquez @ 2024-09-08 21:10 UTC (permalink / raw)
  To: Emil Velikov; +Cc: Oliver Kiddle, zsh-workers

On Sun, Sep 8, 2024, at 4:16 PM, Emil Velikov wrote:
> On Sun, 8 Sept 2024 at 16:58, Oliver Kiddle <opk@zsh.org> wrote:
>> Emil Velikov wrote:
>> > 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.
>>
>
> Looking through https://spdx.org/licenses/ - there are a bunch of MIT
> variants. Can you let me know which is the correct one?

https://spdx.org/licenses/MIT-Modern-Variant.html except with

	distribute this software and to distribute modified versions
	of this software for any purpose

instead of

	distribute this software and its documentation for any
	purpose

-- 
vq


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Integrating the kmod completions upstream
  2024-09-08 20:16   ` Emil Velikov
  2024-09-08 21:10     ` Lawrence Velázquez
@ 2024-09-08 21:35     ` Lawrence Velázquez
  1 sibling, 0 replies; 5+ messages in thread
From: Lawrence Velázquez @ 2024-09-08 21:35 UTC (permalink / raw)
  To: Emil Velikov; +Cc: Oliver Kiddle, zsh-workers

On Sun, Sep 8, 2024, at 4:16 PM, Emil Velikov wrote:
> On Sun, 8 Sept 2024 at 16:58, Oliver Kiddle <opk@zsh.org> wrote:
>>
>> Emil Velikov wrote:
>> > - 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.
>>
>
> Instead of extensive lists, covering decades and dozens of people, I'm
> considering adding the following for fish.
> What would a zsh equivalent look like - there is no official git repo afaict.

The official repository is here:
https://sourceforge.net/p/zsh/code

and the license in the current release is:
https://sourceforge.net/p/zsh/code/ci/zsh-5.9/tree/LICENCE

-- 
vq


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2024-09-08 21:37 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-09-08 14:33 Integrating the kmod completions upstream Emil Velikov
2024-09-08 15:58 ` Oliver Kiddle
2024-09-08 20:16   ` Emil Velikov
2024-09-08 21:10     ` Lawrence Velázquez
2024-09-08 21:35     ` Lawrence Velázquez

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).