Open chadwhitacre opened 2 months ago
See https://github.com/spdx/license-list-xml/issues/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. 🙏
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:
Can you confirm that the FSL licenses will only use MIT or Apache-2.0 as the eventual "Future License" options?
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.Although it's more relevant to #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?
Grateful for your thoughts and responses on these!
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 https://github.com/spdx/license-list-XML/issues/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.
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.
{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.
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.
(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.
(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.
These must all be satisfied to allow inclusion in the license list
Roughly in order of descending importance
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.
(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.
I'm going to send a note to the spdx-legal mailing list in a bit
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:
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