Source Available Licenses

[vsoch]

This might not be a business model, but there is talk of development of “source available” licenses to protect OSS from entities that want to take and sell it without giving back.

https://techcrunch.com/2019/05/30/lack-of-leadership-in-open-source-results-in-source-available-licenses/

Should we add this here or wait until it’s official?

[nothingismagick]

I just discovered the wonderful license-musings of @kemitchell and am thinking that having his feedback here could be extremely helpful.

From his article:

We must judge an open source project, an open source license, an open source definition not by how it serves a concept of freedom both actionably specific and pleasingly vague, but by how it achieves practical results worth celebrating.

The thing that I have been thinking about over the past several days is that our licenses don't go far enough to really protect our communities from being pillaged by corporate raiders and simultaneously allow these corporate behemoths to "open-wash" their projects to gain all the benefits of open source without really committing to the ideals underlying them. Perhaps Source Available Licenses are a step in the right direction, but honestly I need help understanding EXACTLY what they mean from a legal standpoint.

[kemitchell]

@adamhjk and I are definitely in touch.

our licenses don't go far enough to really protect our communities from being pillaged by corporate raiders

Copyleft licenses were designed in part to address this. For a refreshed, easier to read take on copyleft, see Parity.

[vsoch]

I was really happy when I found AGPL, but then when you read all the fine print of most open source company guides (e.g., https://opensource.google.com/docs/using/agpl-policy/) I mostly felt like a bad person for using it. I do agree with the article posted that it's an issue if a company takes and isn't giving back (not the case for Google, imho).

[vsoch]

I'm going to do more reading later tonight to see if I can answer your question @nothingismagick. I always get excited when new licenses come out, because it means (potentially) more options for releasing code.

[kemitchell]

I mostly felt like a bad person for using it.

If the point of your license is "share alike!", and some company bans it because they refuse to share alike, I think the company should feel bad, not you!

[vsoch]

Haha, maybe :) I think it's hard to read a beautiful page of docs (e.g., the Google open source pages), one that I think has a lot of good intention and spirit, and then be the "one of those things that isn't like the other" that doesn't do best practice, according to those docs. On the flip side, there isn't the equivalently beautiful resource (as readily available) that makes someone using AGPL feel good about their choice.

[nothingismagick]

@kemitchell - I agree that a company should feel bad, but companies don't have feelings. I mean there is this thing called Corporate Social Responsibility, but that really isn't the same.

[kemitchell]

@nothingismagick if they don't even have feelings, why do we care what their licensing policies say? ;-P

[vsoch]

I didn't get to looking over the "source available" articles yet, but I did look over the article that @nothingismagick linked and wanted to share a few notable paragraphs:

This is something I've been thinking about a bit - how these "unspoken factors" that aren't directly obvious actually create exclusion, and further a divide between haves and have nots. The first example they give is political / regulatory:

For example, in some industries, companies require government approvals, regulatory permits, or private certifications to do business, legally or practically. Those rights often apply only to the specific company that obtains them, rather than to its software more generally, and cover the organization running the software, as well as the software being run. When those rights prove prohibitively expensive or simply impractical for anyone else to obtain, they become means of exclusion.

It's the same idea as air travel. If you have enough finances, you can just start your own air line. It doesn't need to be so great, because anyone else that needs to travel can't afford to roll their own, so they buy tickets from you. And the next paragraph finishes this point, essentially saying that in this environment, the licensing (or the fact that "you could build / deploy this if you wanted" is totally irrelevant.

Companies holding such exclusive rights can freely release their software as open source. They hold a greater power—an effectively exclusive right to do business with the software—that makes the lesser powers of copyright and patent licensing irrelevant.

All summed up nicely here:

Overall, the system excludes would-be competitors. But the software is “open source”, because open source doesn’t reach the dimension where exclusion occurs.

