These should all be done by CI, but CI is only responsible for checking and outputting the results. Like I said above. Knowing that our contributors mainly use Java, if they need a Python environment to check, that's still a challenge for them. maybe just for me :)
Best wishes！ Calvin Kirs On 02/9/2022 13:58，Benedict Jin<[email protected]> wrote： Hi CalvinKirs, Thanks for your comment. Agree, then the v2.0 is enough and we don't need to implement the v3.0 version, and no need automatically modify LICENSE, just as a local tool to help us to generate LICENSE file. After this PR is merged, the overall process becomes: the Github Action with skywalking-eyes still automatically performs checks. If it does not pass, we can generate LICENSE locally through the exec-maven-plugin maven plugin with one step to reduce the user threshold. And we handle these Unknown licenses and source-level dependencies manually. Regards, Benedict Jin On 2022/02/09 05:27:27 CalvinKirs wrote: hi Benedict, This sounds like a very good feature, but as Zhenxu and I said on the PR[1], there will be some detected licenses that are Unknow, but in fact they may still be available, just need our human intervention to check. The other is source-level dependencies. Then there are some dual licenses, and different license declarations, such as AL2, some check results are Apache 2.0, while others are The Apache Software License, Version 2.0, and some such as the check results are Go License, but in fact It is BSD License. I prefer CI check, and output relevant results to remind contributors, and then contributors add the corresponding licenses, such as which licenses we need to add, and which licenses need to be checked by the maintainer. Instead of automatically helping him to add. License compliance is particularly important for an Apache project. In addition, we are currently using skywalking-eyes[2] to do some checks, if these functions can be contributed to SkyWalking-eyes, it may be better so that he can benefit more projects. sure, it's up to you. [1]https://github.com/apache/incubator-seatunnel/pull/1210 [2]https://github.com/apache/skywalking-eyes Best wishes！ Calvin Kirs On 02/9/2022 12:15，Benedict Jin<[email protected]> wrote： It seems that the picture cannot be displayed well, you can see the description of this issue. FYI, https://github.com/apache/incubator-seatunnel/issues/1209 On Wed, 9 Feb 2022 at 12:10, Benedict Jin <[email protected]> wrote: Hi, Here is the SeaTunnel automatically generates LICENSE design, as follows: Background As we all know, the SeaTunnel is a high-performance Data Integration Platform that supports efficient data transformation and transfer between heterogeneous data sources. Therefore, it is inevitable to introduce many third-party dependencies. Therefore, there is also a problem, which is, with more and more third-party components, it will be a very labor-intensive process to manually maintain LICENSE. At the same time, newbies need to learn this LICENSE mechanism, which also increases the entry threshold for newbies. Therefore, this document will introduce a way to automatically generate the LICENSE file. Requirement After preliminary research, some basic requirements have been sorted out: It needs to be implemented in a scripting language to facilitate understanding and maintenance; It can be integrated with the existing Maven build process; It should support Github Action to trigger automatically. Plan Version v1.0 The easiest way is to generate a temporary THIRD-PARTY.txt through Maven’s license-maven-plugin plugin. Then through the Python script, the LICENSE file is automatically parsed and created. Version v2.0 Further through Maven’s exec-maven-plugin plug-in, it supports one-click triggering by using Maven. Version v3.0 Going a step further, we can integrate with Github Action. When a new PR is created, if the dependency changes, Github Action automatically modifies the LICENSE, and creates a commit to submit it to the new PR. In this way, when contributing new plug-ins, users do not need to understand the LICENSE mechanism, all of which are automatically modified, which greatly reduces the threshold for newbies. Conclusion Currently I have created the #1210 PR, which has completed versions v1.0 and v2.0, we need to discuss whether v3.0 needs to be implemented at this stage. And then we can implement v3.0 in a follow-up PR if necessary. Any comments are welcome, thank you very much. Regards, Benedict Jin
