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