This made me immediately thinking of Kubernetes (and I believe it was also in the author's mind). It's an interesting project because it isn't technically a company, but there is a company behind it, and now there are many companies providing it.

Some firms dominate whole commercial categories due to overwhelming brand recognition, entrenched and exclusive relationships, or market power. These firms occupy swathes of customer brain space in the addressable market, as vendors occupy booth space on a trade show floor. They stack the odds of the competitive games they play like casinos stack the odds on their floors. So even if a competitor has every right to offer a competing product or service, they may be utterly unable to make it known, make a sale, or meet an entrenched incumbent on terms designed to ensure incumbent victory

And the salient point (that is so true that it hurts) is that the large majority of these cases don't even need all the extra bells and whistles that such a complicated deployment API offers. But because they occupy "customer brain space" (conferences, stickers, and "everyone and your grandmother is using it so if you aren't, you aren't with the cool kids") they drift toward it like dead wood to a dam. And then they are stuck there.

Ha, then he says this directly!

So much so that a great number of those enthusiastically riding this new wave of the orchestrated future clearly haven’t any objective need for its complexity.

And then he directly says what's been on my mind (about Google and Kubernetes specifically) but I'd never have the guts to say, because I tend to like Google.

But the name recognition and technical reputation of Google, the massive budget Google has thrust behind it, and the dynamics of new-hotness in software engineering all conspire to make Kubernetes an industry force. There is apparently nothing Amazon, a behemoth in other forms of consumer and developer attention, not to mention the counterparty of an existing commercial cloud services contract with basically everyone, can do about it.

Whew, what a read! I'll check out the license docs over other dinners this week :)

[Beanow]

Awesome discussion, hope to catch up soon. In the mean time:

Should we add this here or wait until it’s official?

SFOSC is opinion based, so anything contributed in good faith to help build sustainable free and open source communities I think fits snugly here 👍 no need to dodge controversy or wait for results.

[vsoch]

okay! I'd like to take a shot at this, because, why not :)

[Beanow]

So, I finally caught up here. Have to say I'm very excited about https://polyformproject.org/. I have to read up more to see whether I would agree with particular flavours of license, but that is besides the point for me. Because this project is all about cracking a complex problem for the sake of empowering others that want to offer up their software to the commons. I love it!

Also @kemitchell's writing is very insightful. Because of the article, I believe I've changed my mind on whether there's dogma in stuff like the 4 freedoms as the pillar defining open source. Freedom as a counter to (IP law) restrictions makes a lot of sense. But freedom as the end goal doesn't capture the sustainability debate now.

I think it's clear the freedoms allow new forms of abuse and (as @kemitchell aptly puts it) exclusion. It's similar to what #84 is getting at. All the ways that things such as forking or influencing governance can be made prohibitively difficult.

Thinking about that, the idea floating in my head now is; rather than freedom should the end goal be empowerment?

A project with an isolated team pushing out open source licensed code at their leisure, fails to empower people to provide input. A project building absurdly complex software geared towards large teams operating it, fails to empower individuals and small teams running it. A project with poor documentation fails to empower people in comprehending the project. A project that gets undermined by external corps not playing nice, fails to empower itself and other well-willing partners at sustaining development of the software. Android may provide lots of liberties on paper, but the complexity of actually running custom roms that align with what you'd want from your device is so prohibitive, you can say it fails at empowering you to do so.

I can imagine lots of ways to fit these problems under problems of empowerment.

[vsoch]

If you imagine each source of empowerment, and entity to be empowered as separate units, you could actually derive some kind of (subjective) equation that shows the relative empowerment of teams running the software, using it, and developing it. I'd imagine this is optimally balanced, and someone gets unhappy when it's not. Empowerment for:

• developers means taking advantage of what is being provided without giving back.
• the community means being provided the knowledge (docs) and tools (infrastructure, compute, etc.) to best utilize a piece of software (so this is hurt by complexity, or requiring investment in a product to use a service). I would suspect many parties just make OSS appear to be user friendly and fun, when it's in fact not. The 90-95% of people that only see the branding won't know, the 5-10% that try to use it will probably be overwhelmed in volume by everyone else liking it.
• for companies means being allowed to use and distribute the software in some profit making scheme.

In a way, the last bullet is in competition with the first, and that might be what has led to source available licenses. It's two entities acting optimally (selfishly) without considering the entire balance of the landscape. The third bullet says "I will act in my best interest" without realizing that doing so could remove the source of the honey to begin with. This might be an example of how selfish interest leads to bad outcomes, and if the different groups had collaboration and communication in place, it could be fixed.

It's interesting that you coined a project getting undermined by external corps as "fail(ing) to empower itself." @Beanow are you saying it's fault of the project, and not fault of the corps? Or fault of the overall landscape offering ways for it to protect itself?

teams that aren't empowered

[kemitchell]

@Beanow thanks for your interest in Polyform. You may have already noticed there's a newsletter sign-up form on polyformproject.org. We are also actively working on the license language here on GitHub, at https://github.com/polyformproject/polyform-licenses.

[vsoch]

@kemitchell I have a question - what does Polyform refer to, or what were its origins for the group?

[kemitchell]

https://en.wikipedia.org/wiki/Polyform

[vsoch]

Yes, I'm aware that I'm able to search the internet for a definition :)

