Implications of usage restriction on patch releases

[chadwhitacre]

Reticketing from @karsten-klein at spdx/license-list-XML#2458 (comment):

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?

[chadwhitacre]

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?

The short answer is, yes.

The longer answer is that there's nothing stopping a software producer from licensing a security patch on a two year old library directly under, e.g., MIT, rather than licensing it under FSL-1.1-MIT. Furthermore, "commercial use" may not mean what you think it means. If someone licenses a library under FSL (nevermind that it's intended for SaaS apps, not libraries), and you incorporate that library into a software product in a way that does not violate the FSL, then it follows that you would be able to use future releases of the library without violating FSL as well. Right? If you are using a two-year-old version of the library under MIT in a way that would violate FSL, and the software producer obligates themselves or is obligated by government to provide security patches, then I would expect the producer to provide those patches directly under MIT. This would be taken into account in their support and deprecation schedules, in other words. That said, if you are using a two-year-old library under MIT in a way that would count as Competing Use under FSL, then you are almost certainly a software manufacturer from a CRA standpoint (e.g.) and likely responsible at some level to patch the library yourself.

Do you see things differently?

[chadwhitacre]

Silence is assent. Closing as answered.

[karsten-klein]

Yet an argument to hesitate from using FSL licensed software in a commercial context, due to complexity of license management.

[chadwhitacre]

An argument that has not swayed 10,000+ companies.