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 >
