Re: pkgsrc-wip: misc/DeepSeek-TUI renamed to misc/CodeWhale; editors/fresh 0.3.12

Jonathan Perkin <[email protected]> writes:

> * On 2026-06-10 at 11:16 BST, Alistair Crooks wrote:
>
>>On Mon, Jun 8, 2026 at 17:30 Benny Siegert <[email protected]> wrote:
>>
>>> I disagree that Makefiles are merely metadata and below the threshold of
>>> copyright. Getting the Makefile for a package right is not trivial! They
>>> often contain some amount of code to move stuff around, setting build
>>> variables etc. As such, I consider them code.
>>
>>Yes, you are right about Makefiles, on reflection I agree they should be
>>treated as code
>
> If that's the case, then playing devil's advocate for a moment, why do
> we not have a 2-clause BSD license text at the start of each one?
>
> I don't think we can rely on some overall covering license, given the
> various different licenses used in the tree.  For example bsd.pkg.mk
> is explicitly marked as public domain, some wrapper scripts are
> 3-clause, etc.

Because we haven't been dealing with this as rigorously as hindsight
says we should have.

Copyright law was not written by computer scientists and is ill suited
to files.  A collection of files can be viewed as a work; books don't
(usually) have per-chapter and per-section copyright statements and
licenses.  Code is copyrighted by virtue of being a creative work fixed
in a tangible medium, and it's copyrighted regardless of a copyright
marking or a license.

The idea that a repo has a top-level copyright statement and license,
saying that the license applies unless a file explicitly has a different
license, seems reasonable.  pkgsrc isn't really there, but it's clear
from the guide and group practice.

And, if a file lacks a copyright statement and a license, under what I
think is your interpretation, it can't be copied at all, vs being PD.
(Plus, PD is US concept and is not portable to other Berne Convention
countries, a complexity like EU/UK having moral rights and the US not.)

Whether it is good/reasonable practice to refrain from full-on marking
is a different question, but I think it's separable from whether we
believe that Makefiles are in general subject to copyright.

I think many Makefiles are obviously over the line in terms of enough
create content to be copyrightable.  I can see an argument that there
might be some that aren't (pypi when url2pkg works without editing?),
but I do not believe that argument can reasonably be generalized to
"Makefiles are considered not copyrightable".

I think we have consensus:

  VERY STRONG: no LLM in mk, doc, packages that are maintained natively
  in pkgsrc, etc.

  ROUGH: no LLM in Makefiles.  (This follows the board@ guidance
  on LLM, so I see it as existing policy even if some people think it's
  too strict a rule.)

  STRONG: ok to have not very big vibe-coded patches from upstream
  channels (including those posted upstream as part of being added)

  STRONG: ok to take upstream text for DESCR and COMMENT (one line is
  below threshold, and usually we rewrite COMMENT anyway to be concise)

  UNCLEAR: ok to have vibe-coded patches that are not part of upstram
  at all

  UNCLEAR: ok to have really big vibe-coded patches from usptream, that
  are clearly copyrightable like adding features

The wrinkle is that the LLM concern is about ensuring that what TNF
distributes as pkgsrc can be properly distributed.  We re-distribute
distfiles and binary packages, but if one of those turns out to be off,
we can stop, and that seems different than the contents of pkgsrc
itself.  The problem with patches is that they are logically upstream
but carried with pkgsrc.

I propose to adopt the first 4 as policy, and to say that the lsat two
are not ok.  The last one - big LLM patches - seems like it really
should be avoided.  The "LLM patches not part of upstream" I am not
really sure if it is needed or not, but we already have a policy that
patches be sent upstream -- so saying no doesn't hurt, because after
following the other policy, the "no LLM patches not part of upstream" is
moot.