Today, we’re releasing v6 of GitHub Actions for Gradle builds, with an important change to how the caching component is licensed. In this blog post, we explain what’s changing, what it means for you, and where we’re headed.
It’ll be interesting to see if anybody posts what you’re actually up to. I’ve been skimming your terms and conditions and I have no idea. Although the we are consenting to allow you to create derivative works feels… problematic… at this time I’m not entirely convinced that isn’t saying that you can’t create derivative works of people’s source code… From things like stack traces. This article does nothing to alleviate the concerns now that I know this is a thing. Because it basically doesn’t actually say anything about what this impact actually is aside from the fact that hey we’re putting binary blobs in here that you’re not allowed to look at.
The fact that you’re not licensing it with something like the BSL is also pretty telling.
I think I might have to figure out how to pin version 5.
The article fails to mention that the cache is enabled by default!
It can be disabled with cache-disabled: true
To be fully up front, yes. These terms haven’t changed in a while (since the beginning of 2022). Still, with the ToS as it stands…
The clause:
infringes or violates the intellectual property rights or any other rights of anyone else (including Gradle);
is hugely problematic for people like myself, who work on projects like game modding (e.g. Minecraft). If I hadn’t read your ToS I could easily have violated it by allowing this update to go through since, as @albertvaka pointed out, caching enabled by default! Not great!
Also, your entire license grant section is awash with terms I do not like…
worldwide, non-exclusive, perpetual, royalty-free, fully paid, sublicensable and transferable license
Fully paid? I’ve never seen that term show up in any licensing terms before. Very strange…
to use, edit, modify, truncate, aggregate, reproduce, distribute, prepare derivative works of, display, perform, and otherwise fully exploit the User Submissions in connection with this site, the Services and our (and our successors’ and assigns’) businesses
I’m sorry but my content is not for your business to “exploit” as you put it in your own terms.
including after your termination of your account or the Services.
No. If I ask you to delete my data because I’m terminating my account, I’m quite sure that you should not be holding on most or all of it. This would be particularly true in Europe where GDPR applies.
Interesting to note all the above is totally separate from the clauses that relate to adapting content and user submissions for display on other devices, services, and in other media formats…
Suffice to say I will not be upgrading nor using these features going forward.
I am looking for clarification as to what is actually changing. I understand it says that the caching was pulled into a separate action, but I am trying to understand what it means for me to continue using the caching in v6. What difference does it make for me to accept or not the terms of services? Legally (my legal department is asking) what have I agreed to so far and what would change if I accepted the ToS?
I think the TOC should be updated and clarified. As I understand it:
If my interpretation is technically correct, that would mean Gradle ceases to be a viable option to create commercial software. Please explain whether my concerns are valid, and either give a reason why these are not valid concerns or otherwise, how you are going to resolve this?
Gradle != Gradle GitHub Action
So even if that is true (IANAL), you can still use Gradle, just not the Gradle GitHub Action with enabled caching.
The question might be which data counts as “submitted to the service”.
Again, IANAL, but even if you build a sources jar and the jar is cached (which it is not as a Jar task in Gradle by default is not cacheable), the action might use @actions/cache and thus store it in the GHA cache infrastructure, not the Gradle infrastructure. At least the old version did it, no idea what the new version does or will do.
Also, maybe this will cause a revival of GitHub - burrunan/gradle-cache-action: GitHub Action to properly cache ~/.gradle folder · GitHub and similar 3rd party actions. 
Thanks for all of the feedback. We take your concerns seriously, and it’s evident that it’s not clear how the Terms of Use should apply to gradle-actions-caching and gradle/actions/setup-gradle.
We are working to clarify and improve the terms. In the meantime, here’s my non-lawyer assessment of the situation: Clarification on new v6 caching changes · Issue #917 · gradle/actions · GitHub
Really appreciate the clarification! This does a huge amount to alleviate the concerns that seeing this announcement generated.
Apologies for being so harsh up front. In an age where many companies are making decisions that start to passively or actively exploit their userbases I hope it’s understandable why some (myself for example) would be quick to jump to certain conclusions upon seeing these kinds of changes.
I will keep a close eye on things but seeing your statements has restored my confidence, for the time being, in using Gradle’s GitHub actions.
Cheers!