XiZhao

Many conditions of a project can change when it goes from being a small community to a business that supports billions of revenue with its software.

Ultimately, the Clause is not meant to transition an open source project with the intention of staying open, it's to keep as much openness as possible when events happen that force a project to close certain things.

I think a lot of the fear is that this will make a lot of open projects close up. This is not the case. Other things are forcing projects to close, and ignoring those forces and blaming it on evil investors and business people is not only disconnected from reality -- it's a really sad an un-empathetic view towards those that _actually_ develop this software (actually = git commit history).

I think inverting the power structure between maintainers and contributors is good for openness. The tradeoff here is it makes the project harder to govern and maintain, which an have its own unintended consequences.

Also: there is no longer a source-disclosure requirement built into the license.

Yes, and right below it acknowledges that it is not Open Source and doesn't try to be:

> It this “Open Source”? > No, at least not by the official definition set forth by the OSD. Applying the Clause to an open source project will transition the project to “source-available”.

The Clause was drafted as a reactionary move to solve against specific bad behavior. I'm not entirely sure it's my place to call out these actors (I'll leave that to the users of the Clause), but our job was to open up an option that isn't quite "screw this, let's go full closed source".

See the commons clause FAQ for answers to your other questions:

https://commonsclause.com/

I don't think the Clause is necessarily the most elegant end-all solution, but there are often broad business, timing and legal requirements that make it really hard to draft a full license to satisfy everyone.

In fact, I'd love to see a v2 standalone license. One of the design constraints was size and readability. I think part of the goal here was to start with something extremely short-form.

More broadly, the average OSS license is far from robust.

The Commons Clause clearly acknowledges this in the FAQ:

https://commonsclause.com/

Kevin Wang here. Thanks Drew for the thoughtful post.

I can accept that you might not appreciate my work on the Commons Clause, but I'm glad to see you acknowledge why funding OSS is so difficult.

I think it's okay to fear the world of open source becoming a bit more closed. I do too. Whether that's a better world or not is up to debate, but I certainly don't think so.

I think where we might disagree is what the greatest threat to "open-ness" is. Sometimes people do bad things to open source projects, and force them to go closed. The license choice will inevitably follow -- and when they do, they can choose to close the source entirely or choose a licensing scheme that makes it available.

Licensing follows intent, and I certainly don't think the Clause inspires people to close their source. But sometimes people need to change their license -- and I think it's unrealistic to say that this doesn't happen.

That's true, but Redis is not closed source. This only applies to a few enterprise modules.

As addressed in the FAQ, AGPL doesn't satisfy many requirements -- one of which is that it's often too restrictive in the wrong ways. If not the Commons Clause, a very viable "v2" is just to draft a more cohesive source-available license, or in the worst case move the project to closed source.

If a project has that wide of a contribution base, then the Commons Clause wouldn’t be needed in the first place. I think that’s the problem.

I think this is close, but adds the feature of source availability. I’m the first to admit the Commons Clause bolt-on feature isn’t the most elegant. But, if it’s a bad solution, then people can fork it, and that’s okay. I hope we do, and then find a middle ground that works better for everyone.

In the longer run, there will need to be a happy middle ground for people to

I don’t think anyone is saying this. Sometimes some projects need to change their license, are you saying the maintainers don’t have a right?

That’s okay, but I think there’s two parts you might be missing. 1/ the Commons Clause doesnt apply to retroactive versions and in this case is not applied to Redis core. 2/ The Commons Clause isn’t meant for everyone. In the world of open source, sometimes projects can stay open, and sometimes they can’t. For projects that can’t, sometimes it’s because people do bad things that are disguised as Services but in reality add little value other than resell.

Hi folks. Kevin from http://fossa.io here. I worked on bringing the Commons Clause to life (https://commonsclause.com/) and led many of the project efforts here.

Happy to answer questions here (or on Twitter @kevinverse).

I wanted to write a blog post to set some context because the real story is a lot less salacious then "Redis just went proprietary", but here's a quick summary:

1/ No, Redis isn't proprietary. It's only some enterprise modules. The Commons Clause is mostly used to temporarily transition enterprise offering counterparts of OSS projects to source-available.

2/ OSS projects are mainly funded by some proprietary offering or service on top of it. Anything to help the ability to monetize this layer is really good, as the fate of the project is directly tied to this revenue stream. A quick reminder, companies like Redis sink 10s of millions into RnD and are usually contributing over 99% of the code to these repos.

3/ OSS-savvy companies aren't dumb. They understand the optics of any licensing announcement and carefully consider what it will mean. Before we react, we should push ourselves to understand what systems are forcing deeply passionate OSS devs to consider more proprietary options.

Kevin from https://fossa.io/ here.

We have an open source project just for this: https://github.com/fossas/fossa-cli. It currently supports roughly 20+ build systems and languages, and pairs with our web service for license and vulnerability discovery.

Would love your feedback.

FOSSA | Software Engineering + 3 | San Francisco + Remote, Full-time | https://fossa.io/careers

“Top 5 Open Source Companies to Watch in 2017” - NetworkWorld

FOSSA is a fast growing venture-backed startup developing code analysis tools to help modern teams manage their open source dependencies.

Since 2017, over 4000 open source projects (Kubernetes, Webpack, Terraform, ESLint) and companies (Docker, Tesla, Mapbox, Hashicorp) rely on FOSSA in their critical deployment paths to automate license compliance, vulnerability management, software inventory and more.

FOSSA is an early-stage company backed by Bain Capital Ventures with affiliate angels including Marc Benioff (Salesforce), Steve Chen (YouTube), Amr Awadallah (Cloudera), Jaan Tallin (Skype) and Justin Mateen (Tinder).

Apply: https://fossa.io/careers

TechCrunch: https://techcrunch.com/2017/02/23/fossa-scores-2-2-m-seed-ro...

To learn more about our engineering team, check out our Request for Teammates (RFT):

https://docs.google.com/document/d/1lzvSSAIa1aevAt5dn1d7BYvK...

Awesome work, congrats Hack Club!

FOSSA (https://fossa.io) - SF | Onsite only

FOSSA's code analysis tooling helps teams become successful with open source.

Over 3000 open source projects (Kubernetes, Webpack, Terraform, ESLint) and companies (Docker, Tesla, Mapbox, Hashicorp) rely on FOSSA's tools in their critical deployment paths to automate license compliance, vulnerability management, software inventory and more.

FOSSA is an early-stage company backed by Bain Capital Ventures with affiliate angels including Marc Benioff (Salesforce), Steve Chen (YouTube), Amr Awadallah (Cloudera), Jaan Tallin (Skype) and Justin Mateen (Tinder).

https://fossa.io/careers/

Unfortunately, the permissions issue is a limitation of Github's Oauth API. There's no way to ask for "read-only" permissions using their current integration scheme.

You can, however get a FOSSA API key without signing up for Github -- just register with an email here: https://app.fossa.io/account/register

Thanks! I filed a ticket for sbt documentation here: https://github.com/fossas/fossa-cli/issues/105.

For Golang, you need to be running the cli in a repo within your gopath; we should have some better feedback for it however. I opened another issue here (https://github.com/fossas/fossa-cli/issues/106), anything you can contribute?

I think it's pretty clear that extorting your customers is an awful business idea. ;)

Kevin from FOSSA here -- I hope it's clear that this would be completely against our policies and business model. However, if you're truly worried about this, you can install a fully on-prem version of FOSSA. Use of app.fossa.io with fossa-cli is also an opt-in feature, so by default you're not sending us any data.

Secondly, we deal entirely with 3rd-party code, so the licensing issues and risks are already completely public. If there was truly a malicious actor, they would just scan popular third party modules and reach out to companies that had job postings or github pages that were active in those environments (i.e. scan npm packages and target JS developers).

But in the spirit of good development practices, "security by obscurity" hasn't proved to be an effective strategy. We'd prefer not to promote "legal by obscurity" either. :)

From team FOSSA here, you can put in anything for the company name -- or leave it blank!

FOSSA, Inc. | Backend / Infra Engineer | San Francisco, CA | ONSITE

FOSSA is used by the most popular open source projects (Webpack, Kuberentes, ESLint) and companies in the world to help them understand their dependencies. FOSSA integrates with your development workflow to track the OSS developers bring into your organization and automate license compliance, vulnerability management and more.

We've raised $2.2m from top investors; if you develop software you've probably used something that runs FOSSA. Read about us here: https://blog.fossa.io/announcing-fossa-public-beta-funding-8...

Our Stack: React, Node, Golang, Java, Docker/Kube on AWS, Postgres Familiar Topics: Code analysis, distributed systems, data, developer tools

To apply, email kevin@fossa.io

I don't think the amount of controversy Facebook is receiving on this is justified. The patent license could maybe be adjusted, but people's interpretation on this seems to be geared towards spreading FUD over facts.

Been following stackshare for a while and this is a really exciting new update. Congrats to Yonas and the team!

Hi HN — founder here, and really pleased to share FOSSA with you!

Over the past year, we’ve been incubating the product at some amazing companies like SolarCity and SmartThings (more announcing soon!) to scale it across cutting-edge engineering teams and get it ready for this moment.

Today, we’re also announcing a $2.2MM seed round led by Bain Capital Ventures with participation from humbling angels including the founders of Salesforce, Skype, YouTube, Cloudera, Tinder and others — read more about it here: https://medium.com/fossa/announcing-fossa-public-beta-fundin...

Excited to hear your feedback on what we’ve built. You may have used a free resource on OSS licensing that we created and maintain: http://tldrlegal.com. We see FOSSA as an attempt to tackle similar problems in a commercial scenario.

Rare for a Finance Analyst at the WSJ to make such a simple mistake, but is it so surprising that a media outlet would overlook accounting details in the chase of a headline?

I like how half the internet can die when EC2 has problems.

Actually, the API looks remarkably similar. 1-1 even.