Hacker News Reader

I disagree. It will be harder to monetize MIT licensed projects, because any competitor can just grab and run. With AGPLv3, at least legally the competitor needs to publish their modifications as well. This in turn makes it more likely the competitor will not use your code, or if they do, in accordance with the license, which would be fine, and users of the product you build will mostly not care, because they don't even know what the licenses are about.

> It will be harder to monetize MIT licensed projects, because any competitor can just grab and run.

Importantly - any competitor can grab it and modify it to make it easier for them to run at scale and keep those changes closed-source.

None of the limitations of open-source licenses apply to the authors themselves. (author = the person or organization whose name appears in the copyright notice). I.e., you can have a MIT/GPL/AGPL licensed project, but have a "premium" fork/derivation/later-version of it that's completely closed source.

I actually see this as a valuable incentive to open-sourcing under MIT -- if a commercial provider of your software emerges, it will help you test/prove that a commercial market for your software exists, after which point you can completely close-source it and pivot to purely commercial competition.

Open-sourcing, then, is basically baiting the waters to see if anyone sees commercial potential in your work. And the minute that's validated, you get funding and start your company.

Close-sourcing a previously open source project is like a deathwish for that project. Will meet much aversion, and if the project is important, people will fork whatever the last open source version was. Then you usually lost all cards and don't have a business at all.

Sure, but you're skipping the first part where if you make your project AGPLv3 most users will just choose a different project doing the same thing but with an MIT license.

I agree that if you can somehow achieve widespread adoption with a copy left license (like Linux or Wordpress), then that will be better for you. But IME copyleft licenses are a major hurdle to widespread adoption, so such projects remain obscure.

I'm not saying it is a good thing, but I've never worked at a company where we were allowed to bring in copyleft dependencies (even though everything invariably runs on Linux, which is GPLv2).

If it stays obscure, that isn't necessarily too bad. You respect your users and grant them the freedoms, if they seek them, but if not then that's their choice. It is merely geared against competitors taking and running, making a "better" (moaaar features) closed source version.

Well, many developers publish their code not because they want to specifically make a successful open source project, but because they made something that was useful to themselves, and like the idea behind open source. In that case it makes more sense to do a copyleft license because it will legally require all derivatives to also follow that open source idea.

Yea I think stuff like this is great and will have some impact around the edges. Perhaps particularly in the realm of end-user software, like a window tiling manager.

But once we start talking about the kind of software large corporations (like AWS) will have an interest in, projects have to be successful to be useful. Software requires maintenance so the maintainers need to be able to devote their time to maintaining and improving the project. So this will select for projects that are successful enough that the maintainers can focus on it fully (either because some company hires them to work on their own project, they can charge high consulting fees because of their association with the project, or whatever).

I think "the code" (the thing covered by copyright) in most cases is not as valuable as "the project:" the leadership, the contributors, the users, the norms and practices, the commitment to ongoing maintenance, and so on. So just lots of individuals all putting pieces of their code out there with GPL probably doesn't make a lot of impact (though there is nothing wrong with it), because most users don't want "code" they want a "project" they can rely on.

> once we start talking about the kind of software large corporations (like AWS) will have an interest in

I'm not sure why someone who is spending their limited free time building software to give away for free would want Amazon as a downstream consumer

Do you enjoy spending your nights and weekends dealing with CVE reports, while a high-6-figure BigTech engineer nags you that they need it fixed?

We definitely agree on this point. Different licenses select for different things.

It is an annoying problem to have, but if your goal is to be able to support yourself by working on your open source project full time (not saying this has to be or should be everyone’s goal), then having big tech engineers nagging you is probably a good problem to have.

Honestly haven't seen many open-source maintainers convert a BigTech downstream into recurring revenue. I'm sure it does happen, but its far from the norm

If your project gets adopted by Big Tech then your market rate as an engineer just went way up.

It’s a huge badge of honor and a rare accomplishment. You’re thinking too directly if you can’t imagine how having your OSS project adopted by Big Tech isn’t a career boost.

Maybe it can happen, but ask the people maintaining open source projects long term, how much it helped them pass silly leetcode interviews, which companies insist must be done, even if you have a golden track record.

“Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off.”

https://twitter.com/mxcl/status/608682016205344768

Please see his follow up comments years later where he reflects on the situation and agrees that he should not have been hired at that time.

He posted that in the heat of the moment while angry, but they didn’t literally reject him for a single LeetCode problem. He admits that he was just not at a point where being hired into a FAANG job would have been a good move.

