Eliminate the Akka CLA?

[dwickern]

Contributors to sbt-native-packager are required to sign the Akka CLA. As far as I know, sbt-native-packager has no relationship with Akka (the product) or Akka (the company, formerly Lightbend/Typesafe). Can we get rid of it?

Other projects in the ecosystem changed their CLA after Akka's license change in 2022:

• Play Framework removed the CLA - https://github.com/orgs/playframework/discussions/11405 Removing CLA from the PR template. playframework/playframework#11407
• Slick removed the CLA - .mergify.yml: don't require signing Lightbend CLA slick/slick#2590
• SBT transferred to the Scala Center and switched to the Scala CLA - Clarity of CLA sbt#7048 Transfer copyright to the Scala Center sbt#7306

@muuki88 @eed3si9n thoughts?

[eed3si9n]

sbt GitHub organization hosts various plugins, under various copyright owners. sbt-native-packager has been maintained by @muuki88, you, and other maintainers for the last 10 years, so I think it's really up to you folks, both technically and ethically, to decide if you want to keep the CLA or not. In the following I can outline some of the historical context and pros/cons.

sbt-native-packager requiring Akka CLA is probably a vestige from the fact that sbt-native-packager was started by Josh Suereth, partly or wholly during the period when Josh worked for Lightbend Inc (then Typesafe, currently dba Akka). So even though the plugin has been fully maintained by the community (mostly Muki) for the last 10 years, if everyone has signed the CLA, technically all of the commits belong to Lightbend at this point.

We can certainly remove that CLA checker, then we will likely fallback to GitHub Terms of Service D-6:

Whenever you add Content to a repository containing notice of a license, you license that Content under the same terms, and you agree that you have the right to license that Content under those terms. If you have a separate agreement to license that Content under different terms, such as a contributor license agreement, that agreement will supersede.

This repository contains such file (https://github.com/sbt/sbt-native-packager/blob/main/LICENSE.md), and it's a BSD 2-Clause "Simplified" License. I'm not a lawyer, but if I'm reading the text correctly, this means that copyright will belong to individual contributors from then, but they will license the public under the same license. sbt project avoided this by transferring the CLA to another CLA that gives ownership to EPFL.

1. If you decide to remove the CLA, I suggest we simultaneously change the LICENSE file to Apache 2.0 with copyright header changed to:

   Copyright (c) 2024 Muki Seiler and contributors
   Copyright (c) 2013-2024 Lightbend Inc (dba Akka)
   Copyright (c) 2012 Joshua Suereth

2. The only minor drawback of removing the CLA is that this plugin would no longer have a single-ish author, which means we won't be able to re-license from it again. And having single-ish author makes it easier to sue someone, but that's not really a concern for plugins, I think.

[muuki88]

Hi folks,

Thanks @dwickern for bringing this up and thanks for the detailed advice and kind words @eed3si9n ❤️

I favor the change to Apache License. From my understanding this wouldn't change anything for plugin users, but only for contributors.

For the record, I want to mention that Derek has been very active in maintaining here 🙏

[dwickern]

Thank you for the advice, Eugene.

My (not a lawyer) understanding is that BSD is compatible with Apache, so we can change the license without keeping any reference to BSD.

Apache 2.0 has a similar clause to the GitHub ToS regarding contributions. It wouldn't hurt to have the clause in this project's license:

5. Submission of Contributions.

Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

Apache seems to have additional restrictions compared to BSD (see BSD 2-Clause vs Apache 2.0):

If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file

Not relevant to us because we don't have a "NOTICE" file.

You must cause any modified files to carry prominent notices stating that You changed the files

This one is tricky. sbt-native-packager's main artifact being licensed/distributed are the shell scripts, and those are intended for users to modify. My goal would be to make it easy for users to comply with the license by default. Should we generate a license header for those files?

#!/usr/bin/env bash
#
# Copyright sbt-native-packager authors (licensed under the Apache License, Version 2.0)
# Modifications Copyright %AUTHOR% (licensed under %LICENSE%)

[eed3si9n]

What I recommend for files that gets distributed to the end user, like Giter8 template is to use CC0 1.0 - https://www.foundweekends.org/giter8/template.html to avoid attribution.

[dwickern]

I don't think we can. The copyright to those files are owned by the respective contributors, with a copyright grant to Lightbend. So we would need permission from every contributor or for Lightbend to exercise the CLA (the same CLA I proposed removing 😅).

[muuki88]

@SethTisue do think this would be possible?

[SethTisue]

Probably. I will ask someone at the company next week.

[SethTisue]

inquiry, sent

[ennru]

Correct, our company Akka (formerly known as Lightbend/Typesafe) has not been engaged much in sbt-native-packager and we have no further interest in it. We are good to remove the CLA and adapt the license and copyright notice in a way that makes sense to its current maintainers.

-- Enno Runne, SVP Engineering @ Akka

[muuki88]

Hi @ennru

Thanks a lot for your statement to go ahead a remove the CLA binding here 🙏 😊