<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 24 Mar 2017, at 02:03, Joy Keys via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>> wrote:</div><div class=""><div dir="ltr" class=""><br class=""><div class=""><a href="https://www.openssl.org/blog/blog/2017/03/20/license/" class="">https://www.openssl.org/blog/blog/2017/03/20/license/</a><br class=""></div><div class=""><br class=""></div><div class="">Since ASL v2 is incompatible with GPL2, some projects may seek to use dual license MIT/ASL v2.</div></div></div></blockquote><br class=""></div><div>It's unlikely that such a relicensing will be seen as valid, particularly because they've gone from the "If we don't hear of any objections then we'll assume that means yes". Relicensing of software is particularly challenging in that all contributors need to agree (not just to not disagree) for it to be valid. There have been few situations where open-source software relicensing has gone ahead successfully; other than projects which have CLAs (i.e. 'we give a license to relicense') the only ones that I'm aware of are JUnit and Eclipse, both of which moved from CPL to EPL. And in that particular case, the only way they achieved that was to denote EPL as being a subsequent version of CPL, because they couldn't get positive permission from everyone.</div><div><br class=""></div><div>See also Theo's trolling of relicensing GCC to ISC:</div><div><br class=""></div><div><a href="https://marc.info/?l=openbsd-tech&m=149032069130072" class="">https://marc.info/?l=openbsd-tech&m=149032069130072</a></div><div><br class=""></div><div>Alex</div><br class=""></body></html>