That one Tweet has fueled years of internet rage from people who didn’t get the whole story, though.

I know people maintaining open source projects long term and getting FAANG adoption is a dream come true. That’s why I posted it.

I’ve also worked at companies where people who write OSS have been recruited with comp packages that would be hard to get even at FAANG because their OSS work was crucial to the company.

Maybe in specific fields this is true, but a lot of folks in Big Tech view open source as where developers who couldn't hack the interviews end up (they also hold a pretty similar view of startup engineers, unless they are ex-FAANG)

> I'm not sure why someone who is spending their limited free time building software to give away for free would want Amazon as a downstream consumer

Are you kidding? This is the dream scenario for many open source projects: Getting adopted by a major company is a claim to fame like none other.

> Do you enjoy spending your nights and weekends dealing with CVE reports, while a high-6-figure BigTech engineer nags you that they need it fixed?

Then don’t? You don’t have to do anything. It’s fine to ignore it you want.

Practically speaking, Amazon engineers aren’t going to sit around and hope the maintainer fixes the thing that unblocks them. If they actually need it, they’ll fix it. They might fork it. They might try to recruit the person.

But nothing obligates you to do anything. This hand-wringing about the idea that someone might find the project useful enough to identify issues and report them is rather ridiculous. Just ignore it if that’s prerogative.

Having been upstream of this problem (I was engineer at Amazon for ~5 years), they will typically not do any of those things.

The amount of paperwork they have to jump through just to send you a patch makes it not worthwhile. They might fork in extremis, but to do that they first have to justify to management that it's worth ongoing effort to support. Hiring a maintainer really only happens for truly foundational projects like the Xen hypervisor.

What they will do is use the public nature of the CVE process to pressure you to patch with the SLA - and that's generally pretty effective. Only a few open source groups (for example, the npm team) have enough public clout to reject CVEs without reputation damage.

AWS doesn't seem to have an issue with using copyleft software.

Which copyleft software does AWS use? Linux, certainly. And MariaDB/MySQL (but also the BSD-like PostgreSQL). I was under the impression that it typically avoids GPL software when there is a BSD- or MIT-licensed alternative.

> In that case it makes more sense to do a copyleft license because it will legally require all derivatives to also follow that open source idea.

That is a matter of opinion. I have put out some open source stuff under the form you mentioned, and it's always BSD or another permissive license. I view it as quite wrong to force my moral choices upon others, so I give others the freedom to use whatever license they like. In my case, that is what makes sense because of my own moral convictions.

> People can license their software however they want, but it is worth reflecting on why almost all open source authors go with a permissive license like MIT: because it is basically a "buyer's market." When choosing a database, distributed queue, blogging platform, or whatever, companies usually have a choice of at least several high quality open source options.

> If one of those options places restrictions on the users, then those users are probably going to choose one of the other options.

First, if someone isn’t paying, he’s not buying. ‘Paying’ should be understood broadly, e.g. code as well as money counts. A company paying dollars really doesn’t care that much about the license — plenty of companies pay for proprietarily-licensed products (even ridiculously limited ones, with dongles and high seat prices). OTOH, a company ‘paying’ with code contributions should prefer the GPL, because it knows that its contributions will never be taken away from it.

Second, the GPL does not restrict users; it restricts developers from restricting users.

The GPL family is the right way for individuals and companies to form a software commons in which all can benefit.

Understand your point, but I wouldn't be so sure. People also want to ensure that the software is being supported, the inevitable bugs being worked on, and not abandoned. It is more likely that a commercial project will be supported than a MIT licensed one. So there might not be as many github stars for such project, but on the other hand, as long as it feeds people, it will not disappear.

A MIT licensed project on the other hand, I personally consider like a potential liability more often than not. Not different from any piece of code I could find on stackoverflow. Not something that is serious. Even if it were tied to a big corpo, that would probably become fast unsupported.

> licensing your project GPL or the like usually means relegating it to obscurity

Subjective. Sure if you are talking about percent of market share, but it's a huge market, you don't need to capture even 1% of users to have a viable business.

The vast majority of the GNU ecosystem is GPL. Bash, git, Apache, Gimp, Blender, Libreoffice.

There are also a lot of projects that are dual licensed, allowing commercial software to be charged a fee and non-commercial software to use for free with GPL.

Neither Apache nor LibreOffice is GPL. Apache is permissive whereas LibreOffice is MPL (a sort of middle way between permissive and copyleft).