<div dir="ltr"><div>I'm not against this but the downsides are:</div><div>-it's yet another licence so would add confusion</div><div>-it's incompatible with the GPL 2 so there's an increased risk of incompatible licences interfering with each other</div><div><br></div><div>It doesn't seem to cover any use case that isn't covered by the other permissive licences, it's just a bit more explicit about some of the detail. Can you say why you think it's useful?</div><div><br></div><div>Jonathan</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 20 Oct 2019 at 19:32, Luigi Toscano <<a href="mailto:luigi.toscano@tiscali.it">luigi.toscano@tiscali.it</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
right now the licensing policy does not contain the Apache 2.0 license:<br>
<a href="https://community.kde.org/Policies/Licensing_Policy" rel="noreferrer" target="_blank">https://community.kde.org/Policies/Licensing_Policy</a><br>
<br>
While it may not be really useful for C++ code, the Apache 2.0 license is more<br>
extensively used by the Python community, and it may be useful for<br>
infrastructure scripts. For example, I have in mind a few Python-based scripts<br>
for the i18n infrastructure and it may be useful to use it.<br>
<br>
I feel that adding Apache 2.0 to section 5 of the licensing policy would be<br>
enough for this, but of course we may want to create a special section to<br>
restrict its scope, if we want to avoid its usage in C++ code.<br>
<br>
Of course it may be possible to avoid it and just use pure MIT or BSD when<br>
GPL/LGPL are not used.<br>
<br>
What do you think?<br>
<br>
Ciao<br>
-- <br>
Luigi<br>
</blockquote></div>