New license request: FSL-1.1-Apache-2.0 [SPDX-Online-Tools]

[chadwhitacre]

1. License Name: Functional Source License v1.1 (Apache 2.0 Future License)
2. Short identifier: FSL-1.1-Apache-2.0
3. License Author or steward: Functional Software, Inc. dba Sentry
4. Comments: Functional Source License is a new license stewarded by Sentry (Functional Software is our legal name). It is in the lineage of the Business Source License (BUSL-1.1), but without the parameterization of BUSL. There is a fixed usage restriction (Competing Use), a fixed time period (two years), and only two possible future licenses (Apache 2.0 or MIT).

Looking at the definitive factors for inclusion:

A. FSL-1.1-Apache-2.0 does not match another license already on the SPDX License List as per the SPDX matching guidelines.

B. FSL-1.1-Apache-2.0 is not an OSI-approved license.

C. FSL-1.1-Apache-2.0 does not apply only to executables; it provides for the availability of the source code.

D. FSL-1.1-Apache-2.0 has identifiable and stable text; it is not in the midst of drafting.

E. The FSL-1.1-Apache-2.0 steward is committed to not modifying after addition to the list and to versioning new versions in the future.
5. License Request Url: http://tools.spdx.org/app/license_requests/366
6. URL(s): https://fsl.software/FSL-1.1-Apache-2.0.template.md
7. OSI Status: Not Submitted
8. Example Projects: https://github.com/codecov/self-hosted?tab=License-1-ov-file#readme, https://github.com/get-convex/convex-backend?tab=License-1-ov-file#readme, https://github.com/getsentry/self-hosted?tab=License-1-ov-file#readme

[chadwhitacre]

See #2458 for the MIT variant. Perhaps we can consolidate our conversation over on that ticket since they are equivalent except for the future license?

[karsten-klein]

This is license proliferation at its best.

For the time being a -1 from my side. This appears to me as a bad practice without perceivable justification other than a commercial use restriction that must be managed by the consumer.

An interesting question: Does it also mean that I cannot commercially use a new security patch on a two year old library, before the patch itself is two years old?

I think this license is in severe conflict with economic operation of software and upcoming regulation.

[karsten-klein]

{metæffekt} Universe
canonical name: Functional Source License 1.1 (Apache-2.0)
short name: Functional-Source-1.1-Apache-2.0
markers: Linked License Marker, Non-commercial Marker, Patent Information Marker
category: Functional Source
OSI status: none

Comment
The license was introduced to the universe to be able to raise a compliance risk when identified. Still -1 for SPDX inclusion.

[chadwhitacre]

I've responded at #2458 (comment).

[karsten-klein]

@swinslow: with respect to your email on the legal mailing list. Please - in the effort to identify a name/id - also consider that there are already different versions in the wild:

The proposed id scheme here and in #2458 are in alignment with the ScanCode Id scheme (while ScanCode applies a all-lower-case policy). In the metaeffekt universe we hesitated from using FSL as short id, since the 'F' prefix is lightheartedly interpreted as "free".

[jlovejoy]

discussed more on July 11th call, particularly, id issue:

• proposal to bypass name/id issue, by using letters, e.g., FSL-1.1-M and FSL-1.1-A - this also may "look better" later once license becomes disjunctive after 2 years (see comment below). See CERN 2.0 licenses as an example-ish
• @chadwhitacre to check with ASF representative to make sure ok to use FSL-1.1-Apache-2.0 - if so, need someone from ASF to put comment here as such for transparency and in case we/SPDX gets questions in the future.

Clarification from stewards/authors - is the intention after two years in terms of what license applies, that it becomes a disjunctive license choice? That is, after two years, a downstream user can choose to use, redistribute etc. under a CHOICE of FSL-1.1 or MIT (for example)
If so, then the license expression at that point (when I redistribute) would be, for example:
FSL-1.1-MIT OR MIT
FSL-1.1-Apache-2.0 OR Apache-2.0
and I may "conclude" (in SPDX spec terms) to redistribute under just MIT?

Could someone fork/copy the code after two years and remove the FSL-1.1 part and just have MIT license text with no mention of FSL-1.1? In which case the license would just use MIT. Is that realistic b/c the fork would be arguably a derivative work and retain the Sentry copyright notice, also people are generally hesitant (rightly so) to remove any license related info.

to be clear, this last part is not relevant for SPDX inclusion, but could influence ID choice in terms of aethetics (ie., would FSL-1.1-M OR MIT look better?) and might be helpful to have an FAQ on Sentry's website or something.

[chadwhitacre]

Thanks for the discussion today and for working with us on this. I've started reaching out to ASF, will report back.

