Re: Extending the license policy to include ODbL-1.0
Thanks! Could you please update the changelog section https://community.kde.org/Policies/Licensing_Policy#Changelog ? On Wed, Sep 22, 2021 at 5:38 PM Volker Krause wrote: > > Thanks everyone, I've added the suggested change to the wiki now. > > Regards, > Volker > > On Mittwoch, 15. September 2021 17:26:57 CEST Volker Krause wrote: > > Hi, > > > > there's a MR [1] for ki18n containing data tables generated from OSM data, > > which implies the ODbL-1.0 license [2]. We also already have other places > > ([3], [4]) actually doing this. > > > > However that's a license not yet covered by our license policy, so I suggest > > we add it. > > > > ODbL is essentially LGPL-y but for data rather than code, so conceptually > > compatible with our existing licensing. > > > > It's also not like there's any viable alternative to OSM data, so not doing > > this would imply not being able to implement features integrating > > OSM-derived data. > > > > The proposed addition to the policy section of https://community.kde.org/ > > Policies/Licensing_Policy would be: > > > > > > # ''Geographic data'', in particular data based on or derived from > > OpenStreetMap may be licensed under the '''[https://spdx.org/licenses/ > > ODbL-1.0.html Open Data Commons Open Database License v1.0]'''. > > > > > > What do you think? > > > > Regards, > > Volker > > > > [1] https://invent.kde.org/frameworks/ki18n/-/merge_requests/19 > > [2] https://spdx.org/licenses/ODbL-1.0.html > > [3] https://invent.kde.org/pim/kitinerary/-/blob/master/src/lib/knowledgedb/ > > timezonedb_data.cpp > > [4] https://invent.kde.org/libraries/kpublictransport/-/blob/master/src/lib/ > > knowledgedb/linemetadata_data.cpp > -- Alexander Potashev
Re: Extending the license policy to include ODbL-1.0
Thanks everyone, I've added the suggested change to the wiki now. Regards, Volker On Mittwoch, 15. September 2021 17:26:57 CEST Volker Krause wrote: > Hi, > > there's a MR [1] for ki18n containing data tables generated from OSM data, > which implies the ODbL-1.0 license [2]. We also already have other places > ([3], [4]) actually doing this. > > However that's a license not yet covered by our license policy, so I suggest > we add it. > > ODbL is essentially LGPL-y but for data rather than code, so conceptually > compatible with our existing licensing. > > It's also not like there's any viable alternative to OSM data, so not doing > this would imply not being able to implement features integrating > OSM-derived data. > > The proposed addition to the policy section of https://community.kde.org/ > Policies/Licensing_Policy would be: > > > # ''Geographic data'', in particular data based on or derived from > OpenStreetMap may be licensed under the '''[https://spdx.org/licenses/ > ODbL-1.0.html Open Data Commons Open Database License v1.0]'''. > > > What do you think? > > Regards, > Volker > > [1] https://invent.kde.org/frameworks/ki18n/-/merge_requests/19 > [2] https://spdx.org/licenses/ODbL-1.0.html > [3] https://invent.kde.org/pim/kitinerary/-/blob/master/src/lib/knowledgedb/ > timezonedb_data.cpp > [4] https://invent.kde.org/libraries/kpublictransport/-/blob/master/src/lib/ > knowledgedb/linemetadata_data.cpp signature.asc Description: This is a digitally signed message part.
Re: Extending the license policy to include Apache-2.0
On Wed, 22 Sept 2021 at 13:40, Luigi Toscano wrote: > Jonathan Riddell ha scritto: > > I don't think it needs to be restricted to infrastructural tooling, > maybe just > > a line somewhere saying Apache 2 is an option if needed for code sharing > > compatibility with third party projects. > > That still prevents the usage of Apache 2.0 from scratch, as someone could > always say you can use MIT for a new project which uses Apache 2.0. > Right, I don't think we should allow Apache 2 for new projects unless it's needed to help with an external 3rd party project, that reduces the ability or ease of doing code sharing within KDE and doesn't seem to benefit in any way. Jonathan
Re: Extending the license policy to include Apache-2.0
Jonathan Riddell ha scritto: > I don't think it needs to be restricted to infrastructural tooling, maybe just > a line somewhere saying Apache 2 is an option if needed for code sharing > compatibility with third party projects. That still prevents the usage of Apache 2.0 from scratch, as someone could always say you can use MIT for a new project which uses Apache 2.0. -- Luigi
Re: Extending the license policy to include Apache-2.0
I don't think it needs to be restricted to infrastructural tooling, maybe just a line somewhere saying Apache 2 is an option if needed for code sharing compatibility with third party projects. Jonathan
Re: Extending the license policy to include Apache-2.0
Jonathan Riddell ha scritto: > I think I'd be against adding it to the policy, the aim of the policy has > always been to keep it simple which licence to use so ensure code and be > swapped around within and outwith KDE with minimal worry about different > licences. Apache 2 doesn't add any useful use case to our licences that isn't > already covered by another one, it's just a bit more explicit about the > intended uses. > > There's no problem with linking to Apache 2 code such as openssl. When Apache > 2 licenced code is included in KDE because of policies used by other projects > that share the code such as aether-ssas or mycroft that shouldn't be a > problem, we can just note the reason why it's used and make clear the > different licence. Please consider that such a broad "no, you need to justify it every time" basically blocks the usage of this license even for tooling. As pointed out, for example, Apache 2 is widely used in the Python world. Can we please at least have an exception for infrastructural tooling? -- Luigi
Re: Extending the license policy to include Apache-2.0
I think I'd be against adding it to the policy, the aim of the policy has always been to keep it simple which licence to use so ensure code and be swapped around within and outwith KDE with minimal worry about different licences. Apache 2 doesn't add any useful use case to our licences that isn't already covered by another one, it's just a bit more explicit about the intended uses. There's no problem with linking to Apache 2 code such as openssl. When Apache 2 licenced code is included in KDE because of policies used by other projects that share the code such as aether-ssas or mycroft that shouldn't be a problem, we can just note the reason why it's used and make clear the different licence. Jonathan
