The Commons Clause is an existential threat to open source - <AUTHOR> https://drewdevault.com/2018/08/22/Commons-clause-will-destroy-open-source.html <comment><USER3> Regardless of whether or not it is harmful to open source, I find the choice to use two words beginning with C (thus CC as an acronym) flawed, as that abbreviation is typically used to refer to Creative Commons, and Commons Clause and Creative Commons sound quite similar too since they both use the word Commons.

I would hope this was not an intentional choice to sow confusion.

Edit: obvious spelling error :)

<comment><USER4> Between the name, the abbreviation, and the suggested usage of "Apache + Commons Clause" for a proprietary offering, this "Commons Clause" project has severe problems with deceptive messaging.

If it was unintentional it was incredibly foolish; if it was deliberate....

Either way it should be junked.

<comment><USER5> The plus sign suggests an additional right, as a dual license would offer, instead, it _removes_ rights from the Apache license. I don't think that's an accident because judging from the website, this seems to be a very serious attempt to put a positive spin on "look but don't touch" style proprietary licensing schemes. Fuck this.

<comment><USER6> In other words, it is no longer Apache license and it is NOT ALLOWED to use Apache Software Foundation trademark Apache.

Call it Indian license or what not.

This is unlike GPL which allows the use of the name as long as the clauses are not restrictive.

<comment><USER7> how can extra clauses not be restrictive? I mean, if they don't add new restrictions, what do they do?

<comment><USER8> I guess a clause could specify exemptions to previous clauses.

