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

[chadwhitacre]

1. License Name: Functional Source License v1.1 (MIT Future License)
2. Short identifier: FSL-1.1-MIT
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-MIT does not match another license already on the SPDX License List as per the SPDX matching guidelines.

B. FSL-1.1-MIT is not an OSI-approved license.

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

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

E. The FSL-1.1-MIT 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/365
6. URL(s): https://fsl.software/FSL-1.1-MIT.template.md
7. OSI Status: Not Submitted
8. Example Projects: MIT variant—AnswerOverflow, CodeCrafters, GitButler; Apache 2.0 variant—Codecov, Convex, Sentry

[chadwhitacre]

See #2459 for the Apache 2.0 variant. I suggest we use this ticket for conversation about both, since they are equivalent except for the future license. I'm happy to answer questions and address concerns here. I'm also subscribed to the mailing list, and I can plan to join the call if needed.

@MarkAtwood this is the license we spoke about last week at OSSNA. 🙏

[swinslow]

Hi @chadwhitacre, thanks for submitting this! Appreciate your initial comments above on the application of the license inclusion principles.

I'll follow up with some thoughts and an actual review of the licenses under the inclusion principles. But I did have two initial questions for you to consider -- would welcome your thoughts on these:

1. Can you confirm that the FSL licenses will only use MIT or Apache-2.0 as the eventual "Future License" options?

   • I'm asking that because, if it's going to be open-ended to potentially include others, I don't love the idea of ending up with a bunch of FSL-1.1-... entries with different suffixes. If it'll only ever be -MIT or Apache-2.0 as the only options, that might be less of a concern.

2. Although it's more relevant to New license request: FSL-1.1-Apache-2.0 [SPDX-Online-Tools] #2459, I'm listing this here as requested :) I note the Apache Software Foundation's position on use of the Apache trademark for licenses that are not the official Apache licenses. Should that affect whether we allow the use of "Apache" in the name or ID for these entries, if they are added to the SPDX License List?

   • I recognize that the purpose of the license is to state that, eventually, the software will in fact be licensed under Apache-2.0.
   • But given that it isn't currently under Apache-2.0 -- and given e.g. the use of the standard Apache-2.0 template at the end of the license text -- I have some concerns that using "Apache" in the name or ID here might not be in line with ASF's intended use of their trademark. To my knowledge, we haven't used "Apache" in the names of other non-Apache but related licenses (see for example this discussion last year for Pixar's modified version of Apache-2.0).

Grateful for your thoughts and responses on these!

[chadwhitacre]

Thanks for the warm welcome and for taking on a fuller review. :-)

Can you confirm that the FSL licenses will only use MIT or Apache-2.0 as the eventual "Future License" options?

Confirmed. We've already fielded a couple requests to expand the set of future licenses (one, two), which we've denied. Theoretically we could be convinced of the value of allowing for another license. Disinclination from SPDX would raise the already high bar higher.

Although it's more relevant to #2459, I'm listing this here as requested :)

Sigh. Murphy's Law! 🙈

Should that affect whether we allow the use of "Apache" in the name or ID for these entries, if they are added to the SPDX License List?

That does seem a question worth asking. @GavinZee (from Sentry legal) and I are planning to join the call tomorrow. Let's discuss and go from there.

[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 (MIT)
short name: Functional-Source-1.1-MIT
markers: No Warranty 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]

Thanks for speaking up, @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.
I think this license is in severe conflict with economic operation of software and upcoming regulation.
The license was introduced to the universe to be able to raise a compliance risk when identified. Still -1 for SPDX inclusion.

Clearly you have strong feelings about FSL. Less clear is the substance of your concern. If you expand on the rationale behind these statements, it may help make a better decision regarding FSL's proposed inclusion in SPDX. As they are, I find these statements too vague to know how to engage with them.

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?

This question seemingly applies to delayed Open Source publication in general. Since that includes the already-included BUSL-1.1, I don't see that this is relevant to the question of SPDX inclusion for FSL. That said, it's worth discussing. I've reticketed your question in the FSL repo so we can have a clarification on record without distracting from the present topic.

[swinslow]

(comment 1 of 3)

Hello all,

I'm adding my comments below from my perspective of applying the license inclusion principles to the licenses proposed here and also in #2459. This reflects the discussion and comments I shared during the legal team call on 2024-04-25.

As described below, based on the license inclusion principles, I'm in favor of adding this (and the #2459 submission) to the License List. However, I'm less convinced on using FSL-1.1-Apache-2.0 as the license identifier for #2459. I'm planning to follow this up with an email to the spdx-legal mailing list shortly.

@karsten-klein I do want to note your comments above. As discussed on the call, I think it's important for us to highlight that this is not an open source license, in light of the use restrictions; and to acknowledge that this does affect the first "Other factor" from the license inclusion principles.

Setting aside any personal views I might have towards these licenses, when I look at the balance of the "Other factors", I do think it comes out in favor of adding them to the license list, particularly given the similar analyses that have led to adding some other source-available licenses such as SSPL-1.0, BUSL-1.1 and Hippocratic-2.1. But I recognize there are differences of opinions here, and I want to give you and others a chance to weigh in if you have a different view based on applying the license inclusion principles to these.

