20:40:49 <m-relay> <a​rticmine:monero.social> A combination of LGPL v2.1 and LGPL v3 code can only be released under GPL v3, which does propagate. 
20:40:50 <m-relay> <a​rticmine:monero.social> https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
20:40:52 <m-relay> <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. 
20:40:54 <m-relay> <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.
20:44:50 <m-relay> <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
20:59:30 <m-relay> <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.
21:01:32 <m-relay> <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
21:58:08 <m-relay> <k​ayabanerve:matrix.org> 1) I agree to contestants licensing upon submission, not after
21:58:08 <m-relay> <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.
21:59:01 <m-relay> <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.
23:06:10 <m-relay> <a​rticmine:monero.social> I am fine with MIT.