"Springing licenses" and promises to grant future permissions #20
Comments
|
I have been working with other PolyForm folks to further improve that draft since blogging it. The main question in my mind is whether to call it "PolyForm Countdown" or "PolyForm Scheduled". I'd like to publish next month. But we're all volunteers, and many of us usually get crunched toward the end of the fiscal year. |
chadwhitacre
added
the
clarification
|
Is it as easy as this? @gavin-zee @hmeeker thoughts? diff --git a/FSL-1.0-Apache-2.0.template.md b/FSL-1.0-Apache-2.0.template.md
index 3ab1387..daff829 100644
--- a/FSL-1.0-Apache-2.0.template.md
+++ b/FSL-1.0-Apache-2.0.template.md
@@ -91,7 +91,7 @@ trademarks, trade names, service marks or product names.
## Change License
On the second anniversary of the date we make the Software available, the
-Software will become available under the Apache 2.0 license. On that date, the
+Software becomes available under the Apache 2.0 license. On that date, the
Terms and Conditions above automatically terminate and the following terms
become effective:
|
|
@chadwhitacre it would probably have to be something like: "On the second anniversary of the date we make the Software available, we grant you the right to use the Software under the Apache 2.0 license. On that date, the Terms and Conditions above automatically terminate and the following terms become effective:" |
|
To be precise, it is incorrect to say that the original license terminates.
It is correct to say the springing license is granted.
…On Thu, Nov 30, 2023 at 4:20 PM Gavin Zee ***@***.***> wrote:
@chadwhitacre <https://github.com/chadwhitacre> it would probably have to
be something like: "On the second anniversary of the date we make the
Software available, we grant you the right to use the Software under the
Apache 2.0 license. On that date, the Terms and Conditions above
automatically terminate and the following terms become effective:"
—
Reply to this email directly, view it on GitHub
<#20 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ATLOOI5FZP5RP7XE4Y7CLE3YHEPFVAVCNFSM6AAAAABAB5EYSWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZVGA2TANJZGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Heather Meeker 510-463-1116
|
|
If you've not had the opportunity to read the full CC report on springing licenses, I encourage you take the time to do so. I think you're retracing some steps that they, too, retraced some years ago.
"Stand on the shoulders of giants," as we say... ;-) |
|
Respectfully submitted, I'm not sure I trust their conclusion.
…On Thu, Nov 30, 2023 at 4:59 PM mswilson ***@***.***> wrote:
If you've not had the opportunity to read the full CC report on springing
licenses, I encourage you take the time to do so. I think you're retracing
some steps that they, too, retraced some years ago.
Finally, through this work, CC gained a renewed appreciation for the
documentation of research and learnings. As explained above, the springing
license concept has been discussed and explored in a variety of fora for
many years. Yet CC found itself having to revisit many of those previously
vetted ideas because there was insufficient record of what was discussed
and decided previously, including within CC. Creative Commons provides this
extensive report in an effort to avoid this situation in the future if CC
or another organization decides to move this project forward in the future.
"Stand on the shoulders of giants," as we say... ;-)
—
Reply to this email directly, view it on GitHub
<#20 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ATLOOIYSSGSGLEOWXGDO5HTYHETX5AVCNFSM6AAAAABAB5EYSWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZVGIYTOMZRGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Heather Meeker 510-463-1116
|
|
Half of "public license" is getting the legal job done. The other half is preventing pointless e-mail. |
This isn't what I'm looking for. I'm looking for a clear present grant of license under Apache 2.0 terms that a licensee can elect to in the future. Something more like: diff --git a/FSL-1.0-Apache-2.0.template.md b/FSL-1.0-Apache-2.0.template.md
index 3ab1387..8733966 100644
--- a/FSL-1.0-Apache-2.0.template.md
+++ b/FSL-1.0-Apache-2.0.template.md
@@ -88,12 +88,14 @@ Except for displaying the License Details and identifying us as the origin of
the Software, you have no right under these Terms and Conditions to use our
trademarks, trade names, service marks or product names.
-## Change License
-
-On the second anniversary of the date we make the Software available, the
-Software will become available under the Apache 2.0 license. On that date, the
-Terms and Conditions above automatically terminate and the following terms
-become effective:
+## Additional License
+
+We hereby grant to you an additional irrevocable license under the
+terms of the Apache License, version 2.0 that is effective on the
+second anniversary of the date we make the Software available. Until
+that date, the Terms and Conditions above are the entire agreement for
+the licensed Software. After that date, you may elect to use the
+following terms to superseed the Terms and Conditions above:
Licensed under the Apache License, Version 2.0 (the "License"); you may not use
this file except in compliance with the License.If someone is happy with the original Terms and Conditions, I don't see why you would want to pull the rug out from under them by forcing a change to Apache License, version 2.0. You can "dual license" the software perpetually as "FSL-1.x OR (IF TODAY() >= $CHANGE_DATE THEN Apache-2.0) " in a schema like SPDX. Note that I don't think that the condition construct that @david-a-wheeler proposed in spdx/spdx-spec#60 was fleshed out, so that might be something to consider working with the SPDX community. If you force a change in terms for a given release of software, the SPDX metadata for a given release has to change as well, and that's a bit of a pain (to say the least). |
Can you be specific about what we're missing, if not already covered in your other comments so far? In reading the doc, I didn't find anything more (apart from the main topic of this issue) to think through. Rather the opposite: "A license tied to a specified future date or period of time poses the fewest legal complications." That's us! :-)
I don't resonate with this negative characterization. How is it a forced rug-pull when the license terms are clear up front? It's not like we jump out of the bushes in two years to surprise them with the additional permissions. 😛
Election is a new idea in this conversation. What's the value of it? We've successfully used BSL's "Change License" model for over four years (and others for longer). How would we benefit by switching FSL to use an election model instead?
Really? That doesn't seem like a given to me, but I've only lurked SPDX fairly recently. Doesn't the SPDX metadata include a date? A quick look only turns up the copyright field. Maybe package information should also include a publication or release date, if that's not already accounted for somehow? Then consumers could programmatically determine the licensing state of a given artifact. Burdening the consumer with the computation of the concrete change date was an intentional design decision for FSL (contra @kemitchell's approach). Based on our experience with the friction of managing BSL change dates, we decided to optimize for producers to adopt FSL by only having the copyright notice to change. Also, we shot ourselves in the foot pretty badly with a date change misfire in the heat of our Codecov (mis)adventure. Once burned, twice shy. Anyway, I intend to submit FSL to SPDX in due course (reticketed as #21). We can then discuss fully over there. I'm not sure there won't be other gotchas as well once we get into the process.
I think my proposal achieves this, but I'm open to finding even clearer language.
This is a separate ask, the value of which I don't understand. |
I didn't intend a negative characterization, apologies for that. I only meant to highlight that the original terms are unilaterally changed.
As a software consumer, I generally prefer agreements that are unchanging over time. The license you have drafted today is not an irrevocable one. In fact, it is expressly unilaterally revoked after two years, and replaced with new terms and conditions. As a software consumer, this means I need to evaluate both agreements, and then set a calendar to know which ones apply to my continued use of the software (which is only permitted via these two license terms, which in the current drafting are never available to me concurrently). From time to time, some software consumers need to make precise attestations to others about the licenses that permit their continued use of software. An election option would mean that if the Terms and Conditions of the FSL are agreeable to me, and are clearly perpetual, I can make an election to abide by those terms in perpetuity. I can't do this with an expressed termination that happens at an ambiguous date. The argument that "the BUSL terminates and we've not had problems with it" doesn't convince me. There is increasing scrutiny on software supply chains in all dimensions. Security vulnerabilities gets a lot of attention, but clearly documented license compliance is another. This is an area where I think that BUSL can be improved upon, and I'd encourage you to consider it.
I'm unaware of a place where the dates and changes in terms (License A or B, depending on a date) could be adequately expressed in a machine readable form within the SPDX standard as it sits today. If someone is generating an SBOM that uses SPDX identifiers, that SBOM producer could use a "Declared License" field of "FSL-1.0-Apache-2.0" and a "Concluded License" field of "Apache-2.0" once the change date has elapsed. But they would have to figure out how to implement that conclusion themselves. A "Concluded License" of "FSL 1.0" would not be durable, since it has an unknown (within the schema of SPDX license expressions) expiration date.
Naturally, this externalizes costs and risks. It is your choice to do so, but it may dampen adoption of software that uses this license due to the ambiguity. |
|
I've started #32 with some updates, here's where we're at for this portion:
Look good, @mswilson? |
|
Sorry for the delay responding. I think this is an improvement. I imagine that the revisions I suggest will be a little more "lawyery" (though to be clear: I'm not a lawyer). As a consumer of software I want the same kind of clarity that many lawyers want in legal drafting, so some of the words I'm looking for are the same. Quoting David McGowan
The clarity I'm seeking is this: I want to be certain that there is a present grant of a license that I can fully rely on at a future date. That's why in the suggested text in comments above:
I used some words like "hereby grant to you" and "irrevocable license" and "is effective". I removed words like "change" because that indicates that something is, well, changing. "becomes effective" has a similar effect of uncertainty. A Real Lawyer™ might write it more like this:
Personally, I think that a version like that may be more form than substance. A bit too much "for the avoidance of doubt" verbosity. Building on the current proposed version, this is my concise suggestion
|
|
hi @mswilson the reason we left out "irrevocable" is because Apache 2.0 already speaks to the license grant being irrevocable, however under MIT (which is the other delayed license for the FSL) the license is not specified as "irrevocable". It felt like whether the license was "irrevocable" or not should default to the delayed license terms themselves. |
|
Thanks @mswilson. I see now that we have "hereby grant" in the main License Grant section, and that "Apache License, Version 2.0" is the way it specifies itself in the boilerplate notice. I agree we that if we're taking the basic point, we should change thoroughly from "change license" to "additional license grant." Leaving off "irrevocable" based on @gavin-zee's comment, we now have this diff: 
Is this acceptable? |
Rereading ... I think @mswilson is looking to make it clear that the licensor can't undo the "present grant of future permissions" between the date the Software is made available and two years thence. Yes, once Apache 2.0 kicks in, its own copyright and patent clauses are irrevocable. Could the grant be revoked before the Apache 2.0 kicks in, though?
I think this might actually be clearer:
|
|
Updated in d42ffcb. 
|
|
Last call for comments! :) Here's the language we're getting ready to move forward with on #32:
|
|
In the headings I would intentionally avoid words like "future" because it can introduce questions regarding when the license is granted. Some licensees may have more "confidence to proceed to do things they want to do" (to borrow a phrase from a comment above) knowing that the grant of an additional license is made immediately in the present, and that this is not a promise to perform some act in the future. A fact that potential licensee may want to establish is: an irrevocable license under the terms of Apache 2.0 clearly existed before a potential future bankruptcy proceeding commences, and therefore the license of the software should not be extinguished through a bankruptcy proceeding. See 11 U.S.C. §365(n). Explicit and intentional choice of language can help make the intent of the licensor clear. Disclosure: I'm not a lawyer and this is not legal advice. |
In the Creative Commons report on the viability of so-called "springing licenses" the authors made this observation:
It is not clear to me that the language in the current license text is a "present grant of future permissions" (i.e., irrevocable permissions granted via different legal terms that will be effective in the future). The current license text uses the words "will become available". This is different than a present grant (e.g., "the software is licensed to you under Apache Licence 2.0 effective [unambiguous date]".
See also this blog post from @kemitchell that goes into detail about the need to be unambiguous in the effective date for a license that grants permissions effective in the future.
Disclaimers: I am opening this bug report in my individual capacity, speaking only for myself. I am not a lawyer, and this is not intended to be legal advice. Opening this bug report is not intended to be an endorsement of the FSL.
The text was updated successfully, but these errors were encountered: