How will "open source" be used or framed relative to this license/plan?

[ssddanbrown]

Hello 👋 ,
I hope you don't mind me opening up an issue here, let me know if there's somewhere more appropriate for this discussion.
I just wanted to start a conversation in how, as part of these efforts, you intend to use and/or frame the existing "open source" term.

For some context and perspective, I'm a fan of open source and someone that believes it's important that the term should be to the OSD, and that it's worth advocating that open source is used in an OSD adhering way.
I've documented and called-out cases (including Sentry) where I felt open source was being used in a non-OSD manner.
I've written about why I think this is important here.

That said, I also strongly believe in the right for people to license (and protect) their efforts however they desire.
I think it's perfectly valid to set extra terms, and at the end of the day a company sharing their code is much better then code being closed off completely. I respect the need and desire for protecting your work, and I understand some of the struggle & challenges of attempting to sustain upon open source work.
I'm just not a fan of this being done at the detriment, or mis-marketing, of open source.

Focusing on this repo and license, I respect what you're doing here to align and publicise this in-between space.
I always thought "Fair Code" sounded good and could do well to become established if pushed by a few.

In regards to my concerns, the first is if (and how) "open source" may still attempted to be used with this license (or the marketing surrounding it).
My worry is that "open source" may still be attempted to be used in ways to label this license (eg, sustainable open source, evolution of open source etc...).
It may not seem like big deal, especially from your perspective where you may see these kinds of licenses as a better revision of open source, but this kind of use chips away at what I believe to be the pretty good bounds set by the OSD.
I've seen this before in usages of "Commercial Open Source" (details here).
Specifically for the FSL, it may help avoid any issues here if the FAQ had something alongs the lines of (very rough example):

Is this open source?
No, while the code is under the FSL is it not considered open source, since we put limits on use, but once the code becomes available under the Apache 2.0 license after the change date then that code would be considered open source.

I have felt that the Commons Clause did a great job at making this clear (see the 'Is this “Open Source”?' section).

My second concern is potentially framing of open source, as a whole, as unsustainable or with the indication it needs to evolve, or that it's defunct or not suitable for modern software. I've been seeing this type of framing quite a bit, but it mostly comes across to me as dishonest narrative building to justify why open source does not work for them. The sustainability and feasibility of open source is a massively variable thing depending on many factors including the business model and goals of an entity.

I understand that open source can be unsustainable, or not the right option/model, for some but I think it's misleading and incorrect to label open source itself as unsustainable or a bad choice as a whole.
It's really a matter of compatibility. There are many business perfectly happy sustaining themselves on open source, and there are others it has failed. I raise this in the hopes that the wording/marketing for this license around these area will be established to your experience/usage ("Open source is not sustainable for us") rather than being generalised to open source itself ("Open source is not sustainable").

[chadwhitacre]

Hi @ssddanbrown. 👋 Thanks for jumping in. :)

How will "open source" be used or framed relative to this license/plan?

For the license we'll use language like "as Open Source as possible" and "eventually Open Source," taking care not to refer to FSL as (full stop) Open Source. Maybe we need to strengthen our FAQ, maybe not.

For the plan ... too early to tell. On #2 we're brainstorming new brand names, but the hard part (as you suggest) is coming up with a meaningful expanded definition that sticks. If there's enough buy-in from the community on an expanded definition, then I can imagine a future in which Open Source comes to refer to that definition, if/when it becomes widely adopted. In that future, those who were only ever committed to user freedom and not to developer sustainability can go back to using the Free Software brand. Otoh if there's too much baggage in "Open Source" and a pretty good name emerges on #2, then no reason not to go with that. Time will tell! :-)

[ssddanbrown]

Thanks @chadwhitacre for the response!

Otoh if there's too much baggage in "Open Source" and a pretty good name emerges on #2, then no reason not to go with that.

As an outsider, that would be my hope in the direction you persue.
I think you'll mainly get buy-in on an expanded definition from folks in the same position as you. In which case, a group of businesses, for which existing open source did not work for, attempting to expand the definition would likely alienate a significant portion of the existing open source community who appreciate the bounds set by the OSD.
Whereas putting efforts into a new category & brand, could potentially improve things IMO by setting a clearer definition between open source and source available, rather than creating friction via overlap.

I guess another angle to think about is, what are you attempting to gain by expanding the definition of "open source" (if you go that route)?

[chadwhitacre]

I'm gonna hold off on engaging the "plan" aspect until we're much further along. :-)

Did I answer your question about how we're framing the FSL? That's the immediate focus.

[ssddanbrown]

Did I answer your question about how we're framing the FSL?

Yeah, thanks, that answered it. In my view, "eventually Open Source" seems like an accurate way to describe these kinds of license, as long as you always have that qualifier. For example, Referring to a project licensed in such a way as "open source", since it's open sourced eventually would still be misleading IMO.
If overused, or used as branding in itself, if could come across as open washing though as it may be attempting to use the reputation of open source in a way that's not open source. As a more elaborate example, say I applied the FSL but with a change date of 100 years. That's "eventually Open Source" but completely missed the point.

"as Open Source as possible" seems strange to me. "as Open Source as possible" is open source, and is possible, it just doesn't fit with your goals/requirements/desire/business-model/fears. What you really mean is "as Open Source as possible for us act out business in the manner we want". Or maybe "as close to Open Source as possible while protecting our business interests" .

[chadwhitacre]

What you really mean is

Fair enough. That's in fact how we're using it on the website: "It is designed for companies that want to make their core products as Open Source as possible without jeopardizing their business." Of course "as Open Source as possible" without further qualification would just be Open Source. :-P

FSL but with a change date of 100 years

One of our goals with FSL is to remove the parameters in order to avoid ambiguity. Another is to tighten up the timeframe from the 4-year default of the BSL/BUSL (which most everyone sticks with) to 2 years, to make it even more meaningful to call it "eventually Open Source." In other words, FSL will only ever mean a 2-year change date.

I've added a FAQ about FSL not being OSI-approved.

How are we doing? Anything else to address on this thread?

[ljharb]

I think that "Open Source as possible" (even with the unbolded qualifier text after it) is still a bit too coattail-riding on Open Source - I understand the appeal but it'd probably be better to try to establish your own branding for the non-open-source window, and "eventually Open Source", while true, isn't a great tagline.

[ssddanbrown]

"It is designed for companies that want to make their core products as Open Source as possible without jeopardizing their business."

To me, that insinuates that you generally can't use open source without jeopardizing business. From my view, a more direct and honest version of this would be "It is designed for companies that want to make their core products as Open Source as possible while retaining a business advantage." Additionally, "as Open Source as possible" does give the impression that open source is some kind of range which is not great.

Another is to tighten up the timeframe from the 4-year default of the BSL/BUSL (which #4 (comment) sticks with) to 2 years

That's good to hear, but ultimately others can just copy the license setup and change the timings. Then what time range does "eventually Open Source" remain reasonable? If others see you publicizing and stewarding this, it will be copied (both this phrase and license variation), hence my concern if as branding.

I've added a FAQ about FSL not being OSI-approved.

Okay, that doesn't make it clear it's not open source though. Any reason not to make it as clear as the commons clause FAQ?

[ssddanbrown]

After starting this conversation I've been trying to get my thoughts together in regards to why I think that distinction between open source and source available is important, which has resulted in my post here: https://danb.me/blog/open-source-available-distinction/
I'm not great at fully getting things written down though.
It's not a direct response to anything above, but just an attempt to emphasise why I've pushed for the distinction to be clear.

The "common source" approach in getsentry/fsl.software#36 is looking like a good development to fill/brand that source-available space. I'd be interested to see how the community reacts and runs with it.
I don't see anything about a definition there though. I've thought OSI's model of having a definition, which they then steward and validate licenses against, has worked well rather than limit to specific licenses. It provides transparency into what the licenses are being validated to, and does not force their licensing review process itself to be a gate-keeper.

[chadwhitacre]

Thanks, @ssddanbrown. I've been mulling over this thread as well.

I just pushed a revision to the homepage that changes how we frame FSL relative to Open Source. I removed the term from the opening paragraph and the first FAQ. Instead, I'm focusing our pitch on the positive intent behind this effort, without reference to Open Source:

Many software-as-a-service (SaaS) companies wish to make the source code for their core products available under permissive terms without the risk of free-riding. A standard license for this purpose makes it easier on both producers and consumers of such software.

I replaced the FAQ about OSI approval with a more front-loaded FAQ about Open Source that builds on the initial pitch:

Why not Open Source?
Open Source does not protect against free-riding.

How does this read to you (and @ljharb) now?

P.S. Can you post your comments about #36 over on #36? 😬

[ljharb]

I'd make "free-riding" a link; it's not a term I'd heard before.

The name and rationale are a bit weak still, but I don't have a better suggestion.

Otherwise, looks much better.

[chadwhitacre]

I linked it in the FAQ, I can link it in the opening paragraph if needed (but then what else should I link?). Honestly makes me want to use this term a lot more, hearing that you haven't heard it. It's the precise name for the sustainability problem in Open Source.

[ssddanbrown]

@chadwhitacre That reads a lot better in respect to open source now, thanks!

Basing it around "free-riding" is an intriguing take, since the license does not really prevent free-riding, but specifically "free-riding from competitors". You do risk that being taken as labeling end users as free-riders. Might come across, and relay the intent better, to specify "free-riding competitors" or something along those lines. With "free-riding competitors" it may be easier for others to sympathize with the intent.

Red Hat got a bad reaction from using "freeloaders", which I think runs quite close to "free-riding" (when not provided with any extra qualifier).

[chadwhitacre]

Red Hat got a bad reaction from using "freeloaders"

Link?

[chadwhitacre]

Does "corporate free-riding" get at it? 🤔

[ssddanbrown]

@chadwhitacre Some context here: https://www.linkedin.com/feed/update/urn:li:activity:7080644263968997376/

From what I remember, the term started being used by some RedHat folks around the latest CentOS sources drama.
But the trouble is that RedHat would never specify who they really meant by that. A "freeloader" from RedHat's internal perspective could have a lot of community value from another's perspective. Just got a bit messy.

Does "corporate free-riding" get at it?

It's better than free-riding alone, although the license still doesn't prevent corporate free-riding, unless they're doing so in a competitive way. The reader would have to extrapolate that from "corporate free-riding" rather than taking at face-value.

[chadwhitacre]

I'm gonna go with "harmful free-riding." 👍

What is harmful free-riding?

Harmful free-riding is the sort of free-riding that leads to the free-rider problem: “In the social sciences, the free-rider problem is a type of market failure that occurs when those who benefit from resources, public goods and common pool resources do not pay for them or under-pay. Examples of such goods are public roads or public libraries or services or other goods of a communal nature. Free riders are a problem for common pool resources because they may overuse it by not paying for the good (either directly through fees or tolls or indirectly through taxes). Consequently, the common pool resource may be under-produced, overused, or degraded. Additionally, it has been shown that despite evidence that people tend to be cooperative by nature (a prosocial behaviour), the presence of free-riders causes cooperation to deteriorate, perpetuating the free-rider problem.”

Anything else to address on this thread? I appreciate the back-and-forth, the FSL webpage is stronger for it! 🙏

[ssddanbrown]

Anything else to address on this thread?

No, nothing from my side. All seems much clearer now, as something defined adjacent to open source instead of being conflated with it.

I'll therefore close this off. Thanks again for listening.

[chadwhitacre]

Thank you @ssddanbrown! 🙂