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
next prev 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
* 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 external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.