<a​rticmine:monero.social> A combination of LGPL v2.1 and LGPL v3 code can only be released under GPL v3, which does propagate.

<a​rticmine:monero.social> gnu.org/licenses/gpl-faq.html#AllCompatibility

<a​rticmine:monero.social> The issue here is that we should not be introducing a mishmash of licenses on an ad-hoc basis as part of a contest.

<a​rticmine:monero.social> There is a good case to review the licencing of Monero as a GitHub issue. Furthermore I can see the case for copylefts in certain cases. This in my view needs to be discussed in a manner where we can understand all the ramifications and a consensus can be reached.

<a​rticmine:monero.social> My concern here is that we can easily stumble into a mess by not carefully looking at all the ramifications. In particular we need to dot all the it's and cross all the t's

<a​rticmine:monero.social> As far as the contest is concerned the participants would have to agree beforehand to the 3 clause BSD only if they are successful.

<a​rticmine:monero.social> This should avoid a license hostage situation. As for the license for the submission all that is needed is that the reviews are able to do their work without impediment

<k​ayabanerve:matrix.org> 1) I agree to contestants licensing upon submission, not after

<k​ayabanerve:matrix.org> 2) The existing libs aren't BSD-3 so even if the submissions are licensed BSD-3, it'll create a MIT+BSD-3 package. That's why the prior conment the discussion settled on was to require submissions be MIT licensed.

<k​ayabanerve:matrix.org> I don't mind if submissions are licensed from an entire list, I'm just noting of we are to lock to a single license, we should lock to MIT.

<a​rticmine:monero.social> I am fine with MIT.