I'm interested in why your group:

a group of experienced licensing lawyers and technologists developing simple, standardized, plain-language software source code licenses.

chose the term. You don't have any mention in your docs (at least that I can easily find) so I want to suggest that you add it, because others like myself would want to know.

[Beanow]

@Beanow thanks for your interest in Polyform. You may have already noticed there's a newsletter sign-up form on polyformproject.org. We are also actively working on the license language here on GitHub, at https://github.com/polyformproject/polyform-licenses.

I did sign up and star earlier :] hopefully get a chance to take in depth looks soon.

[Beanow]

@vsoch great point! Balancing who gets empowered by what sounds like a key question. If you don't have a perfect optimum (probably always the case), who you prefer I think says a lot about your project/community alignment. But also, are you even trying for an optimum or are you trying to maximize one, possibly at the expense of the other? Feels like an even better heuristic now.

It's interesting that you coined a project getting undermined by external corps as "fail(ing) to empower itself." @Beanow are you saying it's fault of the project, and not fault of the corps? Or fault of the overall landscape offering ways for it to protect itself?

Hmm, I wasn't trying to suggest who's at fault with that. I had the scenario in mind where early day choices in license, governance models, business models, etc, comes back to bite them. Those early choices in retrospect haven't put them in an empowered position in the face of that undermining -> i.e. failed them. A hindsight observation, not a blame.

If you're ask me about blame, I think as a society we shouldn't want companies being hostile towards work created for the commons. So I have as much a problem with why companies aren't held to higher standards as the companies that do go forward with such acts. In practise though I think that viewpoint gets very hairy, especially when the work is arguably created in the commons for the benefit of one company. Where is the line then between competition between companies and damaging support for the commons?

[vsoch]

Where is the line then between competition between companies and damaging support for the commons?

I don't know if there is a line, but damage seems to coincide with too much of a desire for control. Trying to force control over something, whether by license, community rules, or closing up, is destroying (previously) healthy communities. From this article this is what all these business models are missing - the human element:

I’m not sure who my mentee will be when I someday buy lunch, but an important thing of that day for me, as it will be for a mentee, is becoming part of a chain, part of a culture of sharing knowledge, sharing resources, and making sure that others could follow in your footsteps. I didn’t fully appreciate this until much later, the idea of helping people bootstrap a path. I think many people who’ve had this experience didn’t realize it at the time and might not realize it now, and so might not realize what’s happening, or not happening, in communities around them. I certainly think that the average company stewarding a successful FOSS project into a huge IPO doesn’t realize this.

It is real, genuine care for a project and people that has traditionally been the heartbeat of OSS. It doesn't fit into an "open source strategy" or business plan or an IPO. People that want to make money, and maybe see if happen by rule or accident, like to make bullet point lists of factors that led to it, and if money is made at the end of the day, nobody can say for sure if it was the bulleted list or something that isn't even measured. But once you have those lists, people get obsessive about them, and try to implement them. That means more rules and control. That's a direct conflict with an open source community - you cannot manage it like an unruly set of curls with a big plastic hairbrush. Sometimes maybe it works and the steps of control are brushed aside or touted as useful, but I think this is a case of correlation and not causation. The lists might actually hurt more than not. This sits true with me:

