-
Notifications
You must be signed in to change notification settings - Fork 277
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
New license request: FSL-1.1-MIT [SPDX-Online-Tools] #2458
Comments
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. 🙏 |
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:
Grateful for your thoughts and responses on these! |
Thanks for the warm welcome and for taking on a fuller review. :-)
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.
Sigh. Murphy's Law! 🙈
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 Comment |
Thanks for speaking up, @karsten-klein.
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.
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 @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. New submission review
Definitive FactorsThese must all be satisfied to allow inclusion in the license list
Other factors for inclusionRoughly in order of descending importance
Summary of factors, outcome, commentsWhile 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 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 see some value in adding SPDX identifiers for these source-available licenses under what I think of as the @MarkAtwood principle, which is that an SPDX identifier can sometimes be useful as an aid in avoiding relatively bad, problematic, lamentable licenses, which these certainly are. 😄 The countervailing concern I have often had is that some licensors and license authors in the recent past have apparently attempted to use SPDX identifier creation as a kind of signal of approval or something. I am not familiar with any of the example projects but my sense is that these licenses should be seen as meeting the "substantial use" requirement. |
Prefacing this as my personal opinion, unrelated to my work at Sentry but from trying to both use and write a license checker. Today SPDX does not just maintain a license list, but also a bit of "infrastructure" around it. That in my mind comes from two places: SDPX expressions and common suffixes to indicate that licenses have some variance to them (eg: I'm raising this because particularly with I think the FSL family of licenses has some a bit similar in that after the second anniversary it becomes a different license entirely and tools will care. Particularly if the model of change over licenses becomes more popular, I'm a bit afraid that having aliases like I'm not sure what the right path here is but I feel like this might warrant some discussion about how to future proof this here so that people that might want to write tooling around license compliance. If trademarks where not a concern I believe it would be reasonable to recommend a |
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
The text was updated successfully, but these errors were encountered: