My CRA arguments basically revolve around the "Open Source Steward" from the CRA. As far as I recall, for open source software to be used in commercial projects it must be maintained by a steward. The definition of steward is being discussed but foundations generally meet the requirement, projects run by a single individual do not generally meet this requirement. Basically this section protects businesses from the "One developer project in Nebraska" (see XKCD).
I think that moving forward picocli will probably move to a foundation or will establish some sort of entity that meets the steward requirements. So moving to picocli carries the risk of churn if we have to replace it again later. We should be asking picocli how they are going to deal with the CRA requirements before we jump. Claude On Wed, Jul 17, 2024 at 2:42 AM Ariel Weisberg <ar...@weisberg.ws> wrote: > This particular library doesn't really present transitive dependency > issues. We already manually specify the version of the two dependencies > that look like the runtime dependencies. > > On Tue, Jul 16, 2024, at 11:39 AM, Jeff Jirsa wrote: > > (Answering this as a cassandra person, don’t confuse this reply as > > board/foundation guidance) > > > > The legal landscape is rapidly evolving with the CRA. The answer may > > change in the future, but I think “we have a dependency we ship that’s > > user-accessible and known to be abandoned” is an unhappy state that’s > > indefensible if there’s ever a transitive dependency issue (e.g. log4j > > style “oh who would have guessed that was possible” ). > > > > I’d look at this slightly differently - if someone proposed adding this > > library right now, we’d all say no because it’s unmaintained. That > > alone should be enough justification to fix the obvious problem - if > > it’s unmaintained, let’s remove it before we’re doing it on fire. > > > > > > > >> On Jul 16, 2024, at 8:11 AM, Ariel Weisberg <ar...@weisberg.ws> wrote: > >> > >> Hi, > >> > >> I am pretty torn down the middle on this one. Unmaintained bad, but > also Aleksey is right. If there are few/no dependencies in airline then it > could be "done" given the narrow scope of what it does. > >> > >> It seems to depend on Guava, javax.inject, and findbugs. Seems like we > can probably update the dependencies on our end if there is a security > issue. > >> > >> Can we get clarity from Apache legal on whether simply being > unmaintained will be something we are motivated to fix for legal reasons? > >> > >> If we have the code/prototype now (assuming we settle on Picocli), is > the counter argument "churn bad" as strong? I don't anticipate changing > from one to the other being too bad if someone else is footing the bill so > to speak. Especially if Maxim is willing to take the lead on any bugs that > we might uncover in the switch. > >> > >> Ariel > >> > >> On Mon, Jul 15, 2024, at 2:53 PM, Maxim Muzafarov wrote: > >>> Hello everyone, > >>> > >>> > >>> I want to continue the discussion that was originally started here > >>> [2], however, it's better to move it to a new thread with an > >>> appropriate title, so that everyone is aware of the replacement > >>> library we're trying to agree on. > >>> > >>> The question is: > >>> Does everyone agree with using Picocli as an airlift/airline > >>> replacement for our cli tools? > >>> The prototype to look at is here [1]. > >>> > >>> > >>> The reasons are as follows: > >>> > >>> Why to replace? > >>> > >>> There are several cli tools that rely on the airlift/airline library > >>> to mark up the commands: NodeTool, JMXTool, FullQueryLogTool, > >>> CompactionStress (with the size of the NodeTool dominating the rest of > >>> the tools). The airline is no longer maintained, so we will have to > >>> update it sooner or later anyway. > >>> > >>> > >>> What criteria? > >>> > >>> Before we dive into the pros and cons of each candidate, I think we > >>> have to formulate criteria for the libraries we are considering, based > >>> on what we already have in the source code (from Cassandra's > >>> perspective). This in itself limits the libraries we can consider. > >>> > >>> Criteria can be as follows: > >>> - Library licensing, including risks that it may change in the future > >>> (the asf libs are the safest for us from this perspective); > >>> - Similarity of library design (to the airline). This means that the > >>> closer the libraries are, the easier it is to migrate to them, and the > >>> easier it is to get guarantees that we haven't broken anything. The > >>> further away the libraries are, the more extra code and testing we > >>> need; > >>> - Backward compatibility. The ideal case is where the user doesn't > >>> even notice that a different library is being used under the hood. > >>> This includes both the help output and command output. > >>> > >>> Of course, all libraries need to be known and well-maintained. > >>> > >>> What candidates? > >>> > >>> > >>> Picocli > >>> https://picocli.info/ > >>> > >>> This is the well-known cli library under the Apache 2.0 license, which > >>> is similar to what we have in source code right now. This also means > >>> that the amount of changes (despite the number of the commands) > >>> required to migrate what we have is quite small. > >>> In particular, I would like to point out that: > >>> - It allows us to unbind the jmx-specific command options from the > >>> commands themselves, so that they can be reused in other APIs (my > >>> goal); > >>> - We can customize the help output so that the user doesn't notice > >>> anything while using of the nodetool; > >>> - The cli parser is the same as what we now do with cli arguments. > >>> > >>> This makes the library a good candidate, but leaves open the question > >>> of changing the license of the lib in the future. However, these risks > >>> are relatively small because the CLI library is not a monetizable > >>> thing, as I believe. We can also mitigate the risks copying the lib to > >>> sources, as it mentioned here: > >>> https://picocli.info/#_getting_started > >>> > >>> > >>> commons-cli > >>> https://commons.apache.org/proper/commons-cli/ > >>> > >>> In terms of licenses, it is the easiest candidate for us to use as > >>> it's under the asf, and in fact the library is already used in e.g. > >>> BulkLoader, SSTableExpoert. > >>> However, I'd like to point out the following disadvantages the library > >>> has for our case: > >>> - This is not a drop-in replacement for the airline commands, as the > >>> lib does not have annotation for markup commands. We have to flesh out > >>> all the options we have as java classes, or create our owns; > >>> - Subcommands have to be supported manually, which requires extra > >>> effort to adopt the cli parser (correct me if I'm wrong here). We have > >>> at least several subcommands in the NodeTool e.g. cms describe, cms > >>> snapshot; > >>> - Apart from parsing the cli arguments, we need to manually initialize > >>> the command class and set the input arguments we have. > >>> > >>> > >>> JComannder > >>> https://jcommander.org/ > >>> > >>> The library is licensed under the Apache 2.0 license, so the situation > >>> is the same as for Picocli. Here I'd like to point out a few things I > >>> encountered while prototyping: > >>> - Unbinding the jmx-specific options from commands is quite tricky and > >>> requires touching an internal API (which I won't do). Option > >>> inheritance is not the way to go if we want to have a clear command > >>> hierarchy regardless of the API used. > >>> - We won't be able to inject a Logger (the Output class in terms of > >>> NodeTool) or other abstractions (e.g. MBeans) directly into the > >>> commands, because it doesn't support dependency injection. This is > >>> also part of the activity of reusing the commands in other APIs, for > >>> instance to execute them via CQL; > >>> > >>> More basic in comparison to the Picocli, focusing primarily on simple > >>> annotation-based parsing and subcommands, and won't allow us to reuse > >>> the commands outside of the cli. > >>> > >>> > >>> airline2 > >>> https://github.com/rvesse/airline > >>> > >>> The library is licensed under the Apache 2.0 license, and this is an > >>> attempt to rebuild the original airline library. Currently, this is > >>> not a drop-in replacement, as it has some minor API differences from > >>> the original library. It is also not a better choice for us, as it has > >>> the same drawbacks I mentioned for the previous alternatives, e.g. not > >>> possible to unbind the specific options from the command and use them > >>> only when commands are called from the cli. > >>> > >>> > >>> > >>> > >>> [1] https://github.com/apache/cassandra/pull/2497/files > >>> [2] https://lists.apache.org/thread/m9wfb3gdo9s210824c9rm2ojc9qv9412 >