I do not like the direction that company sponsored projects seem to be going, retreating into silos and having managed communities. Such regressions stifle innovation and reduce the enjoyment skilled developers get from the projects.

The downstream effects lead to a lot of people realizing there is change, a change for the bad, some strange corporate involvement that has them check off the "How to contribute" boxes for a PR instead of sitting with them to talk, and hearing about what they have to say. This leads to models that cause individuals and entire projects to get defensive. Getting defensive means creating more rules to fight the first set (ahem, source available licenses). The author summarizes it well:

My sadness at projects attempting to manage communities with tools and rules rather than mentor-ship and growing a community organically cannot be understated. These are mistakes I’ve made personally and would take back in an instant. If you run a community, don’t make the same mistakes I made.

So - once we've snowballed into a competition of bulleted list vs bulleted list, how do we undo that? How do we get back to human-based rules that are more intuition to be a good person, and to work hard, over anything that must be written on paper in tiny words to fit it all in?

[Beanow]

That's an interesting article indeed. Maybe something we could give a more explicit place within SFOSC. It certainly has good arguments as being beneficial for sustainable communities.

I'm not completely sure what you're suggesting though. Are you concerned the source available licenses are leaning towards this tools and rules approach?

[Beanow]

Just found out working on #79, https://github.com/drone/drone/blob/master/LICENSE has a very similar language to what I imagine a polyform trial & smb would look like, in an open core fashion, having the core available as Apache 2.0 and the agents you would need for clustering as Source Available. And are still updating it. https://github.com/drone/drone/commits/master/LICENSE as recent as 17 days ago.

Edit: more info in the forum FAQ post
https://discourse.drone.io/t/licensing-and-subscription-faq/3839

Why does Drone charge an Enterprise License fee?
Maintaining a large open source project and supporting a large open userbase requires significant financial investment, even though we typically think of open source as free. This includes the cost of full time developers, designers, writers, support personnel and more. The typical annual cost to maintain a large open source project can range from hundreds of thousands of dollars a year to tens of millions of dollars a year.

For Drone, the Enterprise Edition subsidizes these costs. We expect successful companies making hundreds of millions or billions of dollars to purchase a license in support of both the project and maintainers. We look at this purchase as an investment. You are investing in the future of Drone, to ensure the tools you are using today still exist tomorrow.

Finally, I want to point out that we try to give Drone Enterprise away for free to as many developers as possible. Please consider that Drone Enterprise is free for virtually 100% of individuals, 100% of non-profit organizations and educational institutions, and 95% of startups and small businesses worldwide.

[Beanow]

@bradrydzewski just a heads up of drone being mentioned here (let us know if there's any issues with that). And would love to ask if you want to share some comments on this. Drone was previously all Apache 2.0 right? What motivated the change?

[bradrydzewski]

@Beanow thanks for the polite heads up. I could probably write a series of blog posts on this topic...

This story will probably sound familiar. I open sourced Drone in 2014 under an Apache License. By 2015 the project had become so overwhelming and demanding of my time that it felt like I was working two jobs. I decided to quit my day job and work on the project full time.

After two years of working on the project without pay I was no longer able to sustain and was facing serious burnout. I unsuccessfully tried to fund the project through various means (donations, etc) but ultimately settled on open core. I removed one (popular enterprise) feature from the public repository and made it private. I had a half dozen paying customers the very first week.

In 2018 I combined the private code and open source code in the same repository at the request of my customers, who wanted the ability to contribute to the private code. I released the code under a variant of Kyle's Prosperity License. I knew I did not want to earn my living from other independent developers and small businesses, so we added the following clause:

Contributor waives the terms of rule 1 for companies meeting all
the following criteria, counting all subsidiaries and affiliated
entities as one:

1. worldwide annual gross revenue under $5 million US dollars,
   per generally accepted accounting principles

2. less than $5 million US dollars in all-time aggregate debt and
   equity financing

This is the history behind the current project license, in a nutshell.

Looking back I believe open core was the right decision at the time, however, I am convinced we can pave a better path forward. Kyle mentions this above, but I strongly believe advancing copyleft and selling copyleft exceptions is worth exploring. History shows this approach works without sacrificing user freedoms. I recommend reading some of Kyle's excellent blogs on the topic [1] and I also recommend reading why Stallman supports Copyleft and selling exception [2]

I've considered selling exceptions acceptable since the 1990s, and on occasion I've suggested it to companies. Sometimes this approach has made it possible for important programs to become free software. - Richard Stallman

[1] https://blog.licensezero.com/2019/04/10/case-for-selling-exceptions.html
[2] https://www.fsf.org/blogs/rms/selling-exceptions

[kemitchell]

The Prosperity license @bradrydzewski mentions is here: https://licensezero.com/licenses/prosperity

Prosperity is essentially Creative Commons' NonCommercial language grafted onto a software license, with built-in provision for a free trial.

Polyform is developing language that will to a large extent track both Prosperity as published and Prosperity as supplemented with @bradrydzewski's waiver for small businesses.

[vsoch]

@kemitchell is there a reason you are not answering my question? I'd really like to know the history of Polyform relating to your group. To reiterate what I asked (so you don't have to find it again):

