Re: [chrony-dev] Changing License to GPL for candm.h

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-dev Archives ]


On 25.04.23 10:43, Miroslav Lichvar wrote:
On Mon, Apr 24, 2023 at 05:19:09PM +0200, Walfred Tedeschi wrote:
If they agree it would be great. I think even if we consider a library as

described below, being able to rely on a header to build on top it would
easier

the maintenance of the code.
Maybe easier for another project, but I suspect it might make things
more difficult for chrony, e.g. if we needed to move something between
files with different licenses.

I think writing a new header file from scratch and maintaining it
shouldn't be too difficult if you really need it. Maybe it could be
automated with a script generating the names of the fields and their
type.

Maybe it would be better to start a separate libchrony project from
scratch, with less restrictive licensing, simple API, an ABI that
doesn't need to break with future updates, and also support for
previous versions (chronyc supports only the current version). At
least the monitoring part, it shouldn't be too much work. I can look
into it. If it turns out to be working well, we can consider adopting
it in chrony and rewriting chronyc to use it.
Here would you be considering to host the code in the same repository?
A separate repository, at least for start. If it turns out to be
useful and chronyc could easily be ported to it, it would be adopted
to the chrony repository.

I wrote some minimal code to send a request, process the response and
get the fields from the tracking report. It doesn't seem so bad. I'll
add the remaining reports and publish it. Commands could be added
later if there is interest.

n this context, we are also working with an important costumer on a similar topic.

From our last conversations, it did not look like you had priority on that. We could bring more users/customers that would be interested in that tool. If so, would that increase the priority?

At first, would you also be maintaining that code? In a positive case, it might be we would have some good contributions to add, taking good feedback from customer(s).

But also interesting is the license planed for the library, what are you considering as a good license for the library?


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/