<comment><USER5> Exactly. This used to be quite common, see for example [https://en.m.wikipedia.org/wiki/GPL_linking_exception](https://en.m.wikipedia.org/wiki/GPL_linking_exception)

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Another problematic aspect of this is that to me the Redis situation seems like a corporate grab of open source software after the fact.

By that I mean, Redis Labs are not the creators of Redis. They are a consulting agency that then hired the creator of Redis. In other words, they only exist because the original Redis was not Commons Clause. Now they want to build a moat so others can't do what they did.

Not a good precedent.

<comment><USER10> Fake news, according to the man himself: [http://antirez.com/news/120](http://antirez.com/news/120)

The whole thing is evidently not about Redis, but modules that were developed by Redis Labs.

<comment><USER11> People need to stop using the term "fake news" it is more a meme at this point than constructive English.

Even reading that statement and assuming the best intentions I can see why people would be upset/concerned. Redis has gone from Open Source to "Open Core" with some of the best modules now essentially paid for.

<comment><USER12> > People need to stop using the term "fake news" it is more a meme at this > point than constructive English.

Just yesterday the most powerful politician from my country (a EU and NATO member) said during a live interview on prime-time TV that George Soros had sent 4 men in order to assassinate him last year (spoiler alert: they didn't succeed, even though they had been checked-in at the local Hilton hotel). His right-hand man had an interview the day before that saying that the KGB (yes, the Russian KGB) had tried to recruit him (spoiler alert: apparently the Russians didn't succeed). All I want to say is that "fake news" is indeed a live and active concept, just trying to hide it under the rug won't bring back the former, saner times.

<comment><USER13> I think you miss the point .

Call a lie a lie, and don't trivialize it with the cute meme of the day.

<comment><USER12> > cute meme of the day.

I don't think I'm missing anything, I'm afraid "fake news" is here to stay, is what propaganda was back in the 1920s and '30s. Calling it a "lie" means that the person saying the lie and those "receiving" it would change their views once the lie is "exposed", but under the current media and political climate I'm afraid that won't happen anymore, i.e. people will keep believing the "fake news" no matter if it would get "exposed" or not.

</comment></comment></comment></comment></comment></comment><comment><USER14> 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.

<comment><USER15> Hi Kevin, Drew here. Thanks for sharing your thoughts.

I appreciate your response, but I find it frustratingly vauge. What kinds of bad things happen to open source projects that drive them to this? If you are fearful of open source becoming more closed, why are you promoting that very approach?

Did you consider promoting alternatives like AGPL first? Before I see an option violating one of the four essential freedoms I would really like to see a detailed exposition on why the AGPL or other approaches discussed in my article are not suitable. I don't think that the brief summary on AGPL on your website is detailed enough - it doesn't have any specific criticisms of AGPL.

The problem with "needing to change their license" is that it's really just a few people who "need" to change it. In reality, open source projects are community works, and even the maintainers don't have the (certainly moral, and usually legal) right to change the license.

I think your Commons Clause gives vulnerable people (open source maintainers struggling to make ends meet) an easy but despicable option for their projects. Especially in cases like Redis, where a company has ulterior motives and employs the maintainers, they can strongarm maintainers into making choices which are not in the best interests of the project.

<comment><USER14> 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/](https://commonsclause.com/)

<comment><USER16> No, it's not bad behavior, it's a fundamental misunderstanding of open source economic models, and a desire to have your cake and eat it too.

I will steal an argument from a friend who has been doing free software/open source for 30+ years now.

Y'all created a bunch of open source software, it became valuable. Y'all think that you should get to extract some percentage of that value, and that others being able to do it instead is "bad behavior".

But this is very very wrong, and if that is your understanding of open source, you really should say screw it, and take your ball elsewhere. Try it. See if you can create the same amount of value.

In fact, it is your attempt to "extract your share" that is the bad behavior. You cannot, in fact, have your cake and eat it too. If you and others all get to extract your "fair share", that software will cease to exist. This is not theoretical, this is what has happened every time. That is because the value exists because you made the software free. If you didn't, people would have used something else that was free and worked well enough. Also not theoretical. When i review diligence from companies as part of M&A, the _vast_ majority (90-99%) of software is free software, not commercial software.

This paradox has existed since free/open source/etc software was created. The solution traditionally is for developers to just be happy creating cool software and making a living on it. I have rarely, if ever, seen this fail to work at the scale seen here. It certainly fails in smaller scales, but you are not solving that problem even a little.

Instead these claims of bad behavior only seem to come up when people see a billion dollar ecosystem and think they deserve 50% of it.

You are pretty much never going to get anyone worked up over that. Because they shouldn't be. Of all the injustice in this world, this doesn't even register.

<comment><USER14> 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).

<comment><USER17> > _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_

Please, _please_ clarify what those 'other things' are.

Both the Commons Clause FAQ and your comments here repeatedly imply this is about handling "specific bad behavior", "other things... forcing projects to close", and "the most predatory of use cases". But nowhere is there any clarity about what these dark forces _are_. What's 'predatory'? Are we talking about harassment by contributors? Extortion by lawsuit? Cloud hosting for a fee? Just contributors undercutting the business offerings?

The only motive explicitly clarified in the FAQ is the need to monetize, which is what Drew's piece challenged. In response there's this suggestion that the clause is actually defensive against some sort of attack by contributors and so it won't affect most people. In the comments here, you've said it's not your place to call out specific actors, but haven't given any example of what sort of behavior you mean.

It sounds like there's a real problem here, deeper than "we want to make money like RedisLabs", but this conversation is hopeless as long as that problem goes unstated. I don't think it's fair to say people are being un-empathetic to actual developers when no one can understand what situation we're supposed to be showing empathy about.

<comment><USER18> > It sounds like there's a real problem here, deeper than "we want to make > money like RedisLabs", but this conversation is hopeless as long as that > problem goes unstated. I don't think it's fair to say people are being un- > empathetic to actual developers when no one can understand what situation > we're supposed to be showing empathy about.

This.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> I wish there were more publications on how open source is really funded. Earlier Linux and BSD kernels were made by a combination of researchers, people with spare time, volunteers as well as big companies who paid people full time. We see much more of the latter. Intel has an entire OSS division in Portland, OR that writes most of the drives, works on Linux kernel patches, etc. Nintendo and Sony both use big parts of the BSD TCP stack in their operating systems and have an interest in contributing and keeping it up to date.

But open source didn't depend on these funding models in the 90s/2000s did it? I did a whole post on the philosophy of open source a while back:

[https://penguindreams.org/blog/the-philosophy-of-open- source...](https://penguindreams.org/blog/the-philosophy-of-open-source-in- community-and-enterprise-software/)

..but one of the things I didn't find enough sources on where a lot of funding came from (And percentage of volunteer contributors).

This recent Redis things reminds me of the Caddy controversy, and maybe even more recently, how Win/Mac Docker binaries are behind a login wall.

What changed? Do developers no longer have the time to volunteer to work on this stuff? The desire? Is the demand for tech in The Valley/West Cost changing the dynamics of how much time people have to contribute. Were the earlier efforts way less commercial and new efforts moving much faster and requirement more maintenance/resources?

<comment><USER16> "What changed? Do developers no longer have the time to volunteer to work on this stuff? The desire? Is the demand for tech in The Valley/West Cost changing the dynamics of how much time people have to contribute. Were the earlier efforts way less commercial and new efforts moving much faster and requirement more maintenance/resources?

"

What's changed is that once open source started getting serious VC's, people believe they've created tons of value, and should be able to extract some of it (in reality, the model created most of the value, not them).

In the past, people were just relatively happy to be doing okay for themselves while created cool software.

Once you try to move to "value extraction", things become a lot thornier because you discover you aren't as important as you thought you were - <USER2> attempts to extract value fail. Usually, because it was not you who created the value, but the model.

<comment><USER20> Some are seeing that corporations are the ones making all the money on the back of open source software. It's hard to want to contribute to something like open source infrastructure tooling, when it's use case is purely commercial, for example. I imagine some also feel that it's setting an unrealistic value on digital products, at least I do. Why would I want to build a tool for corporate infrastructure if they take it and make millions while I run support for free? They aren't about to Open Source my rent.

I would much rather an honest transactional relationship for commercial software. That also includes consumer commercial software, like phone apps and websites. If we had honest expectations about the cost of software we wouldn't see so much aggressive advertising and tracking.

There are fantastic use cases for the generosity of open source. Education software is something I whole heartedly agree should be driven by open source. But I feel open source has been taken advantage of in commercial settings.

<comment><USER16> "Some are seeing that corporations are the ones making all the money on the back of open source software. "

That is often true, but i guess i try to be pragmatic. I did not create the corporation or do all of that work to make that happen. Maybe people think this is easy, but it's not. it is a _lot_ of work in most cases.

I also get paid plenty. Why should i care that someone else is getting paid more? None of this was ever about making significant amounts of money, and open source is almost certainly a bad model to achieve that for real. It tends to create lots of value and attempts to distribute that value usually destroy it.

I may be weird about this though. I have plenty of friends who have made hundreds of millions or billions building those corporations. I chose not to do that, and instead be happy with what i've got (and i've got plenty) and value different things.

<comment><USER20> It's not really an issue to me that someone else is making money, I understand I could come off as a budding capitalist who's mad they are missing out on their cut. But that's not the case. I have always felt OSS was an embodiment of human generosity, and it just seems that it's been commandeered by commercial interests. Passionate devs are happy to keep working on it anyway, because it's fun. Their efforts might have been better spent on more altruistic OSS projects, but that's not my decision to make, and I don't exactly lead by example.

</comment></comment></comment></comment></comment><comment><USER16> So let me see if i've got the details right:

1\. A group of people go off and, without involving their communities at all, try to solve a problem they think they have.

2\. They spring it on their communities suddenly and without warning

3\. Negative reaction ensues.

4\. People decry death of open source.

5\. Author of clause bemoans on twitter that the reaction of community should have been collaborative problem solving (and "starting a conversation"), despite completely failing to attempt collaborative problem solving with their community.

Is that about right?

If so, this is a great object lesson in how not to do this.

If you want the reaction to be collaborative problem solving, engage people in collaborative problem solving.

If you want the reaction to be to your solution, present people a solution. But expect people to do precisely that!

This is like when people drop completely designed/implemented megabombs of stuff on OSS projects and then complain when there is pushback.

</comment><comment><USER21> > including without limitation fees for hosting or consulting/ support > services related to the Software

Wow! That seems like a mistake. This casts too wide a net and catches more than it should.

> ... product or service whose value derives, entirely or substantially, from > the functionality of the Software...

Ugh. Instead of unambiguous freedom-granting terms, this leaves it up to a court to help determine this vague notion of the product or service's "value".

Steer clear of these license terms!

EDIT: deleted request for OSI to clarify

<comment><USER22> Why do you want OSI to weigh in? The license describes itself as not Open Source, according to [https://commonsclause.com/](https://commonsclause.com/)

> It this "Open Source"? [sic]

> 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".

<comment><USER21> Good point. I will delete this request.

</comment></comment></comment><comment><USER23> There are several challenges here.

One challenge is the name "Commons" is very misleading. It's not creating a commons, and it's also confusingly similar to the term "Creative Commons" which has been around for a really long time.

Also, the Commons website says that the Commons license is not OSS "at least not by the official definition set forth by the OSD". Yet that _is_ the official generally-accepted definition.

<comment><USER24> > One challenge is the name "Commons" is very misleading. It's not creating a > commons

"Commons" isn't the thing the clause creates, it's the problem it aims to solve. Naming contract or license clauses after the problem they address is not uncommon.

<comment><USER25> It would be terrible PR to call this the "Anti- Commons Clause", but it would indeed be accurate.

</comment></comment></comment><comment><USER26> Maybe open source is just not keeping up with the real world, a few things could destroy it: lack of open source license choices restrictive enough and clear enough and enabling openness so much that most businesses can't profit in any significant way from software under those licenses; lack of standardized proprietary licenses for dual-licensed open source project; lack of standardized open source CLAs and CLA integration with popular software hubs.

Ultimately, though, open source has to incentivize independent creators and not big corporations. AGPL is somewhat successful here, because big corporations already ban its use internally, but it's far from addressing the problem. New restrictive licenses are needed.

<comment><USER27> What do you mean by "restrictive" and "openness" here? In particular, how does business and profit affect this? Would it maybe help to distinguish between the goals of Free Software (user freedom) and Open Source (abundance of high quality, royalty free code)?

> AGPL is somewhat successful here, because big corporations already ban its > use internally

The word "because" is confusing me here. As far as I'm aware, the goal of AGPL is the same as that of the GPL: protect the freedoms of users (specifically the FSF's "four freedoms"); the difference is that GPL considers "users" to be those who run the software and AGPL also considers those who interact with the software.

There's nothing about preventing business use; although I believe that in dual-licensed projects, the extra stipulations of the AGPL may boost the appeal of the alternative license. Is that what you were getting at?

<comment><USER28> I think the AGPL point is to say that there is _not_ a need for an anti- commercial license if the AGPL _effectively_ stops the things you're aiming to restrict.

AGPL isn't perfect, but obviously neither is a non-open, non-free anti- commerce clause.

<comment><USER24> AGPL didn't stop cloud hosting providers from offering hosted serviced with the Redis modules at issue, though, because either they weren't making modifications or they weren't deterred by the requirement to share.

RedisLabs wants money, not sharing, from this kind of downstream use, so AGPL doesn't work.

<comment><USER29> No license can work where it isn't used, AGPL included. Redis has been licensed under BSD 3-clause since at least version 2.2[1].

[1] [https://github.com/antirez/redis/blob/2.2/COPYING](https://github.com/antirez/redis/blob/2.2/COPYING)

<comment><USER28> I think the point is that there had been separate _modules_ that were AGPL but still being used…?

<comment><USER27> Looks like it, according to [https://redislabs.com/blog/why-redis-labs- modules-are-agpl](https://redislabs.com/blog/why-redis-labs-modules-are-agpl)

> We wanted to keep our modules open source, so that everyone can freely use > them, enhance them and fix issues. On the other hand, we are a commercial > entity that invests a lot of time, effort and money developing these modules > and verifying they can work under extreme deployment conditions. Therefore, > we wanted to make sure no one else can resell them for commercial purposes.

That last sentence is key: it shows the preamble to be a smokescreen, since they're explicitly stating that they're against the literal number 1 criterion of open source (as per [https://opensource.org/osd](https://opensource.org/osd) ):

> 1\. Free Redistribution

> The license shall not restrict any party from selling or giving away the > software as a component of an aggregate software distribution containing > programs from several different sources. The license shall not require a > royalty or other fee for such sale.

This condition appears _before_ any related to source code. In other words, RedisLabs are pulling the classic "we want our software to be proprietary, but we also want other people to fix our bugs for free" (see also "Shared Source" and [https://en.wikipedia.org/wiki/Source- available_software](https://en.wikipedia.org/wiki/Source-available_software) ).

They thought releasing under the AGPL would strike that balance, but it turns out it didn't so they've now gone to a proprietary license like they always wanted.

</comment></comment></comment></comment></comment></comment></comment><comment><USER30> Relevant: [https://twitter.com/antirez/status/1032180321834467330](https://twitter.com/antirez/status/1032180321834467330)

@Antirez has confirmed the core project is remaining BSD. The "Common Clause" stuff applies to the modules that RedisLabs create.

Additional modules @Antirez creates himself, are also not under Common Clause, they're AGPL.

</comment><comment><USER31> It's just a "free-with-source for non-commercial use" distribution of certain modules that would otherwise be proprietary.

There is nothing to see here, folks; "free-with-source for non-commercial use" has been a thing in the proprietary world for decades. It's like "free trial" or "freemium" with source code.

It's a good thing for customers and would-be customers. Customers can track down bugs and security flaws if they have access to the code. Would-be customers can evaluate the product based not only performance of the executables but code quality.

It is a "better proprietary", in other words.

<comment><USER32> _There is nothing to see here, folks; "free-with-source for non-commercial use" has been a thing in the proprietary world for decades. It's like "free trial" or "freemium" with source code._

Right. And if they would just call it that and not try to make it sound like it's "sorta / kinda Apache licensed" then I wouldn't really care. But it's like people using this clause want to benefit from the general perception of open-ness and the wide acceptance of the ALv2, while not _actually_ being Open Source. It's just dishonest.

<comment><USER31> You are right; if you're going to radically change a license by adding a free- for-noncommercial-use type clause, you should change the name, and don't maintain even the slightest insinuations that it's related to the original license. Textually it may be, but legally it's a completely different beast.

</comment></comment></comment><comment><USER16> All of this has happened before. All of this will happen again.

The guidelines/definitions/blah blah blah exist precisely because of attempts to do this in the past.

If people want to try again, great, let them. Experimentation is good. (I personally wish they'd stop experimenting with repeatedly proven-to-fail models, but c'est la vie)

In the end, it's the developers who are going to decide whether it's the right way for the world to be.

That is, it's not going to destroy open source or anything else unless the people using/developing open source want it to.

Past that, _Kevin_ 's refrain is kind of tired, at least to me. Open source has always been a community that basically eats its own over time (nothing is ever good enough, free enough, open enough, etc). Solving that seems more important than solving this.

Saying "The OSS project we tried to build as a business sinks tons of money into open source and gets no help" as if it was a new problem is just silly. This is not a new problem at all. The fact that they believe doing _literally the same thing that hasn 't worked in the past_ will suddenly work to solve this problem in any meaningful way is disappointing.

For a person whose twitter bio likes to tell me how impressive they are, this is not impressive at all. I would have hoped for something better.

Because if this is all they've got, then yeah, that model of open source is likely screwed.

I will paraphrase a colleague:

The underlying issue they are trying to solve is that developers believe they should be able to extract some of the wealth they feel they created. In open source, that wealth is often only created because the software was free. Otherwise, people would have used something else that was free but worked well enough. Developers like to often argue this isn't true, but history shows it to be true basically always :) So saying you should be able to extract this wealth is probably wrong. Saying you should be able to get paid a reasonable amount of money is not.

</comment><comment><USER33> Let them do what they want; the open source community does not suffer fools.

It's a dirty practice to build something open source and after a certain point, try to close it off. But, it's not unheard of. Any project can change their license, I believe Google did this with Android. Older versions will get forked and others will do with those forks what they choose.

I'm hoping doing this would cause so much backlash that it'll force projects to revert back to OSS. But, it could just push people out of contributing to OSS -- then again, there might be some people more likely to contribute if they knew no one was going to make money off their work.

Let the market sort it out.

<comment><USER19> Google and Android is weirder. The base OS is still totally open source and based on a Linux kernel. But in order to distribute Android with Play/Gapps, you have to join the Open Handset Alliance. You're heavily restricted on what apps you can bundle and you CANNOT manufacture any Amazon Fire devices (or any Android devices that do not contain the Google base services).

The base is open, but what makes it useful is licensed, essentially making the free still crippled. I did a post about Android a while back:

[https://penguindreams.org/blog/android- fragmentation/](https://penguindreams.org/blog/android-fragmentation/)

<comment><USER33> Thanks for the clarification. The more I think about it, the less my comparison applies.

</comment></comment></comment><comment><USER34> Say I made a sizable contribution to an OSS project, one that qualified me as an expert. For projects that have this clause, I wouldn't not be able to make money directly with the source that _I wrote_. I would certainly not lend my expertise to a project that put me in this position, and I would guess that others would feel the same. Imagine if the Linux kernel had this clause. All this "commons clause" will do is remove the community from an open source project, and probably kill open source adoption as a result.

</comment><comment><USER35> The example clause at [https://commonsclause.com/](https://commonsclause.com/) does not really make any sense. It first says you can't sell the software and then provides example text below like this:

Software: [name software]

License: [i.e. Apache 2.0]

Licensor: [ABC company]

If they actually used the Apache 2.0 license anyone would have the right to sell the software. Hence putting that clause and then putting "Apache 2.0" as the license makes no sense. The licensing terms would be contradictory.

<comment><USER36> Yes, exactly. You can't use an unmodified Apache 2.0 license and then try and tack on some extra clause which is incompatible with the underlying license and end up with an intelligible end result. You certainly can't call it "Apache 2.0" and direct people to apache.org. It looks like a legal nightmare.

Even if you like this license, please never use it!

</comment></comment><comment><USER37> Preposterous logic. Therefore WHAT?

> If the Commons clause were to be adopted by all open source projects, they > would cease to be open source, and therefore the Commons clause is trying to > destroy open source

<comment><USER38> Exactly. If everyone used a gun to kill one person, people would cease to exist, and therefore guns are trying to genocide the human race!

Make an absurd assumption, link it back to your pet point, conclude something dramatic, link-baity, and utterly preposterous. For bonus points, attribute a motive to inanimate objects.

</comment></comment><comment><USER39> Does a software license actually have the power to prevent you from selling consulting services? All a license can do is grant you rights you wouldn't otherwise have because of copyright law, right?

I'm new to the matter, but I do see in the Commons Clause an intent to manipulate and mislead. If the goal is to provide an option for companies who would otherwise take their software closed-source, why does that option have to sound super-duper open sourcy while not having terms recognizable as open source? I'm not even a rabid free software guy or anything, but just compare the name to the terms. There is no possible way that "Commons Clause" is not intended to be confused with, or somehow gain a positive spin that has nothing to do with its content from, CC or Apache Commons.

People who care about things like Creative Commons or about open source as anything more than "source available" will label this as "evil" or at best a marketing ploy.

<comment><USER40> Services+software is older than software licensing itself.

DFSG #6 is written to address this specifically: "No discrimination against fields of endeavor, like commercial use." [https://en.wikipedia.org/wiki/Debian_Free_Software_Guideline...](https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines)

</comment></comment><comment><USER41> I think that the Commons Clause is good for Open Source. There aren't many alternatives at the moment; it seems better than allowing external corporate sponsors to dictate the direction of the project.

In the case of Redis, I think that it's a really deserving project and I fully trust the integrity of the people behind it.

As someone who created a popular OSS project outside of Silicon Valley, I can relate to how difficult it is to be an outsider in this industry and I understand why Redis Labs would feel entitled to capture a tiny fraction of the enormous value that they created.

I think that if the Commons Clause is just related to optional things like plugins or addons then I honestly don't see any harm; at least the plugins/addons are still available for small companies to use for free so it's still a step up from the typical OSS freemium model where they sell the plugins.

<comment><USER42> > at least the plugins/addons are still available for small companies to use > for free so it's still a step up from the typical OSS freemium model where > they sell the plugins.

This doesn't allow any companies (except not for profits) to use the plugins without buying them.

</comment></comment><comment><USER43> _An alarmist title, I know, but it's true. If the Commons clause were to be adopted by all open source projects, they would cease to be open source1, and therefore the Commons clause is trying to destroy open source._

But it's not true, it's complete, self-admitted clickbait. An asteroid will destroy most life on Earth tomorrow. If a sufficiently large asteroid strikes Earth tomorrow. It's an overwrought premise leading to predictably overwrought handwringing.

</comment><comment><USER44> > _Without limiting other conditions in the License, the grant of rights under > the License will not include, and the License does not grant to you, the > right to Sell the Software._

> _For purposes of the foregoing, "Sell" means...fees for hosting or > consulting / support services related to the Software..._

Why anyone would ever use this license is beyond me. No paid hosted version. No paid consulting. No paid support.

I mean this is great for folks who have already made their money but for those of us with bills to pay, it's not exactly realistic.

[0] [https://commonsclause.com/](https://commonsclause.com/)

<comment><USER38> > for those of us with bills to pay

Do you think the authors of the software you want to resell don't have bills to pay?

</comment></comment><comment><USER24> I actually think open source will destroy the "Commons Clause", which is just a name for a model that keeps being tried (shared source with limited free use but pay us for the use we think we'd like to monetize) that keeps getting killed by open source again and again and again.

</comment><comment><USER45> After reading your post, your comments here, the Redislabs post and the entire Commons Clause and FAQ, I feel like you didn't read either of them completely yourself before getting all doomsday about it.

Redislabs made a good point, cloud providers are making huge amounts of money off these products and often contribute little back. Take Linode and their Block Storage service for example. They use Ceph, but contribute nothing to the Ceph open source. Or QEMU, the entire basis of their business, and not a single commit from anyone there.

The Commons Clause addressed the AGPL question you ask in your comment.

Redislabs states the goal is not to close source redis core, that will remain free forever, and that the use of the priority modules will be free for most use cases, but when companies makes money from packaging it all up as a service, they should have to pay a license fee, which seems completely fair.

I've worked for a large cloud providers and some small ones, it's pretty common at these places to not care what the License is because as long as it's running on a server, it doesn't matter. And selling service based off them, just means profits without giving back in most cases.

The final point of the Commons Clause says very clearly that this was not meant to be slapped on every OSS license and that it's not a final solution but meant to spark conversation.

In that way, it's working exactly as intended.

</comment><comment><USER46> This argument is theological in that it's arguing against an idea, labeling it heresy. His ideal 'solution' is to just fold it all up and try to forget it ever happened. But you can't fight ideas, ideas provide solutions to problems that people have and if you want people to stop rolling their own solutions, then the orthodoxy needs to make their solutions actually work for actual people, not just the faithful.

Not every business can be Red Hat.

<comment><USER47> > This argument is theological in that it's arguing against an idea, labeling > it heresy.

I find this use of "theological" insulting and not fitting to the situation. "Ideological" or "partisan" would be better IMO.

<comment><USER46> Au contraire, I find religion to be _extremely_ fitting to the free software - open source debate. Richard Stallman himself is very sympathetic to theological analogies for technology debates, calling himself Saint IGNUcius.

[https://stallman.org/saint.html](https://stallman.org/saint.html)

<comment><USER48> Invoking an atheist like RMS doesn't help matters, even if he may have a lot of wisdom and experience in the licensing wars. Conflating an argument over a particular licensing debate in 2018 with deeply-held religious beliefs that may have existed for thousands of years and even inspired actual religious wars (where thousands of people, or even millions -- might as well loop Godwin's law into this debate -- actually died in horrific ways) would certainly appear to be insulting to those who are religious (and many who are not) and might take your irreverence more seriously than it was intended.

<comment><USER46> I think you're overblowing the potential for offense and committing the sin of assuming it's other people and not you that will get offended. If some religious person is offended by the characterization, I welcome them to articulate why. I'm highly spiritual myself and have interacted with many very religious people, and I can say that most of them relish the opportunity to think about worldly things using religious framing.

<comment><USER49> > I'm highly spiritual myself and have interacted with many very religious > people, and I can say that most of them relish the opportunity to think > about worldly things using religious framing.

Would they "relish" your using the term "theological" in the way you did in your original comment? Be honest.

<comment><USER46> Well, they certainly wouldn't take offense to it like a atheist / materialist would at the idea that a debate they care a lot about might be framed that way.

</comment></comment></comment></comment></comment></comment></comment><comment><USER50> I'm genuinely confused why there is so much backlash against the Commons Clause. Ignoring for a second the confusion around RedisLabs and its relationship with Redis core, the Commons Clause is setting out to solve the following problem with open source:

      - A person or company creates an open-source library, at great cost of time and effort.
      - A big company adds that library to their cloud offerings, at arguably far lesser cost, and monetizes it.
      - The library author receives no compensation.

This article seems to argue against the Commons Clause because it's not 'true open source,' but this seems like a purely ideological argument that sidesteps the true problem that CC is trying to solve: open source creators not getting a cut of the profit they are generating for big companies. Am I missing something here?

<comment><USER51> Affero GPL is the license that purports to solve this problem. It's been around for a while, and it's getting some use, but I wouldn't call it popular.

</comment></comment><comment><USER52> GPL does not allow the addition of this clause, anyone who did so would be in violation of the GPL. For license that would allow it, it's not fair to say License+CommonCrap - not to the license, and not to the users.

</comment><comment><USER53> CC should really be renamed to 'Corporate Continuation' (or abbreviation changed entirely).

Commons Clause is misleading in the context of Open source licenses.

On a separate note, it is important to address volunteer open source contribution and development. I think as a community we are missing a model that guides how :

a) developers,

b) their hosting organizations

c) financial contributors / donors

can all benefit from their activities.

Right now, there are different models and experimentation are being used.

But I think we, as a community, could come up with 3-4 models that make it worthwile to the above groups.

<comment><USER54> > CC should really be renamed to 'Corporate Continuation' (or abbreviation > changed entirely).

'Corporate Co-option' or 'Cash Capture' might also be appropriate...

</comment></comment><comment><USER55> Near as I can tell, there's nothing in this agreement that prevents me from choosing another license model.

If I can choose to apply whichever license I want, then it would seem that The Commons Clause could only possibly harm those that choose it.

Anyway, there are plenty of unprofitable licenses out there, and the reality is, for all of them, if you've already given something away for free, once the cat's out of the bag, you probably won't make any money, even if your license doesn't say you're a bad person for even thinking about trying.

That said, The Commons Clause is probably fine for foundations, where lots of people are sharing an array of technologies, and not really asking for money. Meanwhile, it's been several decades of HTTP over TCP/IP, and last time I checked, there isn't a whole lot to lock down, and the real money is in adding reach to flip switches from the other side of a network connection. JSON isn't going away, so, there really isn't much to apply licenses to, in this area, without being silly.

But hey, databases, operating systems, desktop applications, peripheral drivers, all these things still happen, so I guess there's stuff to license. But really all the fringe licenses mostly get applied to JavaScript frameworks, and by the time you actually read a JS library's license, three other projects have replaced it, so why bother.

</comment><comment><USER56> The D programming language uses the Boost license, the least restrictive license we could find. We aren't going to switch to a more restrictive one.

[https://github.com/dlang/dmd/blob/master/LICENSE.txt](https://github.com/dlang/dmd/blob/master/LICENSE.txt)

</comment><comment><USER57> A common fear with Open Source software is "What if someone takes my work and profits from it?". But in my opinion, that's the point of Open Source! If you don't want others to profit from your code, make it proprietary!

But any attempt to make software open source, but still make sure that I get licensing fees or whatnot if someone makes a profit from it, is in my opinion seriously misguided.

With Open Source, our business model should be that lots of people work together to build an ecosystem; no-one profits directly from selling the code, but everyone profits from using the code. Some people contribute to the project because they offer consulting services, some people profit because they use it for their job, etc.

</comment><comment><USER58> Antirez discovered github was using redis by accident on a non related thread here sometime ago, and there was very little outrage.

Open source should be just about taking, if million dollar companies, forget supporting projects they rely on, can't even tell the authors something has gone wrong.

Ideally those who can afford it should throw some support to the projects they use. But clearly this is not happening, if the project becomes too important then they simply acquire the project with downsides for everyone.

There has to be a middle way that has upsides for all parties and untill that is figured out this can work in the interim.

</comment><comment><USER59> I understand the objection but in general I support the Commons Clause-- as long as developers can easily opt out for projects where it isn't desired or doesn't make sense.

Open source developers are building software for free that is then used by extremely large corporations to make vast amounts of money without compensation to the original author. Even worse much of this revenue comes from business practices that the original authors may find highly objectionable including mass surveillance, "surveillance capitalism," and data-driven propaganda, con artistry, and manipulation.

If you create open source today you have no choice but to indirectly offer free labor toward the construction of a global surveillance state. The commons clause offers a way out while still encouraging people to use your software for personal, private, academic, and other purposes and retaining the openness of open source.

The "free as in beer" part of OSS is a relic of the 1990s when the prevailing enemy was "embrace-extend-extinguish" at the hands of (mostly) Microsoft. It was sort of a growth hack to enable open source software to gain critical mass and challenge closed source proprietary platforms.

Times have changed. Today the big threat is SAAS walled gardens, surveillance capitalism, and other business models that in many cases run on and depend upon open source. In some cases SAAS can verge on piracy-- not necessarily in the legal sense since nothing is being done to violate any license but in the moral sense of profiting handsomely from the work of others without compensating them.

Edit: I will provide a concrete example of the last point: RethinkDB.

RethinkDB was probably the best NoSQL database, at least before Mongo was improved enough to challenge it on robustness and versatility. It still has features Mongo and others lack.

Unfortunately RethinkDB the company failed because... well... nobody paid them. Instead they paid services like compose.io to run RethinkDb for them in the cloud. Cloud SAAS database services were making more money off RethinkDB than the database's own developers were. In the end they failed and the project is now almost abandoned.

There are numerous similar examples. AFIAK the Commons Clause would have prevented this, allowing either RethinkDB to capture their own SAAS market or charge compose.io something for making money off their software.

</comment><comment><USER60> It drives me nuts how much people talk about OSS when they need to at least mention the difference between FOSS and OSS. One more reason to stick to FOSS instead, as OSS proponents seem increasingly disingenuous.

<comment><USER61> Help me understand. Which of the following are FOSS licenses and which are OSS licenses?

\- Apache

\- Apache + Common Clause

\- BSD

\- MIT

\- GPLv2

\- GPLv3

<comment><USER60> The FSF can explain it better than I can.

[https://www.gnu.org/licenses/license- list.html](https://www.gnu.org/licenses/license-list.html)

[https://www.gnu.org/licenses/licenses.html](https://www.gnu.org/licenses/licenses.html)

<comment><USER61> > It drives me nuts how much people talk about OSS when they need to at least > mention the difference between FOSS and OSS.

Maybe because like you they find it hard to explain?

According to your linked resources, it appears that everything except the Common Clause is FOSS.

So, basically everything I've ever seen is FOSS.

<comment><USER62> > According to your linked resources, it appears that everything except the > Common Clause is FOSS.

> So, basically everything I've ever seen is FOSS.

Correct. Free Software just puts more attention to the freedom part of software.

GNU has a nice diagram and some category definitions for software at [https://www.gnu.org/philosophy/categories.html](https://www.gnu.org/philosophy/categories.html)

</comment></comment></comment></comment></comment><comment><USER63> There are 2 separate issues here:

1\. The existence of the Commons Clause. 2\. The application of the Commons Clause to software that previously was not subject to it.

To the original author: How would your view be different if a company released a _new_ product or module that was Commons Clause-licensed from day 1? Would that still be a threat to open source? (What if the alternative to it being Commons Clause-licensed was that it wouldn't exist at all?)

</comment><comment><USER64> As a non-commercial user, I'm okay with using stuff that's for non-commercial use only.

The problem is when I want to, say, copy a few functions into my own project which I'm publishing under completely unrestricted terms (say, Unlicense). Or use as a dependency, etc.

So, I'd say it's okay-ish for "product-like" stuff, for user-facing applications. But please NEVER publish libraries everyone depends upon under these terms.

</comment><comment><USER65> I can see their side. GPL was called copyleft for a reason, a nod to copyright. It's a copyright restriction which limits redistribution to certain terms.

Cloud providers do redistribute. It runs on their servers. They do not have to honor copyright restrictions. They can make proprietary modifications and keep them, and they do. They might be honoring the letter of the license, but certainly not the spirit of it.

<comment><USER66> Don't we have the AGPL for this purpose to require them to contribute back their proprietary changes. As others have pointed out, if this was only about the modifications they would have used AGPL. Instead, and giving the clauses about consulting, it seems more like they are concerned about money than the health of the ecosystem.

<comment><USER24> > Don't we have the AGPL for this purpose to require them to contribute back > their proprietary changes.

That doesn't help upstream monetize; this is entirely about money, not reciprocal contributions of code.

<comment><USER66> That was the point I was trying to make. Guess I didn't word it well :)

</comment></comment></comment></comment><comment><USER67> Here's a possible way around this clause: An AWS-like hosting service prepares images of every clause-bound instance users might want (e.g. Linux + Redis + Redis Add-ons), and provides them completely free for download. They also rent users a virtual machine and the ability to quickly load one of these free images.

</comment><comment><USER68> What's the difference between the Commons Clause and the GPL?

What's the difference between the Commons Clause and the creative commons "nc" (non-commercial) license?

I'm having trouble seeing how the Commons Clause is a threat to open source, while the GPL and Creative Commons are not.

<comment><USER69> Apparently you can no longer do business as a Redis consultant or offer hosting. If it were GPL'd, you could, as long as you don't sell binaries without source.

</comment></comment><comment><USER70> "This Clause is not intended to be applied against at-scale existing open source projects, but incrementally on top of commercial counterparts that need to be transitioned to source-availability to satisfy urgent business or legal requirements."

</comment><comment><USER71> What is the difference between Commons Clause and non-commercial use? Is there one?

</comment><comment><USER72> The answer to this dilemma is something like [https://tidelift.com/](https://tidelift.com/).

This Commons Clause is pure blarney and Drew is exactly right.

</comment><comment><USER73> I don't think the Commons Clause is going to go anywhere: it's not DFSG-free, so Debian and core Ubuntu won't distribute it.

</comment><comment><USER74> Cloud infrastructure (like DynamoDB) is already closed source and nobody seems to care, so this might not even matter

<comment><USER69> AWS doesn't want a monopoly on DynamoDB consulting. At most they encourage certification, probably to motivate people to notice their endless roster of new services.

</comment></comment><comment><USER75> For the Redis example, how does this apply to past versions of Redis? Are we going to see a MariaDB-like fork?

<comment><USER76> As explained by antirez[1] Redis itself wil remain BSD and his own modules will remain open source licensed. Only the modules developed by Redis Labs will have this clause. So no change for future or past versions of Redis.

[1] [http://antirez.com/news/120](http://antirez.com/news/120)

<comment><USER77> On HN: [https://news.ycombinator.com/item?id=17818647](https://news.ycombinator.com/item?id=17818647)

</comment></comment></comment><comment><USER78> Software is hard to monetize, whether it be open source or not.

The best open source monetization case I've seen yet may be SQLite3, which is in the public domain. SQLite3 has a consortium, has some proprietary products (e.g., the more extensive test suite) not available to the public at large (in source form or otherwise), and is so ubiquitous that there are a number of large companies that are so utterly dependent on it that they are practically obligated to be members of the consortium. I've no idea just how profitable SQLite3 has been for D.R. Hipp and friends, and I don't want to know, but I assume it's been good enough that they are happy to continue working on it. SQLite consortium members probably (I imagine anyways) get to influence SQLite3's development, and that's one generic way to monetize source code regardless of license: get paid to do further (specific) development / bug fixes / support, but SQLite3's proprietary test suite makes it very difficult for third parties to be able to have contributions welcomed by the core, which tends to limit third party commercial support.

Choice of license doesn't seem to have that much to do with whether something can be monetized. Consider the Linux kernel, which is GPL'ed: prolific contributors profit mostly by being well-employed to continue being prolific contributors, but almost certainly no one is making a dime from commercial Linux kernel usage without source code distribution. There might be some GPL licensed codebases where the copyright owners are making a few bucks from commercial usage by third parties who don't want to distribute their changes, but probably not a lot. There are almost certainly _no_ BSD/MIT licensed codebases where the owners are making any money from commercial usage by third parties -- the license simply allows third parties to use such code outright with absolutely minimal obligations on the third parties.

You can have open source and monetization for some value of "open source", but not one that most people would really consider "open" \-- getting to see the source code != open source.

Getting paid to support open source (e.g., add features, fix bugs) can be very difficult when it is easy for anyone to do that. SQLite3 has a mechanism for limiting third party contributions (a proprietary test suite) which limits third-party commercial support though in general that would also increase the risk of forks (but SQLite3 is so widely used that forks are extremely unlikely). The SQLite3 approach won't work generically for very many open source projects as it depends on SQLite3's popularity and very widespread use.

The fact is that for many of us open source is just a way to build and maintain a reputation, and we then monetize the reputation.

I myself have been offered payment for development on open source codebases that I maintain, and I always reject such offers, mostly because accepting them would interfere with my main responsibilities, and in some cases also because it's not my right (e.g., I don't think it would be fair to take money to work on jq without giving @stedolan the right of first refusal). If I were to lose clients/employment, I might reconsider this.

<comment><USER79> The real value is not and never the code, but the product that is enabled by software. Software is not and never an end product that gives real value. software creates value by making valuable products possible.

</comment></comment><comment><USER80> Please, somebody fork redis.

</comment><comment><USER81> No it won't. You know what will destroy open source? Lack of money to develop it.

<comment><USER82> I've seen this prediction on a regular basis since the mid-1990s. Usually the prediction hasn't included the qualifier "sometime after 2018". Would you like to add a qualifier to your statement?

<comment><USER83> This is already happens with rethinkdb.

Even after community "acquisition" the development process mostly dead [https://github.com/rethinkdb/rethinkdb/graphs/commit- activit...](https://github.com/rethinkdb/rethinkdb/graphs/commit-activity)

<comment><USER82> This thread is about the health of open source in general. A specific project slowing down doesn't tell us anything about that. Especially since the project you're talking about was created by a business and abandoned by that business when the business situation changed. It seems perverse to infer anything about open source from that.

</comment></comment></comment></comment><comment><USER84> Childhood is believing in free software, adulthood is knowing Microsoft was right.

What kills open source software is greed, and very few people are immune from that.

<comment><USER85> What in the world are you talking about? We're living in the golden age of free software. It's doing better than it ever has before, and even Microsoft and Apple are enthusiastically contributing to it.</comment></comment>


GParted: core features lost due to parted's "improvements" in v3.0 - <AUTHOR> http://git.gnome.org/browse/gparted/tree/NEWS?id=16e2cb1b23c96d6a046e4a4001a05fcad8f7d253 <comment><USER2> The code was removed because it was old, bitrotted and potentially _dangerous_. You really don't want to use old unmaintained code to resize your precious filesystem data.

In any case there are better ways to do this. I have an interest in this, having developed libguestfs[1] and virt-resize[2]. But I'd say that even if you don't use libguestfs, you must use the latest upstream kernel code and tools (as libguestfs does) because that's the code that will not corrupt your data.

[1] <http://libguestfs.org>

[2] <http://libguestfs.org/virt-resize.1.html>

<comment><AUTHOR> I fully agree. Hopefully libguestfs support will be added to GParted soon; as changing the partition layout and resizing the file systems within these partitions is usually a hand-in-hand process, it should be controllable from a single tool.

<comment><AUTHOR> Unfortunately, as I understand it, the tools accompanying libguestfs aren't capable of resizing a file system in-place -- a major downside compared to what libparted could do, as you don't necessarily have a spare hard disk in your servers.

<comment><USER2> This is true, but really gparted doesn't need to use libparted (or libguestfs) at all for resizing. It should just call out to the native tools like resize2fs or ntfsresize. That's all that libguestfs is doing underneath the covers.

While obviously gparted folk have got a bit of development work to do, which you can argue was made necessary by changes in libparted, really they should have taken a close look at all that crufty filesystem code in libparted, run a mile, and used the native tools a long time ago.

</comment></comment></comment></comment><comment><USER3> I am the parted maintainer for Fedora. I also help with upstream a bit (I removed the CHS asserts for example). These are my own opinions:

These 'features' were removed because they were old, not well maintained, and don't fit into the core feature set of parted. You are better off relying on dedicated tools to do your filesystem specific operations.

<comment><USER4> Perhaps I am better off using dedicated tools, but this was the only feature that made Gparted useful to me at all.

I can already resize partitions manually with fdisk; What I liked was being able to resize the partitions, grow the FS to match, and write it all to disk easily.

<comment><USER5> Just because libparted removed that functionality doesn't mean gparted has to remove it. I think gparted already uses a number of fileystem-specific tools; on Ubuntu 11.04 it depends on xfsprogs, reiserfsprogs, reiser4progs, jfsutils, ntfsprogs, and dosfstools. The only problem I can see is if libparted removed functionality that no other free software tools provides.

</comment></comment></comment><comment><USER6> It looks like the same support for all file systems was removed from libparted. According to the release notes:

      Changes in behavior

      Remove all FS-related (file system-related) sub-commands; these commands
      are no longer recognized because they were all dependent on parted "knowing"
      too much about file system: mkpartfs, mkfs, cp, move, check, resize.
      This change removes not just the user interface bits, but also the
      library functions and nearly all of the underlying FS-munging code.
      The code embedded in Parted by which it knew about those file systems
      was so old, unmaintainable and buggy that while seemingly drastic,
      this change is like removing a gangrenous toe.

<comment><USER7> I hope people were running into a lot of bugs and errors as a result of that code in order to get it removed...

Removing code because it's "old" or unmaintainable but which relied on features require seems like a questionable decision to me.

<comment><USER8> Bug rate isn't the only consideration when deciding when to trim a code base. It's usually not even the best one.

Gparted isn't a game. It's a critical filesystem utility. Code that isn't maintainable is by definition vulnerable in terms of both security and functionality.

<comment><USER9> It's bloody filesystem code! If someone has enough access to your system in order to invoke a partition editor on the local machine, security is the least of your worries.

Functionality.. eh. Having used gparted extensively and not having a single problem among hundreds of filesystem resizes, I've got to thank the maintainers for finally forcing me to get off my ass and purchase a commercial solution that can be trusted to not have critical functionality yanked.

So thanks for that.

<comment><USER8> It's not filesystem code. It's a userland utility that has direct access to your devices. No, the security of utilities that can directly IO my disks is never the least of my worries.

> "Having used gparted extensively and not having a single problem among > hundreds of filesystem resizes..."

Cool, just make sure you stick with your legacy hardware. Tell you what, go look at the gparted code, and tell me how it'll handle an HFS on my new 4k sector disks. If you can either reassure me or suggest a patch, I might change my mind.

Edit: I certainly don't mean this to insult any of the work of gparted's devs. I just picked HFS as an example. The fact that gparted works so well is a tribute to those developers (looking at you xilun0).

<comment><USER10> IIRC Os X can now resize its own FS, so we can probably let my beautiful (just kidding) HFS code RIP. I won't talk for the other FS code, I have no special knowledge of them.

I have had no involvement in Parted for years (i'm doing radically different things), but as the one who wrote the HFS shrinking code I think and can explain my opinion on the subject. In summary it's a good idea to remove FS code if it has unknown status because the environment changed, and nobody is there to check every details.

Data security is to be taken very seriously in that kind of tool, and getting confident enough that a good level was achieved was actually what took most of the time when i wrote the hfs shrinker (I even unplugged the computer tens of times while resizing, then checked that the whole content of all files on the whole fs did not changed, then checked that OS X still booted and worked properly, + checked some internal metadata field of the FS, and so over). A correct review + tests in the modern context would take a lot of time, and I don't know if somebody have it but I haven't had in the last few years, still don't have, plus I don't even have the needed hardware anymore, so nobody should count on me.

Also one would have to check that the HFS+/HFSX has not evolved and implement support for interesting additional features Apple could have introduced in recent years.

That makes me a little nostalgic, but I 100% agree that without a careful review it is better to remove it (people who know what they are doing can still use an older version of the software, it's free software after all) than leave that kind of code that is now having an unknown status since the context of the environment has changed.

Of course that opinion is only relevant for the HFS code. I know nearly nothing about the other parts.

<comment><USER8> I am at this very moment working with 4k support in filesystem code, and it is a royal pain. You're quite right about the testing. My development on this is turning out to be largely test-driven.

Much respect to you for your gparted work.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> I don't see why this should be an unsurmountable thing for GParted to implement. If Parted is removing the code because it's unmaintained and crufty, someone else has a well-maintained tool for the same thing. Why can't GParted call mkfs.x? Parted still resizes partitions, after all...

I think the blame is more to be laid upon GParted than Parted; Parted seems to be going about their business normally, and GParted is apparently sticking to a philosophy of strict adherence to libparted without any additional dependencies?

</comment><comment><AUTHOR> I don't get why these libparted features were "deprecated" when their removal leads to GParted 0.9.0 effectively dropping FAT16/FAT32 and HFS(+) support.

<comment><USER12> I guess what's missing is any indication that libparted does not intend to reimplement these features in the future in another manner? I mean it reads to me that gparted is announcing the ability to even use libparted-3.0. I mean there's a reason the libparted people bumped the version number to 3.0 (i.e. freedom to re-design the API), you know.</comment></comment>


Senate Slams Ad Servers for Security Failings - mike-cardwell http://www.theregister.co.uk/2014/05/15/senate_slams_ad_servers_for_security_failings/

<comment> mike-cardwell

      "The Committee on Homeland Security and Governmental
      Affairs said that the advertising landscape as it now
      exists "makes it impossible" for users to be protected
      against malware attacks while visiting sites."

This is the primary reason we need to use tools like AdBlock. Not because Ads are annoying, but because they're a security risk.</comment>


Reply to Sriram Krishnan: Erlang,distribution & bspawner - <AUTHOR> http://bosky101.blogspot.com/2008/05/erlang-distribution-bspawner.html

<comment><USER2> Erlang is terrible for distributed computations, it is even slower than ruby for math :( Network servers is probably the only thing that is worth doing in erlang.</comment>


Google (Maps) messed up with the I5 shutdown - <AUTHOR> I'll keep this short as it's just a personal story from last night.
If you aren't aware, a part of the I5 was shutdown due to snow [1].  We took the day off to drive up the west coast and do some sightseeing, we are from the south LA area.
To make a long story short and get to the root of the issue: Google never reported the I5 being completely shut down.  At most, it showed a lane closure for I5-North.  We were headed south, so we just ignorantly drove right to the shut down only to be turned around.  Couldn't Google have easily noticed that a section of highway is completely dead to traffic?  Apparently it had been for hours, as there were massive lines of directed traffic both to the east and west.
Leaving the shutdown spot, The signs & cops were directing us eastward past Bakersfield to take the 58 and then the 14 south.  But, when we arrived to the 58, the cops turned us away.  This isn't necessarily Google's fault, as there was still a ton of traffic on the road, so I don't know how'd they detect this -- maybe by all the cars headed towards a specific spot and then turning away at the same spot?
[1] https://www.mercurynews.com/2019/12/27/map-i-5-still-closed-by-snow-southern-california-travel-restrictions-updated/ <comment><USER2> I was in the Google-messup, too. Google Maps did not show I-5 closed. When it did it said it would be closed until March 2020. Absurd!

I took the coastal route south on Hwy 101. In Santa Barbra Google Maps directed 100s of cars off 101 to take a 30-minute shorter route around an accident. I was one of the fools who followed Google Maps. We were lead though a maze of windings street way up above Santa Barbra to a road that was closed (probably due to damage from last year's mud slide). It took Apple Maps to gets us out of this hour+ mess.

</comment><comment><USER3> While it really is unfortunate, and so cold for soCal what did Waze say...it appears they got it right...also CHP does stay very very current...maybe for possible extreme weather conditions in any region it would be best to correlate...I know it sounds simple and doesn't fix the problem you faced but I think those making the google service should be able to correlate various information sources..because others did...

</comment><comment><USER4> cad.chp.ca.gov - go to the source for this kind of stuff.</comment>


Show HN: We Built a Search Engine to Uncover Any Audience's Sources of Influence - <AUTHOR> https://sparktoro.com/product <comment><AUTHOR> Hi HN. Second-time founder (previously co-founded Moz), launching our product for the first time today. It's a tool to help founders, market researchers, PRs, & marketers discover the publications and people followed+engaged-with by any describable audience.

Search for "woodworking" and we'll uncover several thousand profiles that talk about woodworking online, then show you the podcasts, websites, social accounts, and YouTube channels those profiles interact-with most.

Feedback welcome; hope the data proves useful to some of y'all for your own projects.</comment>


Subreddit for Siri fails - <AUTHOR> https://www.reddit.com/r/SiriFail/ <comment><USER2> "Subreddit for (Siri fails)" not "(subreddit for Siri) fails"

</comment><comment><USER3> Crash blossom alert!

I read the headline to mean it was an article about the failure if a Subreddit about Siri that failed or was otherwise removed by Reddit.

<comment><USER4> I'm not the only one then. "failures" instead of "fails" would've been clearer.</comment></comment>


Navigating a New Chapter for Zoom - <AUTHOR> https://blog.zoom.us/wordpress/2020/05/04/navigating-a-new-chapter-for-zoom/ <comment><USER2> Giving him the benefit of the doubt on the china stuff, it must personally hurt so much to hear the China allegations. Lives in the us, is a US citizen, creates jobs in the US, but still has his loyalty questioned constantly. He has to have a datacenter in China to serve his customers that need service in china, and people will keep holding that over his head. Must be frustrating, and it's not an argument he can ever win against people that will never trust him.</comment>


The Power to Revoke Lies with the Certificate Authority - <AUTHOR> https://scotthelme.co.uk/the-power-to-revoke-lies-with-the-ca/ <comment><USER4> On EV certs, Troy Hunt rightly pointed that no one really cares about them and many major websites (amazon, youtube, facebook) don't even bother:

[https://www.troyhunt.com/on-the-perceived-value-ev-certs- cas...](https://www.troyhunt.com/on-the-perceived-value-ev-certs-cas-phishing- lets-encrypt/)

<comment><USER5> I care :-(

<comment><USER6> Do you? Are you going to stop going to a site because it's missing a EV certificate?

<comment><USER5> No, but if I'm going to log in it forces me to check to make sure the domain is not something deceptively similar to what I expect, which takes mental energy and is therefore annoying.

Also, unlike apparently everyone else, I care _who_ I'm communicating with, not what their domain is.

</comment></comment></comment></comment><comment><USER7> Here in the UK there is another problem with EV certs, there is no way of registering a "trading name" or "doing business as (DBA) name" against a company so you can only have an EV cert issues against your actual registered business name. If that is different from your trading name and what you use as your domain name then they are less than worthless. For example, if the company is "Widgets of London Limited" but trade online as "Widgets Online" with the domain "widgetsonline.com" they cant get an EV cert with "Widgets Online" as the name - even if they own the registered trademark of it.

<comment><USER8> Seems like you can, by registering a DUNS number, e.g. "Trade and DBA names are verified directly with registration agency or through a verified third party database such as D&B, Bloomberg, or Hoovers." ([https://support.comodo.com/index.php?/Knowledgebase/Article/...](https://support.comodo.com/index.php?/Knowledgebase/Article/View/702/0/ev- certificate-validation-checklist))

<comment><USER9> You're confusing QGIS (the government source) and QIIS (the independent source) - the OP is correct, you'll need a government registered entry for the DBA and these don't exist in the UK.

Visit [https://certsimple.com](https://certsimple.com) from the UK and you'll even see the UI change to remove the DBA option.

Trademarks aren't the same thing as DBAs, but a number of folks would like to get the EV guidelines extended to include trademarks.

</comment></comment></comment><comment><USER10> The idea behind EV's (to tie domain ownership to real-world legal entities) is sound, it's just that the implementation is poor.

If the EV badge identifies a legal entity plus its country of origin, then how is it supposed to be the CA's fault that there's this leaky abstraction of multiple legal entities with the same name in the same country? If we have a good idea and a poor implementation, then the correct response is to fix the implementation, not throw out the whole idea as fundamentally broken.

Unfortunately, there's also not much that the CAs can do to fix this by themselves. If we want to have a digital representation of a legal entity's identity, the best way to do that is to have a first-class digital identity rather than the hack of a system we have today which attempts to create a poorly supported, non-portable identity on the basis of emailed paperwork and phone calls. Such a first class identity - with private keys controlled by the legal entity, entrusted to the entity when it was first created - will allow clients to verify the identity against the _source which actually governs it_.

I can understand the privacy concerns surrounding the creation of legal digital personal identities - the creation of a definitive population ledger that goes along with it etc. But for _companies_? That the US doesn't have such a solution for companies in this day and age is just myopic.

<comment><USER8> But how would that help? Both Stripes would have a valid first class identity with valid keys. How are clients supposed to then check?

<comment><USER10> In the current system, the client must query the CA that issued the EV cert for the legal entity data. This presents a number of problems:

a) not all CAs will present enough distinguishing data to the client. Case in point: "Stripe Inc. [US]"

b) No consensus between CAs as to who will issue a cert for a given legal entity. In other words, there is such a thing as a CAA record for DNS and DV certs, but no such thing for EV certs and therefore no verification flow of for a given legal entity -> which CA is permitted to issue -> which domains have been certified for that legal entity

c) No support for more complex identity usecases including name changes, subsidiaries, brand licensing (this FedEx-looking site is run by Acme Local Fulfillment Inc. which has been licensed by FedEx to use the FedEx brand), etc.

Certificate Authorities are not in the business of establishing identity and so they are fundamentally doomed to doing a poor job of verifying identity. Instead of trying to coerce CAs into the identity business because of the inflexible and glacial pace at which government moves, we should be pressuring government to adopt more modern identification practices.

<comment><USER8> (a) Actually, the CA sends Stripe's actual business registration number in Delaware (4675506). It's the browser who chooses what to present.

(b) Why is this a problem?

(c) Is there any evidence of demand for those usecases? How would you even present them to the users in an understandable way?

 _" Certificate Authorities are not in the business of establishing identity and so they are fundamentally doomed to doing a poor job of verifying identity."_

I don't see how that follows. In fact, I don't see how that's even possible. Whenever you do business with any entity besides the national registry - be it a bank, insurance company, notaries, or even another governmental department - they have to verify your identity. CAs just happens to give you a digital affidavit of the results.

 _Instead of trying to coerce CAs into the identity business because of the inflexible and glacial pace at which government moves, we should be pressuring government to adopt more modern identification practices._

I disagree; we already have problems with too-big-to-fail CAs; governments are even worse. A CA can be told "follow the CAB Forum rules or get kicked out". But you can't distrust a government when they're the only issuer for the sites of the whole country.

Low-coupling is not just good in software development.

</comment></comment></comment></comment><comment><USER11> I agree with the fundamental conclusion that, due to changes in the Internet, CAs are quickly becoming arbiters of what content is valid or not in the public's eyes -- a job they aren't ready for and never asked for. The article linked goes about discussing this issue in a hyperbolic manner and it commits a few critical thinking mistakes despite arriving at a valid conclusion.

Briefly, I'm going to focus on just one of these. I leave it to the reader to spot the others.

Ian Carroll got an Extended Validation (EV) for Stripe in another state to prove that EVs are forge-able. That is, although he followed the guidelines, he believed those guidelines weren't enough to safeguard an EV.

Then when the Certificate Authority (CA) finds out about this and revokes his deliberately misleading EV, Scott Helme writes the article linked accusing and detailing how CAs have too much power, because they can revoke an EV based on arbitrary decisions. He defines arbitrary decisions as "not following the guidelines".

To summarize: Ian Carroll abuses the guidelines to register a deceptive EV to prove that the guidelines aren't enough. Then Scott Helme accuses the CA of not following its own guidelines and of taking an arbitrary decision to revoke Carroll's abusive certificate.

They just can't win.

<comment><USER12> Your argument hinges on your word "abuse". Except there's no abuse. Nothing stops Ian from conducting business legally with that company name. If CAs have a problem, they need to fix the cert system. What should those guidelines look like? "You need to have a legal entity, but not one that conflicts with any big brand names people might know, even if you're legally entitled to conduct business under that name"?

There was no forgery.

<comment><USER13> This is kind of the point really isn't it. There was no forgery or abuse here, the certificate was issued in full accordance to the rules set out in the CA/Browser Forum Baseline Requirements and the EV SSL Guidelines.

If there were any abuse or forgery taking place here the certificate would have been revoked for those reasons and the CA would be held to account for mis-issuing a certificate. That's not what happened.

Given the name of the account that made the comment I'm curious about the affiliation of the author, perhaps they would share that in the interest of transparency?

</comment></comment></comment><comment><USER14> I'm not sure how EV certs have continued to be a thing for so long.

Does anybody trust an EV cert more than a DV cert? It's hard enough to get the average person to check for the green padlock before they enter their password, how can we hope to convince anybody to check the company details in the certificate?

<comment><USER15> I did a contract in a corporate environment where the SSL interception proxy passed-through any site with an EV certificate.

I first noticed that it wasn't intercepting my connection to my bank, and then after some experimentation, that turned out to be the pattern. Sounds stupid, but there you go, somebody uses EV as a signal for something.

<comment><USER16> You made me curious - I work at a company that does that.

As it turns out it appears to intercept everything _except_ connections to major high street banks.

<comment><USER6> I wonder whether they're doing it by IP, DNS, SNI, or certificate. because if it's by SNI or DNS, it's pretty easy to get pass the intercepting proxy.

<comment><USER16> It's by certificate although the company does run an HTTP proxy for techies that doesn't MITM certs.

These days I can't be bothered to circumvent. If I want to do any sort of sensitive browsing at work (e.g. online banking) I just tether my laptop to my phone.

</comment></comment></comment></comment></comment><comment><USER17> I think it's fine that they revoked the cert because Ian's site looked exactly like Stripe. The point he made still stands though: That the EV is pretty much only lipstick.

<comment><USER18> By "site", are you referring to the actual site, or the EV indicator? Because the site itself doesn't look anything like Stripe's[1].

[1]: [https://stripe.ian.sh/](https://stripe.ian.sh/)

<comment><USER8> The Tweet shows part of the site as identical to Stripe's: [https://twitter.com/iangcarroll/status/940281927789146112](https://twitter.com/iangcarroll/status/940281927789146112)

I think the current look was updated later.

<comment><USER13> It was screenshots taken for the purposes of demonstration and wasn't his publicly hosted site. Do you think that he'd take that kind of risk?

<comment><USER8> What kind of risk?

</comment></comment></comment></comment></comment><comment><USER19> I thought they had a bit more background checks for EV certificates but apparently it looks more like some placebo effect than anything else.

<comment><USER20> As far as I know, he legitimately had a company named "Stripe, Inc". It was just registered in a different state.

<comment><USER19> Yeah but I thought EV certificates involved phone calls, manual checks of the website, some basic security compliance... All the kind of manual paperwork & background checks that the standard certificate would not do.

<comment><USER21> right. and he passed the checks because his perfectly legitimate company is also called stripe inc and is also in the US, just in a different state.

now stripe could take this up with the courts about how ian is confusing consumers and so forth, and they would win. but they didn't - they went straight to the CAs, and the CAs folded on an arbitrary rather than legal decision, which is a little concerning, but also not too concerning. the CAs were probably were just alerted to the fact that ian was running a website in an obvious bid to confuse people, and decided to revoke his cert. and honestly I think that's a fine, reasonable response to what ian did -- to help protect people from fraud. what wouldn't be a fine reasonable response is to do the same if he were in fact doing real business as a different stripe with non- confusing logos in a different market, not trying to look confusing on purpose.

there's no reason to be worried about having your legitimate cert revoked because of things like this, just like there's no reason to be worried about having your legitimate website kicked off cloudflare because of daily stormer. ultimately his point is that if EV SSL can do this, it is shit, and on that I agree.

<comment><USER22> >they went straight to the CAs, and the CAs folded on an arbitrary rather than legal decision, which is a little concerning, but also not too concerning. the CAs were probably were just alerted to the fact that ian was running a website in an obvious bid to confuse people, and decided to revoke his cert. and honestly I think that's a fine, reasonable response to what ian did --

Bullshit.

It is utterly insane to accuse him of running this page in an "obvious bid to confuse people" [https://web.archive.org/web/20171211181630/https://stripe.ia...](https://web.archive.org/web/20171211181630/https://stripe.ian.sh/)

It is also utterly ridiculous to describe this as "helping protect people from fraud". There was no fraud.

>there's no reason to be worried about having your legitimate cert revoked because of things like this, just like there's no reason to be worried about having your legitimate website kicked off cloudflare because of daily stormer

FWIW I've had my website kicked off Cloudflare and countless of domain names suspended because a SF BigCo hired an very big international law firm to keep my site offline at any cost.

I wouldn't put it past them to try and get certificates revoked too, but they tend to be able to put out enough pressure to get the domain names suspended pretty fast.

(My site sells legally scraped public data from that BigCo's website, instead of suing me they prefer to just keep my site offline)

<comment><USER8> _It is utterly insane to accuse him of running this page in an "obvious bid to confuse people"_

Scroll down a bit on that page, and you'll see this image: [https://web.archive.org/web/20171211213402im_/https://stripe...](https://web.archive.org/web/20171211213402im_/https://stripe.ian.sh/firefox.png)

Maybe that page was updated later in the day, but before the Web Archive captured it.

<comment><USER22> I'm aware of the image, and even if the page actually looked like that for 10 minutes while he was taking the screenshot I'd still think it's obvious that his intent was not to confuse people with this site.

[https://crt.sh/?id=393002115&opt=ocsp](https://crt.sh/?id=393002115&opt=ocsp)

Just compare the revocation date and the archive.org date. At best they revoked the cert after it had been used to serve a completely different site for many months.

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> EV's are a waste of time. Sites should focus on HSTS, DNSSEC and a CAA record and all the other things that make a difference and actually provide some material benefit and some protection to the end user rather than a green traffic light approach to security.

</comment><comment><USER24> I always like the idea of what EV Certs are intended to be, I just don't think the browser exposure to general public users has any value.

Factoring in EV Certs for systems that are scanning the internet and trying to separate things that might need more validation...think news agencies and the search engines or social media that distribute their content. This illustrates both the benefit and the consequence of that model at the same time.

It would be ideal if there were some type of EV appeals committee to deal with revoked certs that could mandate a revoked EV be reinstated in a situation like this.

There is a place where using the EV model of more comprehensive verification can be beneficial...it's just not to the general public in a browser bar.

</comment><comment><USER25> I don't see the problem. If it was really a phishing site, law enforcement now has the legal address of your registered company and whatever metadata they collect as part of incorporation. I'd say EV worked perfectly.

<comment><USER26> > I'd say EV worked perfectly.

Ian run a legit site, not phishing, so what's perfect in revoking his EV cert and not giving back cash?

<comment><USER25> > Ian run a legit site, not phishing

He originally had a site that looked extremely similar to stripe's official website: [https://news.ycombinator.com/item?id=16939094](https://news.ycombinator.com/item?id=16939094)

<comment><USER13> I can't find any copies of that in any cache showing it was ever actually online, simply mocked-up photos posted to social media.

<comment><USER25> Posted by Ian himself. Why would he go to the trouble of mocking it up?

<comment><USER18> Presumably to demonstrate that a phishing site using such a certificate would be visually indistinguishable from the targeted site.

</comment></comment></comment></comment></comment></comment><comment><USER27> The only thing you need to know about EV is this: If an attacker puts up a MITM site with a valid DV cert, your browser will be like, cool, let's use this less-verified cert instead, because a CA signed it, even though the last time I visited it was an EV cert. Your browser doesn't care, users don't care, it doesn't actually improve security.

</comment><comment><USER28> When I pay with PayPal I usually ask myself if the website I'm on right now is genuine. I check if it's https, I check if the name is on the cert (the green lipstick) and, most important, if my password manager trusts this site by let it search for credentials matching the current url. Oh,of course I'm not on a public wlan... Can't it be easier?

<comment><USER29> 1: Look at the domain... [https://www.paypal.com/.*](https://www.paypal.com/.*) [https://www.stripe.com/*](https://www.stripe.com/*) etc

2: PayPal/Stripe do have their one touch/sso stuff, if sign up with to that you'll have at least an indication if things go weird.

Otherwise you are right. It's a problem but it's a problem with the web, not specifically any payment processors which are all honestly doing anything they can to make these issues a non-issue.

<comment><USER30> Looks at the domain can be deceiving because of IDN homograph attacks.

<comment><USER31> IDN homograph attack should not be an issue in your address bar - <USER2> letter trickery e.g. pаypal.com with a cyrillic а should be shown as xn-- pypal-4ve.com ; it's something that can be solved and is being solved on the UI level.

<comment><USER30> Oh nice, they've fixed it in every major browser?

<comment><USER32> The browser vendors disagree about what the rule should be, to avoid homograph attacks, but it's reasonable to say that if you suffer a Unicode homograph attack in your browser, the first people to blame are at the browser vendor.

Some feel that the correct approach is to whitelist TLDs that have a responsible homograph rule (so, not .com) and show punycode in all other TLDs. Others want to detect whether a name seems "confusing" by some heuristic and show the punycode instead only in that case.

<comment><USER30> Interesting, thanks. Is it difficult to just try to DNS-query for all possible confusing homographs, and display punycode unless all responses are negative? Not sure if that would overload DNS servers too much (maybe limit it to 3 characters and display punicode otherwise to avoid exponential blowup?), but it should be very cacheable.

</comment></comment></comment></comment></comment></comment></comment><comment><USER33> Revoking lies sounds like an amazing power.

<comment><USER34> I was also confused for a moment. The title is an example of a garden path sentence[0]. You get several word into the sentence parsing it one way before you get to a word that doesn't match your initial parsing, so you have to go back to the beginning again and reparse it.

[0]: [https://en.wikipedia.org/wiki/Garden_path_sentence](https://en.wikipedia.org/wiki/Garden_path_sentence)

</comment></comment><comment><USER35> At my work (all B2B SaaS), we have a lot of financial customers that go far down the rabbit hole with us on security and never once have any of them given us grief on DV certs. Most of them also use DV certs. What I don't see much of is LetsEncrypt.

</comment><comment><USER36> Previous discussion: [https://news.ycombinator.com/item?id=15904513](https://news.ycombinator.com/item?id=15904513)

</comment><comment><USER37> Why don't US EV certs specify the state, if that's important in distinguishing US company names?

<comment><USER38> Apparently they do [1]; browsers just choose not to show this.

Though I don't know that most people could tell you in which state Stripe is registered, even if they know it's _probably_ Delaware. Heck I think a lot of people could look at the state name, say "hunh, I didn't realize Stripe was a Montana company!", and proceed to be phished.

[1] [https://news.ycombinator.com/item?id=16939238](https://news.ycombinator.com/item?id=16939238)

</comment></comment><comment><USER17> A green security badget is easier to sell then SSL/TLS/encryption .

</comment><comment><USER39> There are several points in this post but the bulk of it is, I feel, one of those classic fallacies that journalists or security hobbyists often engage in:

"I found what looks like a flaw in a system but I didn't try to exploit it for real, look how clever I am"

So his mate registered a company with the same name as another company and got an EV cert. Well done. Everyone knew that was possible already, at least everyone who has gone through the process. It doesn't matter much:

1\. Ian wasn't actually a phisher or criminal. If he had been, and had used that EV cert to phish Stripe customers, he'd have been reported to the police using the details from the CA and possibly prosecuted. Bear in mind he had to register a company in the USA, not Kazakhstan.

2\. Therefore _in reality_ it is very rare for phishers to use EV SSL certificates. Actually I've never seen it.

So is this a demo that the system is horribly flawed? I don't think so. It's rather similar to people who send 10 spams to some accounts they just registered themselves and claim they've found a way to beat a spam filter so the whole thing is useless ... well, no, you weren't _actually_ a spammer so the filter did the right thing. You're testing a flaw you think sounds realistic but isn't. Another common case of this, someone who beats a DRM system on a game 6 months after it was released and then talks about how useless copy protection is, not realising that after 6 months almost all sales happened already so the system worked just fine from the developers perspective.

What about revocation? Is the CA exercising undue control here? Probably not. CAs have language in the contracts you agree to at the time about how you're not trying to misrepresent yourself as if you were someone else. Ian's argument that he registered a name that happens to be identical to a well known payment processor, but in another state, is _technically_ correct, which is of course the best kind of correct. But the _underlying purpose_ was clearly impersonation, which is a violation of the agreements and thus not only grounds for revocation, but to not do so would rather undermine the whole system - why should Ian get away with it when others do not?

If stripe.ian.sh had been an actual operating company that happened to have experienced an unfortunate naming conflict with the other Stripe, I bet the CAs would not have revoked. They'd have found some reasonable solution - probably by letting the cert continue, on the grounds that no malicious behaviour was taking place in violation of the agreements. But it wasn't - <USER3> was just a dummy site.

Overall I don't understand Scott or Ian's point. Yes, legal names aren't globally unique. Did anyone think they were? Yes, Chrome's EV UI is rubbish and the big players other than Apple tend to have an institutional dislike of EV certs because of historical clumsy attempts at market segmentation pricing by CAs, that were totally unreasonable for companies with lots of servers. Yes, EV is imperfect.

The alternative though is paypal-customer-centerr.com ... which is better, how, exactly? It isn't.

If Scott Helme or Ian Carroll don't like how EV works today, why not go find _actual_ criminal abusers and propose _specific_ improvements that would stop them - perhaps making Chrome's address bar work more like Safari's. Otherwise this is just another blog pointing out security stuff that doesn't really matter.

<comment><USER32> "If he had been, and had used that EV cert to phish Stripe customers, he'd have been reported to the police using the details from the CA and possibly prosecuted. Bear in mind he had to register a company in the USA, not Kazakhstan."

Are you _from_ the USA? Or do you believe its propaganda from outside?

You don't need to even be able to point to the USA on a map to set up a US company and do all this paperwork. You fill out a few forms on a web page, pay a little bit of money, American lawyers sort everything else out. They keep some of the money, the State keeps the rest, everybody is happy. Oh, except your victims. They can call the cops of course, but the State obeyed the law, and the Lawyer just does paperwork. It's not a crime to be the lawyer for a crook.

Why don't crooks do this today? Well, there are two answers. For big crimes, stuff like crooked property deals, they absolutely do this already, it's completely routine. For a phishing site they don't bother because it's not necessary. If 90% of visitors to your unsecured [http://paypal-credit- checking.example/](http://paypal-credit-checking.example/) fill out the form, and you get that up to 99% by obtaining a DV certificate for it, why spend $500 setting up a US corporation for the extra one percent? But if you persuade everybody EV is great, then sure, that's what they'll do next.

<comment><USER22> >For a phishing site they don't bother because it's not necessary.

It also wouldn't scale, domains get blacklisted within minutes or hours, getting an EV cert takes longer than that.</comment></comment></comment>


Git Branches Are Not Branches - <AUTHOR> http://bryan-murdock.blogspot.com/2013/06/git-branches-are-not-branches.html

<comment><USER2> "... Git branches are just labels attached to change-sets".

Then wouldn't the clearest thing be to call them (named) change-sets?</comment>