---

I'm interested in why your group:

a group of experienced licensing lawyers and technologists developing simple, standardized, plain-language software source code licenses.

chose the term. You don't have any mention in your docs (at least that I can easily find) so I want to suggest that you add it, because others like myself would want to know. The metaphor of different pieces coming together to make a larger thing doesn't fit well, so I'm curious. What is not clear is (in the metaphor) what are the pieces, and what is the whole?

[kemitchell]

@vsoch, between projects like Polyform, Blue Oak, and my law practice, I'm a little busy.

I'm sure we'll get around to saying something about the name on the website when we update it.

[vsoch]

You must be very important and busy... sorry to bother you.

[kemitchell]

I am hardly important, but very busy!

[Beanow]

@vsoch, a fine question but please keep things respectful.

[vsoch]

I mean no disrespect. I'm not used to talking to anyone but programmers, and I've never had someone tell me they are too busy to answer a question. I don't know how to respond other than apologize.

[Beanow]

If I'm mistaken about sarcasm in the comment, then by all means disregard my heads up.

[bradrydzewski]

The metaphor of different pieces coming together to make a larger thing doesn't fit well

I am not affiliated with Polyform and do not speak for Kyle, and I don't want to turn the thread into a naming discussion, but I think the name really works. As I understand it, the goal of the project is to provide a way to "build" a license by choosing from a base template and a standard list of clauses. For example you could choose the SB clause to make your work available to small businesses, or TR to make your work available for a trial period. So in this sense, you are assembling a bunch of pieces to make a license. There would be a finite number of combinations (Polyform SB, Polyform SB-TR, etc) which would drive standardization.

[vsoch]

Oh, I understand, that's really cool! I was imagining a single license as a whole, and unsure about how it could be broken into pieces. This model starts with pieces, and assembles a license from that. That makes a lot more sense than "finding the perfect license" I think, and then as a result, coming up with umpteen new ones. Do you know if they also take common previous licenses and try to fit them into this model? Thanks @bradrydzewski

[kemitchell]

@vsoch, @bradrydzewski more or less got it, from my point of view. But I'm just one participant in Polyform, and was just one participant in the naming process. I can't speak for the group as a whole, but I think the group will eventually say something about it on the website.

[vsoch]

hey @kemitchell a little off topic (but similar in spirit) could you work on privacy policies too? I just read this and the problem seems similar to open source licenses - too much content shoved into one unit, maybe it could be broken into modules, and then each selectively used?

[vsoch]

And a question for everyone - how does privacy relate to open source? It seems like it's more a corporate thing, because the implication is there is some service that has consumer data that needs such regulation.

[nothingismagick]

That sounds like a completely different issue, to be honest.

[Beanow]

And a question for everyone - how does privacy relate to open source?

Maybe #85 is a good thread to read for that question. The same question can be applied to privacy: is it a best practice or should it be a principle (or else you would damage the whole ecosystem)?

But yes let's ask that question in a new issue, or #94 discord :D