> > > Please, no. The inclusion of the third-party code into the project > repository has non-trivial licensing implications. >
I do not think (but correct me if I am wrong) that this is the case. I think once the licence is OK, it has very little implications. The implications are mostly when you redistribute the code, not when you add it to your repository with the appropriate LICENCE information. I don't think ASF cares too much about what is committed in the repo, but what is important (and what as PMC I am responsible for) is what gets into the official release: http://www.apache.org/legal/release-policy.html. I would love to hear what legal has to say about it, but judging from some recent discussions this is very clear from legal point of view they only care about the releases See the answer of Roman who is the "VP, Legal Affairs of ASF: https://issues.apache.org/jira/browse/LEGAL-549?focusedCommentId=17255359&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17255359 Quote: > The most important thing, however, is that this doesn't seem to be a LEGAL issue at all. > How you release what's cooking is your projects business and while there may be helpful practices to learn from all that ASF cares about is that: > > 1. there's a tarball(s) that gets voted on > 2. that tarball(s) gets published on ASF infra The .github code should pretty much never be released as source code release in the ASF infra tarball. So as long the licence allows to copy the code, placing it in you repo has no legal implications. > GitHub Action should be treated not that different from any other project > dependency. > If infra team forbids action reuse from external repositories, then they > should forbid third-party dependencies as well. > You keep repeating it, but it is simply not true. We discussed it already and GitHub actions have far more access than any other dependency because they have potentially uncontrolled access to write to your project. This is unlike any other dependencies which you must explicitly give that permission to. You seem to skip over that fact constantly. This is not an opinion, this is a fact, reality that you must start facing. I am not sure why you do not see this - the answers from INFRA were very clear about it. We are talking about the case that at any point in time your 3rd-party dependency can start making changes to your Github Repository. None of the other dependencies can do that (barring the problem with write access to the repo with checkout which I already reported as critical security to GitHub and I hope they close that). The last problem you can also mitigate by setting 'persist-credentials' to false (which I did). I am sure INFRA will work on a solution to enforce some of those best practices soon as well and you will have no choice by obeying them. > > GitHub Action has virtually the same grants as any other build system > plugin performing the build. > Nope. They have more. They can have implicit (hidden in action.xml) access to write GITHUB_TOKEN which is not controllable by your workflow and is granted on Github Actions scheduler level, not explicitly by the workflow. This is far MORE than any of the dependencies and you seem to ignore this reality constantly. > > Go ahead, shutdown internet connectivity at the ASF build servers, and > require every ASF release to be buildable with access to the ASF repository > only. > Nobody (except you) asks nor proposes that. > > Jarek>Rather than cloning the whole repository to a new repo in 'apache' > they copied and committed the action code into .github/actions/ folder in > their project > > That sounds like a lot of duplication. > So? What's the problem with that > > If the action is cloned to the single Apache repository, then it can be > reused across all the Apache projects. > There are always two sides of reuse. One is removal of duplication but another is coupling that it involves. People often forget that coupling has a hidden cost. In this case, if I DELETE the repo, I will immediately impact all other projects using them. That's hell of a coupling. And to be honest this is precisely what I am going to do. Once we move the actions as subrepos I am going to remove the forks I created. I am going to warn those that I know used it but there might be more people who used it since that I am not aware of. This is a much bigger cost than copying a few hundreds lines of code. Actions are usually rather small On the other hand, if the action is copied to each subfolder, then each > project would have to copy the same > thing again and again :( > So ? Actions are mostly static. We upgraded our actions (besides the intensive effort when I was developing it) maybe 2 or 3 times over the last year. And subrepo greatly helps with that. > > I expect subrepo might result in less than trivial merge conflicts. > Not really. Subrepo only works on the subfolder. If you just "use" the actions, there are never any conflicts, if you switch to a new version, you just bring in the squashed commit (single commit!) of the changes since the last time you got it. The conflict might arise only when you start modifying the action locally but this is the risk you might want to take if you do local modifications and do not care about merging it upstream (which I always do when I modify the code), and subrepo helps with that as well. It separates out the changes you've made from those that were brought from upstream and gives you tools to make a commit in your fork from those changes that you can immediately turn into PR to that upstream repo. Been there, done that. > > Vladimir > -- +48 660 796 129
