unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Simon Tournier <zimon.toutoune@gmail.com>
To: Ricardo Wurmus <rekado@elephly.net>, guix-devel@gnu.org
Subject: Re: Binary descriptors for OpenCV
Date: Sat, 19 Aug 2023 11:37:08 +0200	[thread overview]
Message-ID: <861qfz1igr.fsf@gmail.com> (raw)
In-Reply-To: <874jlk9kl3.fsf@elephly.net>

Hi,

On Mon, 31 Jul 2023 at 15:12, Ricardo Wurmus <rekado@elephly.net> wrote:

> What shall we do with this patch?  Can we accept it or does it cross a
> line we don’t want to cross?

I concur with Maxim’s message.  If the license is compliant for
redistributing, then I do not see any blocker for inclusion.

Somehow, I do not any difference with the package ’gnubg’ for example;
well my opinion is expressed in this thread [1]:

        The only question for inclusion or not is about the license, IMHO.  For
        sure, it is far better if we are able to recompute the weights.
        However, similarly as debootstrapping is a strong recommendation, the
        ability to recompute the pre-trained neural network weights must just be
        a recommendation.

where “neural network weights” reads in this case “binary descriptors”.

We need to do our best for reducing at most the “opacity” but the
criteria for inclusion is about the license and not about our resource
for bootstrapping all from bare-metal.  To be precise, we are accepting
to “cheat” for some compilers as GHC or Chicken.  From my point of view,
the case of Chicken is very similar to these “descriptors”, no?

Similarly, many packages use Autotools files generated by upstream and
we do not regenerate all of them.  Because that’s not the criteria for
inclusion.  The criteria is about the license, whatever if we speak
about human-readable source code, non human-readable source code, or any
other data.

1: https://yhetil.org/guix/87wn0qrmdx.fsf@gmail.com/#r
2: https://issues.guix.gnu.org/issue/22366

Cheers,
simon


  parent reply	other threads:[~2023-08-19 14:58 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-31 13:12 Binary descriptors for OpenCV Ricardo Wurmus
2023-08-01 14:02 ` Maxim Cournoyer
2023-08-01 14:39   ` Saku Laesvuori
2023-08-19  9:37 ` Simon Tournier [this message]
2023-08-24 15:06   ` Ludovic Courtès
  -- strict thread matches above, loose matches on Subject: below --
2023-08-01  7:21 Nathan Dehnel
2023-08-01 12:14 ` Ricardo Wurmus
2023-08-16 16:55   ` Ludovic Courtès
2023-08-17 21:57     ` Nathan Dehnel
2023-08-17 23:18     ` Maxim Cournoyer
2023-08-24 15:08       ` Ludovic Courtès
2023-08-01 18:50 Nathan Dehnel
2023-08-01 20:37 ` Saku Laesvuori
2023-08-01 20:58   ` Nathan Dehnel
2023-08-02  4:46     ` Saku Laesvuori
2023-08-02 20:25       ` Nathan Dehnel
2023-08-03  6:18         ` Saku Laesvuori

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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=861qfz1igr.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=rekado@elephly.net \
    /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.savannah.gnu.org/cgit/guix.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).