[swinslow]

(comment 2 of 3)

Here's my own take on applying the license inclusion principles to this and #2459. Since the only difference between these is whether it switches to MIT vs. Apache-2.0 in the future, I'm going to treat them as equivalent for the moment.

New submission review

• Has the license been approved by the OSI? All OSI-approved license will be included on the SPDX License List, regardless of other factors
  • Yes
  • No => and don't expect that it will be; this is not an open source license.

Definitive Factors

These must all be satisfied to allow inclusion in the license list

1. Is the submitted license unique, that is, it does not match another license already on the License List as per the matching guidelines?
   • Yes
   • No
2. If a software license, does it apply to source code and not only to executables?
   • Yes
   • No
3. Does the license have identifiable and stable text, and is not in the midst of drafting?
   • Yes => participants from the license steward stated during the 2024-04-25 legal team call that this v1.1 release is an iteration after having incorporated community feedback from an earlier version, and that it is now finalized for this version and will not change.
   • No
4. Has the license steward, if any, committed to versioning new versions and to not modify it after addition to the list?
   • Yes => similarly stated by license steward participants on 2024-04-25 as well as in the submission comments above from @chadwhitacre
   • No

Other factors for inclusion

Roughly in order of descending importance

1. Does the license substantially comply with one of the free/open content definitions? (examples include the Open Source Definition and the Debian Free Software Guidelines) (Approval by the organisation that publishes the definition is not required)
   • Yes
   • No => The restriction on Competing Uses, and the limitation to Permitted Purposes, means that this is not an open source (or open source-ish) license. The fact that it'll change in the future to MIT / Apache-2.0 is not relevant here, since that's really about MIT / Apache-2.0 themselves being open source licenses.
2. Is the license structured to be generally usable by anyone, and not specific to one organisation or project?
   • Yes => described as such at https://fsl.software, and indicated in the text e.g. by the Notice section being templated
   • No
3. Does the license have substantial use such that it is likely to be encountered (ie. use in many projects, or in one significant project)? (For recently written licenses, definitive plans for it to be used in at least one or a few significant projects may satisfy this)
   • Yes => As always, this is the tricky one. I view this as a "yes." Sentry, as the license steward, has released some of their own products under this. As described on the 2024-04-25 call, others in the broader community (without Sentry's prompting) have independently adopted it as well. A few of these are listed on the https://fsl.software website; searches on GitHub for the -MIT version and the -Apache-2.0 version show several additional projects also. In my view, that's sufficient to count as a "yes" for this factor.
   • No
4. Is the license primarily intended to facilitate the free distribution of content with limited restrictions?
   • Yes => While this submission of course does include purpose restrictions on Competing Uses, it is otherwise meant as a "no-charge distribution of content" license. This fits with the intent of this factor being separate from the "is it open source" Other Factor 1 above, and is comparable to the handful of other "source available" licenses that have been added to the list.
   • No
5. Does the license steward support this submission, or is at least aware of and not in opposition of it?
   • Yes => This submission originated from the license steward.
   • No

Summary of factors, outcome, comments

While this is clearly not an open source license, in my view the totality of the factors as described above leans in favor of adding it to the license list.

However, I'm less certain about the identifier to be used, which I'll describe below in my final comment in this thread.

[swinslow]

(comment 3 of 3)

Assuming for the moment that these are approved to be added to the License List (if you disagree with that, please respond first to my preceding comment above).

On the naming and ID:

Specifically for the "Future license is Apache-2.0" version submitted at #2459, I'm somewhat uncertain / uncomfortable with including the term "Apache" in the name or identifier. This is primarily because of the (understandable) stance that the Apache Software Foundation has taken towards limiting use of the "Apache" name for only their actual licenses. This is described in their FAQ, as well as e.g. here.

To date, we've made a point of avoiding the use of the "Apache" name in any full name or identifier on the license list or exceptions list, apart from the actual Apache licenses. Where others have requested to add modified versions of Apache-2.0 to the license list, e.g. the Pixar license last year, we intentionally omitted any reference to Apache in the name or ID, but noted its relationship to Apache-2.0 in the "notes" section of the license entry (see the discussion thread for more details).

Given all of that, I think this is a bit of a weird situation for the present request. On the one hand, it is talking about actual Apache-2.0 after the change, not a modified version of it. But, the license is not actually Apache-2.0 until that time; so the reference to Apache-2.0 might be confusing to some or at least might not fit with ASF's preferences. (The inclusion of the Apache-2.0 standard license header text in the version submitted at #2459 may add to potential confusion here as well...)

At the same time, I recognize that trying to come up with some not-really-but-sorta reference to Apache-2.0 would also be confusing here. So I don't have a clean answer either way at the moment.

Based on that, I'm going to send a note to the spdx-legal mailing list in a bit, to raise this for community input. We'll see what others may have to say about how best to handle this.

[chadwhitacre]

I'm going to send a note to the spdx-legal mailing list in a bit

Ftr: https://lists.spdx.org/g/Spdx-legal/message/3553