D19565: kconfig_compiler: new kcfgc args HeaderExtension & SourceExtension

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D19565#678804 , @alex wrote:
  
  > However the option seems pretty unused, even from a github search: 
https://github.com/search?q=HeaderExtension%3D+extension%3Akcfgc&type=Code&ref=advsearch&l=&l=
  
  
  In comparison to how many non KDE users of kconfigcompiler? ;) Also is github 
only giving a partial view of the world with htose fine with MS GitHub or 
having put their code in public anyway. After all KF is LGPL, to allow 
in-house/proprietary use. And those often have their subcultures using their 
own peferred suffices, I found :) ).
  
  >> KF targets also consumers outside of KDE spheres
  > 
  > Also I think there are currently quite a lot of kcfgc options, which makes 
is more difficult to work with IMHO. That might also be more true for third 
party users which are not very familiar with the API.
  
  Can you report any who were confused by those rather straightforward options? 
I would expect almost all are not challenged by those bits, removing them 
should not imrpive their experience a lot. Do we have reports/research?
  
  > Though from having a quick look it seems like (pretty much all) of those 
headers are not using any of KDE/Qt libs. Which means that they would not be a 
very likely audience anyways.
  
  I was giving you examples of what C++ developers use. And it's C++ developer 
who are the primary target of our libraries, as everyone else has a hard time 
due to no real bindings.
  
  > If we want to attract our frameworks to more users, making them slimmer is 
also a possibility one needs to consider.
  
  I would not agree that cutting features and reducing flexibility makes things 
more attractive to others. Rather the opposite. Why using a primitive solution 
that only partially fits when one can instead do a home-grown perfect fit with 
full control...

REPOSITORY
  R237 KConfig

REVISION DETAIL
  https://phabricator.kde.org/D19565

To: kossebau, #frameworks, apol
Cc: alex, apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ahmadsamir, 
ngraham, bruns, vkrause

D19565: kconfig_compiler: new kcfgc args HeaderExtension & SourceExtension

[Alexander Lohnau]

alex added a comment.


  However the option seems pretty unused, even from a github search: 
https://github.com/search?q=HeaderExtension%3D+extension%3Akcfgc&type=Code&ref=advsearch&l=&l=
  
  > KF targets also consumers outside of KDE spheres
  
  Also I think there are currently quite a lot of kcfgc options, which makes is 
more difficult to work with IMHO. That might also be more true for third party 
users which are not very familiar with the API.
  
  > to see that developers of other projects prefer those suffixes for C++ 
headers. Using .h, so the same suffix as used for C headers
  
  Though from having a quick look it seems like (pretty much all) of those 
headers are not using any of KDE/Qt libs. Which means that they would not be a 
very likely audience anyways.
  If we want to attract our frameworks to more users, making them slimmer is 
also a possibility one needs to consider.

REPOSITORY
  R237 KConfig

REVISION DETAIL
  https://phabricator.kde.org/D19565

To: kossebau, #frameworks, apol
Cc: alex, apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ahmadsamir, 
ngraham, bruns, vkrause

Re: Extending the license policy to include ODbL-1.0

[David Faure]

+1

On mercredi 15 septembre 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


-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5