Re: Licensing policy and Apache 2.0
Jonathan Riddell ha scritto: > I'm not against this but the downsides are: > -it's yet another licence so would add confusion > -it's incompatible with the GPL 2 so there's an increased risk of incompatible > licences interfering with each other > > 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? I don't have a specific answer; just consistency with other (python) libraries around. It is not compatible with the GPLv2, but it is fully compatible with GPLv3. (moreover, it has a patent promise). -- Luigi
Re: Licensing policy and Apache 2.0
On Monday, 21 October 2019 12:13:49 CEST Jonathan Riddell wrote: > I'm not against this but the downsides are: > -it's yet another licence so would add confusion > -it's incompatible with the GPL 2 so there's an increased risk of > incompatible licences interfering with each other The incompatibility with GPLv2 is indeed a problem, but one we have to face anyway, due to OpenSSL attempting to relicense to Apache 2. As that's a very fundamental dependency we need to eventually have our entire code Apache 2 compatible I think. (GPLv2-only code isn't actually allowed by the license policy, but it nevertheless still exists in a few places for historic reasons). Regards, Volker > 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? > > Jonathan > > > On Sun, 20 Oct 2019 at 19:32, Luigi Toscano > > wrote: > > Hi, > > > > right now the licensing policy does not contain the Apache 2.0 license: > > https://community.kde.org/Policies/Licensing_Policy > > > > While it may not be really useful for C++ code, the Apache 2.0 license is > > more > > extensively used by the Python community, and it may be useful for > > infrastructure scripts. For example, I have in mind a few Python-based > > scripts > > for the i18n infrastructure and it may be useful to use it. > > > > I feel that adding Apache 2.0 to section 5 of the licensing policy would > > be > > enough for this, but of course we may want to create a special section to > > restrict its scope, if we want to avoid its usage in C++ code. > > > > Of course it may be possible to avoid it and just use pure MIT or BSD when > > GPL/LGPL are not used. > > > > What do you think? > > > > Ciao > > -- > > Luigi signature.asc Description: This is a digitally signed message part.
Re: Licensing policy and Apache 2.0
I'm not against this but the downsides are: -it's yet another licence so would add confusion -it's incompatible with the GPL 2 so there's an increased risk of incompatible licences interfering with each other 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? Jonathan On Sun, 20 Oct 2019 at 19:32, Luigi Toscano wrote: > Hi, > > right now the licensing policy does not contain the Apache 2.0 license: > https://community.kde.org/Policies/Licensing_Policy > > While it may not be really useful for C++ code, the Apache 2.0 license is > more > extensively used by the Python community, and it may be useful for > infrastructure scripts. For example, I have in mind a few Python-based > scripts > for the i18n infrastructure and it may be useful to use it. > > I feel that adding Apache 2.0 to section 5 of the licensing policy would be > enough for this, but of course we may want to create a special section to > restrict its scope, if we want to avoid its usage in C++ code. > > Of course it may be possible to avoid it and just use pure MIT or BSD when > GPL/LGPL are not used. > > What do you think? > > Ciao > -- > Luigi >
Licensing policy and Apache 2.0
Hi, right now the licensing policy does not contain the Apache 2.0 license: https://community.kde.org/Policies/Licensing_Policy While it may not be really useful for C++ code, the Apache 2.0 license is more extensively used by the Python community, and it may be useful for infrastructure scripts. For example, I have in mind a few Python-based scripts for the i18n infrastructure and it may be useful to use it. I feel that adding Apache 2.0 to section 5 of the licensing policy would be enough for this, but of course we may want to create a special section to restrict its scope, if we want to avoid its usage in C++ code. Of course it may be possible to avoid it and just use pure MIT or BSD when GPL/LGPL are not used. What do you think? Ciao -- Luigi