is the intention after two years in terms of what license applies, that it becomes a disjunctive license choice?

Hrm ... I'm not sure disjunction is the best way to model the situation. In a truly disjunctive scenario, the available licenses do not reference each other in any way. FSL, however, fully incorporates the terms of the sub-license, albeit with a time delay. Imagine if FSL granted the additional rights immediately, instead of in the future. Then of course it would be best identified as FSL-1.1-MIT and not simply MIT. Therefore, I suppose the most accurate thing for a redistributor to do would be to maintain the FSL-1.1-MIT identifier in perpetuity. Consumers would need to combine this with the publication date of the licensed software to fully understand their rights, though I could imagine some redistributors "cheating" and using MIT instead for simplicity, depending on their circumstances.

[chadwhitacre]

to fully understand their rights

To be clear: the expectation with FSL is that virtually all users of the software use it under the non-compete terms (as is the case with Sentry, we have 10,000+ users under BUSL/FSL). It is only people forking the project who need to care what the publication date of the original was. Forking is a high-touch operation, so the extra friction of the date computation is perfectly acceptable in that case.

[ShaneCurcuru]

The posted ASF position is that use of "Apache" with such modified licenses is not allowed, which @swinslow noted in the related #2458 issue about the MIT derivative, and which includes additional context. I'll note that there don't appear to be any other SPDX identifiers that include "Apache" currently either.

https://www.apache.org/foundation/license-faq.html#mod-license

See also:
https://lists.spdx.org/g/Spdx-legal/topic/fsl_1_1_submissions_and_id/106000683

Official questions on ASF legal policy go here:
https://apache.org/foundation/mailinglists.html#foundation-legal

[swinslow]

Thank you @ShaneCurcuru! Appreciate your input here.

Based on this, I take it as a pretty clear position from ASF that SPDX should not use "Apache" in the name or ID for anything that is not an ASF-issued license.

@chadwhitacre Feel free to review and let us know how you'd like to proceed. We discussed some alternatives on the call to avoid using the "Apache" name. I assume any such changes would need corresponding changes to the identifier that's baked into the license text itself.

[dcramer]

The posted ASF position is that use of "Apache" with such modified licenses is not allowed, which @swinslow noted in the related #2458 issue about the MIT derivative, and which includes additional context. I'll note that there don't appear to be any other SPDX identifiers that include "Apache" currently either.

https://www.apache.org/foundation/license-faq.html#mod-license

See also: https://lists.spdx.org/g/Spdx-legal/topic/fsl_1_1_submissions_and_id/106000683

Official questions on ASF legal policy go here: https://apache.org/foundation/mailinglists.html#foundation-legal

We will discuss with folks, but to be clear, I dont believe what we're doing fits within the description of what's being talked about there. We don't actually modify the Apache in any way. We're calling Apache, Apache, and FSL, FSL. Will followup after we talk to folks, because this is pretty new territory, and I think immediately jumping to "NO", is not constructive to the community here.

[jlovejoy]

@ShaneCurcuru - thanks for weighing in there, as I realize this was a bit unorthodox for "discussing" a trademark question.

@chadwhitacre - thanks for your attention throughout this. For obvious reasons, we'll mark this for a later release/put on hold for the time being.

@dcramer - re: your opinion that "immediately jumping to "NO", is not constructive to the community here." - I'm not sure what community you have in mind, but let's remember that there is not one monolith open source community, and the relevant community here (this issue, this project) is the SPDX community. Speaking for the SPDX community, we have reviewed your license submission with a fair amount of attention and raised a valid concern for our community regarding use of someone else's name/mark. Of course, you and the Apache Software Foundation are more than welcome to have further discussions separately, but SPDX does not need to be involved.

[chadwhitacre]

To provide a bit more context: @ShaneCurcuru and I had a call together yesterday, to catch up in general and to broach the license naming question. Shane's advice to me on the call was that Apache's legal-discuss mailing list is the appropriate venue to engage with the Apache community on this topic. @GavinZee (Sentry's in-house counsel) posted a message to the list yesterday. It crossed paths in cyberspace with Shane's comment above on this thread.

Of course, you and the Apache Software Foundation are more than welcome to have further discussions separately, but SPDX does not need to be involved.

Yes, please. I feel that we've jumped the gun by engaging this thread instead of following Shane's guidance to me yesterday. My ideal would be that we let the conversation play out over in the suggested channels, and return here once we've reached a conclusion.

Sorry for the noise.

[swinslow]

Thanks @chadwhitacre! We'll stand down on this for now, and will hold off to see what you and ASF work out in your separate discussions.