[HN Gopher] CockroachDB license change
___________________________________________________________________
CockroachDB license change
Author : Cwizard
Score : 356 points
Date : 2024-08-15 14:05 UTC (1 days ago)
(HTM) web link (www.cockroachlabs.com)
(TXT) w3m dump (www.cockroachlabs.com)
| ukuina wrote:
| > On November 18, 2024, we will eliminate our Core offering and
| consolidate on a single, robust CockroachDB Enterprise license
|
| That is incredibly short notice.
| arccy wrote:
| only a problem if you need to update
| kragen wrote:
| even then you've had five years notice that enshittification
| was coming: https://en.wikipedia.org/wiki/CockroachDB#History
| cvwright wrote:
| Making $10M ARR companies pay for the software that they
| use is not enshittification.
| kragen wrote:
| i mean, yes? it is? software you can't use without
| someone else's permission is obviously shittier than
| open-source software you can fork, even if you're a big
| company. perhaps _especially_ if you 're a big company.
| and software that sends telemetry to the vendor is
| obviously shittier than software that doesn't
| CyberDildonics wrote:
| i mean, no? it isn't? changing the license doesn't change
| the software? the software still works the same way?
| nijave wrote:
| In this case, they cancelled a product (core) and
| replaced it with a different product that has an
| additional new license (enterprise edition with a free
| tier)
|
| So not just a license change
| redwood wrote:
| Well if the company can build a business then you can get
| great software to use... while in theory it would be
| great if a bunch of incredible software were done purely
| in the spirit of community open source, in practice
| that's pretty limited
| nijave wrote:
| $10M ARR doesn't mean anything. You could still be a tiny
| company with terrible financials by selling your product
| at a loss (a startup)
|
| It's just an arbitrary number
| veggieroll wrote:
| This hasn't been my experience. After another VC-backed
| software switched licenses, we continued using an older, open
| source version licensed Apache 2. But that didn't stop their
| lawyers from trying to shake us down, claiming we were using
| the latest, enterprise version. We just showed up in their
| telemetry as using their product and they came a knockin. I
| imagine that their telemetry failed to distinguish who was
| running old FOSS from the latest proprietary one.
|
| We showed our lawyers that we were using the FOSS version.
| But, they didn't care and demanded we remove their product
| (despite being FOSS) immediately on all our systems.
|
| That was a crazy crazy week.
|
| You can say that's a problem with our lawyers. But still, who
| wants to go to court even if you know that you'll win
| eventually? It's expensive and incredibly annoying as an
| engineer to have to deal with lawyers.
| geenat wrote:
| Overall I feel like this is a step in the right direction.
|
| I do love Cockroach, but the old licensing model was pretty
| brutal if you required any enterprise features (ex: incremental
| backup).
|
| For reference, some other data stores doing "horizontal scale of
| writes" ..any others I'm missing ?
|
| * MySQL: Vitess, Planetscale, TiDB, MariaDB Spider
|
| * Postgres: Citus, YugabyteDB, YDB, Neon
|
| * SQLite: mvsqlite, marmot
|
| * Document: ScyllaDB, Cassandra, DynamoDB
| ko_pivot wrote:
| I don't believe Neon supports multiple write nodes.
| tristan957 wrote:
| It currently does not, but it's something we would like to
| eventually support.
|
| - employee
| sho wrote:
| > if you required any enterprise features
|
| For me it was the multiple regions. It's like.. with that
| disabled why are we even here? Data residency is the whole
| point...
| madduci wrote:
| The only thing I don't like is the mandatory telemetry.
| ezekg wrote:
| I don't like the fact that even free users need an annual
| license key.
| Thaxll wrote:
| Most of those solutions are not on part with Cockroach,
| Cockroach is basically Spanner usable outside of Google. So
| global transaction with cluster world wide.
| skunkworker wrote:
| Spanner is cheap in comparison depending on your storage
| requirements. I've seen CockroachDB quoted as 10x more, and
| for a product that is harder to sell to stake holders.
| riku_iki wrote:
| There are some contenders in that list: TiDB, YugabyteDB,
| YDB.
| MarkMarine wrote:
| spanner != cockroach. Spanner has specialized hardware with
| atomic clocks. It's better.
|
| https://www.cockroachlabs.com/blog/living-without-atomic-
| clo...
| jwr wrote:
| If what you mean by "horizontal scale of writes" is a
| distributed database, then there is FoundationDB, which is one
| of the _very_ few databases that offers strict serializability
| (see https://jepsen.io/consistency). But it isn't quite
| comparable, because it isn't an easy-to-use shiny tool, rather
| a database-building toolkit (hence the name).
| sidewndr46 wrote:
| What? FoundationDB disappeared down the memory hole whenever
| Apple acquired them.
| hansihe wrote:
| It's still open source and actively maintained by Apple,
| they use it internally.
|
| https://github.com/apple/foundationdb
| mdasen wrote:
| It is now. There were a few years where it had basically
| disappeared (2015-2018). When Apple eventually put it
| back in the open-source world, it was done with little
| fanfare so it could be easy to miss.
| jen20 wrote:
| > put it back in the open-source world
|
| Just to clarify - FoundationDB was never open source
| before 2018. Binaries were available under certain
| conditions, but no source.
| dtf wrote:
| Deno KV uses FoundationDB, for example:
|
| https://deno.com/blog/building-deno-kv
| geenat wrote:
| same guy who wrote mvsqlite btw
| ddorian43 wrote:
| It re-appeared after 10 or so years though.
| sidewndr46 wrote:
| Really, what is the reason why?
| ddorian43 wrote:
| Apple thought it would be in their best interest to
| release it.
| jwr wrote:
| Apple acquired the company in 2015 and 3 years later
| open-sourced the database.
|
| (so much misinformation in this thread, this isn't hard
| to check)
| yencabulator wrote:
| Most of the others listed are relational SQL databases,
| FoundationDB is a key-value store.
| krackers wrote:
| Not a distributed systems guy, but Spanner also offers that
| right? Or at least I'd assume they do considering they
| coordinate with actual clocks so you're naturally tied with
| real-time.
| redwood wrote:
| Odd to see the market leader in this space not listed. It's
| "web scale"
| broknbottle wrote:
| Ah you must be referring to /dev/nullDB?
| redwood wrote:
| Right which has been come along way in 15 yrs
| WuxiFingerHold wrote:
| Neon doesn't horizontal scale of writes. Just like Aurora
| doesn't.
|
| Also, not all alternatives listed are ACID compliant with
| serializable transactions like CockroachDB is.
| tvink wrote:
| Free license:
|
| > Telemetry Required (excluding ephemeral clusters of 7 days or
| less)
|
| So not free, then.
|
| Is there already a popular fork?
| sigmonsays wrote:
| This is really painful, I don't want this pattern of data
| collection being common, Telemetry included.
| kragen wrote:
| it hasn't been open-source since 02019 according to
| https://en.wikipedia.org/wiki/CockroachDB#History so if there
| are popular forks they'd have to be five years old
| cvwright wrote:
| BSL code automatically converts to open source at a specified
| date. So probably several releases since then are now as open
| source as anything else in the world. And if not, then they
| will be soon - BSL allows a maximum 5 year delay.
| kragen wrote:
| that may be (i haven't read the license) but i'm not
| persuaded it's relevant
|
| if nobody forked it five years ago, they probably aren't
| going to fork it now
|
| if somebody did fork it five years ago, they probably
| aren't going to try to merge in new source code drops as
| they convert to open source
| cvwright wrote:
| Then why do you care? If nobody is going to fork it
| anyway, what's the benefit of being open source from the
| beginning?
| kragen wrote:
| i don't care that much because i don't use it, and
| evidently not much of anybody else does either, or there
| would have been a popular fork. i'm just saying that this
| is probably not a good time to expect one to pop up
| aduffy wrote:
| Yes, the popular fork is called Postgres. You can find many
| vendors who will let you run it on one node cheaply. It's also
| free to self-host.
| Thaxll wrote:
| PG is nowhere close of What Cockroach does and probably never
| will.
| mardifoufs wrote:
| In what way is postgres similar to cockroachdb? Except for
| being a database. Going by that standard you might as well
| say that Access is an alternative to postgres. Which it
| technically is but...
| notpushkin wrote:
| Cockroach marketed themselves as largely Postgres-
| compatible, so I guess there's that.
| mardifoufs wrote:
| I guess that's true, I didn't think about that. But i
| think that you'd probably not be using cockroachdb if you
| were fine with what postgres offers. Cockroach might be
| compatible, but it really isn't "comparable" in terms of
| use cases and deployment imo. I might be totally wrong
| though, I have not been following it and Postgres closely
| since some time around 2021?
| zellyn wrote:
| It's useful to use a Postgres-compatible syntax. The
| point of Cockroach was always to compete with globe-
| spanning DBs like Spanner, not with (possibly) sharded
| PG.
| geenat wrote:
| Citus gets close for many usecases but the HA story sucks:
| https://github.com/citusdata/citus/issues/7602
| candiddevmike wrote:
| CockroachDB was already under the BSL. It's interesting that
| they're further restricting it... Perhaps the BSL isn't the
| panacea folks are making it out to be.
| PaywallBuster wrote:
| at least should still cover a lot of businesses under the free
| tier
|
| > Individuals and businesses, under $10M in annual revenue, can
| use CockroachDB Enterprise for free
| mrweasel wrote:
| You just can't build anything new based on CockroachDB now,
| because the pricing for self-hosted is "Contact us". So if you
| build a product you'd need to contact them first and kinda
| guess how successful you'll be. Maybe it's fine and the license
| cost isn't a big deal, or it will completely ruin your business
| case.
|
| Plenty of us have had to deal with this scenarios before with
| Oracle. Cheap or free to get started, then your product takes
| off and Oracle shows up and starts to demand their cut. I'm not
| suggesting that Cockroach is the new Oracle, but this type of
| licensing introduces a significant uncertainty into your future
| plans.
| tschellenbach wrote:
| We will probably end up removing CockroachDB from our infra due
| to this change. It also makes me a bit worried about their long
| term viability. How much ARR does CockroachDB have and what was
| their last round valuation...?
| Cwizard wrote:
| What will you switch to? I feel like there isn't a good
| alternative.
| shadow28 wrote:
| YugabyteDB is a commonly used alternative.
| jen20 wrote:
| According to Wikipedia, Yugabyte (the company) has taken
| 290 million dollars of VC money. It's probably a safe
| assumption that they will follow the same path soon enough.
| spiffytech wrote:
| While the future is unwritten, FWIW in 2019 Yugabyte
| moved _to_ Apache 2.0, open-sourcing features that were
| previously paywalled.
|
| They wrote up their rationale here:
| https://www.yugabyte.com/blog/why-we-changed-yugabyte-db-
| lic...
| riku_iki wrote:
| This won't prevent them back to paywall in future if
| investors ask.
| largbae wrote:
| True, but unlike BSL you can fork the last Apache commit
| the day they do.
| redwood wrote:
| How's their business growing compared to Cockroach?
| remram wrote:
| Also has a CLA: https://cla-assistant.io/yugabyte/yugabyte-
| db
| traderj0e wrote:
| Application-level sharding?
| tschellenbach wrote:
| CockroachDB is easier to manage and more cost effective than
| Postgress due to that. But now I suspect the balance tips back
| to Postgres
| geenat wrote:
| Citus would be great if the HA story was better:
| https://github.com/citusdata/citus/issues/7602
| indoordin0saur wrote:
| What issue do you have with the changes? Sounds like it's
| mostly focused on making it more affordable for small
| operations.
| mrweasel wrote:
| Not me, but two issues I could see: Revenue over $10 million,
| but not profitable, or the license cost would be to high. We
| had that issue with support contracts Elastic tried selling
| us, way back, compared to our revenue and profit, the
| license/support contract made zero sense.
|
| Other issue: Telemetry is mandatory on the free tier and cost
| to avoid it is to high. Some industries cannot have telemetry
| enable, or at least not without a heavy amount of reviews,
| think finance or healthcare.
| purpleblue wrote:
| Were you paying for it?
| sho wrote:
| Probably a good move. I'd looked at Cockroach before for a
| project - they basically disqualified themselves from the start
| by nerfing the "core" version so bad it was useless, while
| Enterprise was some absolutely insane figure for a cash-strapped
| startup. While it was possible to hotfix the code to get around
| their restrictions - we eventually just used something else.
|
| This at least gets the full-fledged product in the door at
| startups. Say what you want about the timing or the BSL but I
| think this makes sense business-wise.
| Cwizard wrote:
| What did you use instead?
| sho wrote:
| It was a data domiciling project so just went with sharding
| in good old postgres. Cockroach would have been perfect but
| it was going to cost something like $5k/m just to turn it
| on..
| geenat wrote:
| The enterprise per core is still an insane figure, based on
| last time I interacted with sales- would be amazing if this was
| revised, too, to be more competitive with Planetscale, etc.
|
| Would be far easier to recommend CockroachDB if it were more
| competitive with Planetscale.
| dathinab wrote:
| through cash strapped startups can now use the "free"
| enterprise version until they reach 10M$ annual revenue
|
| weather it's a good idea to commit to it if you might not
| want to afford it once your revenue went up is another matter
|
| and 10M$ annually is not little but also no absurdly huge, I
| mean a ~80 person company probably will struggle to be
| profitable with that revenue (if it's 80 good paying jobs
| like software developer).
| brianwawok wrote:
| For a US startup I would divide annual revenue by aprox
| 200k for reasonable bootstrapped employee max size. So
| maybe 50 max? This is assuming standard software startup
| with most cost being employees.
| dathinab wrote:
| It's not that much different in the EU. Through due to
| higher sales/revenue tax etc. a bit less employees. Also
| the additional cost above neto salary for epmploying
| someone is higher, but AFIK (especially as a startup) you
| can get away with a paying a bit less. Through in general
| it's less viable to scam your employees by doing stuff
| like goading them with non voting shares and then
| diluting them massively before selling. Like it's still
| possible but with much more limits. So this is comparison
| is limited to ethical company operation.
| vvern wrote:
| Last time I checked, the cockroach serverless pricing model
| and free tier were cheaper than planet scale for small
| projects. IIRC, the dedicated cloud product was also cheaper
| if you kept it utilized. What's your evidence that
| planetscale is cheaper?
|
| For example, planetscale charges 3x as much per gb of storage
| if I read the pricing correctly.
| samlambert wrote:
| we charge per node and you get 3 nodes by default so it's
| not 3x it's just that you have more nodes.
| vvern wrote:
| Cockroach is also doing 3x replication of the data, so I
| don't think that's particularly relevant here. Cockroach
| serverless will dynamically scale up sql serving
| processes based on load. The storage and compute are
| separated in the cockroach architecture. My point is that
| if your query load is relatively low, cockroach
| serverless is definitely cheaper because the storage
| costs dominate. I think there's ambiguity on which
| product is cheaper for a real-world application with
| meaningful load and data size.
|
| I remain curious about the perception that cockroach is a
| meaningfully more expensive product. Where does that idea
| come from?
| skunkworker wrote:
| The last time I priced out CockroachDB it was more than 10x
| what multi region SpannerDB would cost.
| LaserToy wrote:
| That is very interesting. As CRDB user, I priced Spanner
| (had to do some estimates during load testing), and Spanner
| came 3 times more expensive includign our eng salary to run
| CRDB
| infogulch wrote:
| Oh the joys of "Contact Sales" pricing strategy, where
| made up rates are no more consistent than "whatever the
| sales rep thinks they can extract from the business".
| skunkworker wrote:
| From what I remember, the cost per server per year was
| about 5x to 6x (annually) the hardware cost of a new
| server, and these were dual 32 core EPYCs. 64 cores per
| box at per core licensing gets really expensive.
| geenat wrote:
| Re: CockroachDB vs Planetscale. It's all about the price per
| core of the CockroachDB license.
|
| In my understanding, last time I talked to sales it's
| approximately 3x worse (because Planetscale offers 1 primary
| + 2 replicas) with CockroachDB you'd have to triple the
| CockroachDB license fees to even be competitive to achieve
| the same HA .... on hardware you purchase and run yourself.
| Aeolun wrote:
| It's interesting to hear that CockroachDB is so much more
| expensive than Planetscale, since I thought planetscale was
| already prohibitively expensive.
| AntonCTO wrote:
| > they basically disqualified themselves from the start by
| nerfing the "core" version so bad it was useless
|
| Ran the core version for around 3 years in production for a
| smart city project. The company I worked for has been running
| it for around 6 years. Not sure what you are talking about. Of
| course, we would love to use features like stale replicas for
| exports. But this isn't something we absolutely need.
| Icathian wrote:
| So the obvious question is, which big shops were using the Core
| version that ended up prompting this change? I know of one or two
| but I'm curious if there are some obvious big fish.
| turtle_heck wrote:
| Weren't Oxide using CockroachDB?
| nindalf wrote:
| Seems like. There are 5.2k hits in their codebase for
| "cockroach" (https://github.com/search?q=owner%3Aoxidecompute
| r+cockroach&...)
| ccmcarey wrote:
| Looks like those hits are because they forked it
| https://github.com/oxidecomputer/cockroach (no changes
| since then though)
| wave-trample-0h wrote:
| Doesn't this only affect companies with more than $10M in
| revenue? This change should only affect companies that are a
| going concern and are apt to remain in business.
| bcantrill wrote:
| Yes, we are -- and it's worked well for us! (The most acute
| issue we hit was actually a gnarly OS issue[0][1].) That
| said, we are not currently a Cockroach Labs customer and we
| will not be becoming one for purposes of licensing
| CockroachDB. We are abiding by the terms of the BSL, and the
| version that we are on (22.1) will be Apache licensed in May
| 2025; by that point, we will maintain our own Apache-licensed
| fork for purposes of being the database for the control plane
| included in the Oxide rack.
|
| We will be outlining our current direction in an RFD[2] that
| we will make public -- and we will also make public our RFDs
| that pertain to our selection of CockroachDB and the other
| alternatives that we evaluated; stay tuned!
|
| [0] https://www.illumos.org/issues/15254
|
| [1] https://oxide-and-
| friends.transistor.fm/episodes/a-debugging...
|
| [2] https://rfd.shared.oxide.computer/rfd/0001
| redwood wrote:
| Outside Olobserver here... isn't it a huge distraction from
| your core mission to be maintaining a fork of a database
| engine? Why not just use something like MongoDB Community
| if you're trying to avoid paying for database and need a
| horizontally scalable distributed transactional system?
| bcantrill wrote:
| No -- but I will leave it to the RFD that I'm currently
| writing (and to the others that we will make public) to
| explain the rationale.
| redwood wrote:
| Look forward to reading it
| bcantrill wrote:
| As promised, I have made RFD 508 ("Whither
| CockroachDB?")[0] public -- along with RFD 53[1] and RFD
| 110[2], which explain the problem we are trying to solve
| and our rationale for CockroachDB, respectively.
|
| [0] https://rfd.shared.oxide.computer/rfd/0508
|
| [1] https://rfd.shared.oxide.computer/rfd/0053
|
| [2] https://rfd.shared.oxide.computer/rfd/0110
| redwood wrote:
| Thanks: I think there's a category you're missing, which
| is transactional document oriented databases with
| strongly consistent secondary indexes.
| PeterCorless wrote:
| MongoDB is not a drop-in replacement for a CockroachDB.
|
| It's not SQL.
|
| While MongoDB has come a long way in terms of ACID
| compliance, etc., you still would need to map everything
| you've done to MongoDB.
|
| That's more work than forking code you're familiar with
| that already is working.
| redwood wrote:
| That makes sense it's more that from first principles
| when exploring the options it looked like and I see below
| based on the public page, it wasn't even contemplated..
| instead various key value stores without
| transactionality, and with eventual consistency and
| limited secondary indexing capabilities were looked at
| that are not widely used.
|
| I guess my deeper point is there's sort of the illusion
| of a comprehensive analysis in the post when actually
| engines that haven't been widely used in 5-10 years were
| analyzed when more widely deployed engines weren't even
| analyzd that's what was odd
| PeterCorless wrote:
| RFD 53 addressed why they avoided NoSQL in general:
|
| "NoSQL systems (e.g., Cassandra, Riak). The challenges of
| building relational, transactional applications atop
| these systems is well known. These systems also generally
| predate the modern emphasis on hands-off operation, which
| is critical for supporting a system that we will not be
| operating directly."
|
| https://rfd.shared.oxide.computer/rfd/0053#rfd48
| redwood wrote:
| My point is to conflate the entire non-relational
| category into this bucket when one of the two items
| referenced peaked >10 years ago and the other isn't
| generally strongly consistent at write time,
| transactional, or with strongly consistent secondary
| indexes, is a limited and misleading POV https://db-
| engines.com/en/ranking
| franckpachot wrote:
| YugabyteDB is and will always be Apache2. It is PostgreSQL
| compatible (the query layer is a fork of PostgreSQL) so the
| migration from CockroachDB, which implements a subset of
| PostgreSQL features, is easy.
| Spivak wrote:
| And like clockwork too.
|
| 1. Company builds cool OSS and releases it to the world.
|
| 2. The product becomes stable, mature, and users are happy
| with its feature set. Development slows down.
|
| 3. Company starts having to make money so they relicense
| future code.
|
| 4. A few large users of the software (that company was
| hoping for $$$ from) realize that since it's mature and
| stable it's massively lower cost to just maintain the last
| OSS version.
|
| 5. At the time of the license chance the new OSS fork is
| identical to what everyone is already using and so it's the
| the least resistance migration.
|
| 6. The consortium of actual users of the software drive its
| future direction instead of the company.
|
| I'm not mad about the cycle, it's the moment VC backed
| software gets turned over to the community. But I always
| wonder how it turns out for the companies in the long run.
| ko_pivot wrote:
| As much as this has the vibes of a classic OSS rug pull, as a
| Cockroach user, I don't really take it that way. First of all, it
| was already not open source and secondly, the free to use version
| was missing key features like follower reads and incremental
| backups.
| api wrote:
| Someone creating free software and changing the license on
| software they created isn't a "rug pull" in any sense of the
| word. You paid $0 and contributed nothing. What rug is being
| pulled?
|
| A rug pull is when you buy into something and then it's taken
| away, like when a cryptocurrency token is busted out or you
| spend money on something and then it's cancelled or nerfed.
|
| Don't like it? Write your own distributed fault tolerant
| database, or contribute an extension for Raft replication to
| the Postgres open source code base.
| warvariuc wrote:
| > You paid $0 and contributed nothing
|
| I think investing into integrating a tool into your
| infrastructure is not exactly "paying $0".
| ted_dunning wrote:
| From the standpoint of the people paying the developers of
| said software, it is _exactly_ like paying $0.
| tsimionescu wrote:
| No, it's not. If they're planning a rug pull, they very
| much care that you took effort to integrate their free
| offering into your infrastructure, because they care that
| you're sitting firmly on the rug before they can pull it.
| d_watt wrote:
| I see the issue with these more as if you are paying for it,
| one of the decision factors to buy it might have been that
| you have the opportunity to go to an open source version if
| the relationship gets bad.
|
| Sole source vendors are really risky, so open source gives a
| little control back to the buyer that the vendor won't lock
| them in then screw them later (oracle).
|
| So now if you're paying for Cockroach, you're effectively on
| proprietary technology with no negotiating levers.
| ensignavenger wrote:
| It is described as a rugpull because of the marketing around
| it being open source. Coackroach however was never open
| source, it was BSL licensed. This change does appear to mean
| that old versions will no longer eventually convert to open
| source, though.
|
| Thus it would be up to the the BSL promoters and marketers to
| decide whether or not this is a rugpull. As an open source
| user and proponent, I don't really care.
| eatonphil wrote:
| > Coackroach however was never open source, it was BSL
| licensed.
|
| It used to be Apache2. :)
|
| Their blog post announcing this in 2019 happens to now 404:
|
| https://www.cockroachlabs.com/blog/oss-relicensing-
| cockroach...
|
| But see also:
| https://news.ycombinator.com/item?id=40058332.
| ensignavenger wrote:
| My bad, I was wrong then. They even still falsely claim
| on github that it is open source, too (thanks to another
| commenter for pointing that out.).
| ezekg wrote:
| Archive: https://web.archive.org/web/20190604173131/https
| ://www.cockr...
| wging wrote:
| Really does appear to be memory-holed, rather than just
| having moved. Not a good look. https://www.google.com/sea
| rch?q=site%3Acockroachlabs.com+"Co...."
| john-flu-fix wrote:
| Cockroach hasn't marketed itself as open source for years
| warvariuc wrote:
| > CockroachDB - the open source, cloud-native distributed
| SQL database.
|
| https://github.com/cockroachdb/cockroach
| ezekg wrote:
| They seem to have fixed it.
| theamk wrote:
| CockroachDB raised >$500M in funding, and a big reason for
| this was it's high number of users. That high number would be
| a lot lower if it wasn't a free software.
| port19 wrote:
| The rug where my contributions sit on. That rug.
|
| And as you're surely aware, competent OSS contribution is
| worth thousands
| scblock wrote:
| Dancing around the "so it's not open source" by not clearly
| saying "correct, it's no longer open source".
|
| "CockroachDB will remain source available under a new license"
| sounds correct but it's still sidestepping the question. And "the
| source code will still be available for viewing and
| contributions" is completely shit. Why would anyone contribute to
| a commercial product unless they're getting paid to do so.
|
| Also, the use of this kind of "evolving our" and "advancing our"
| phrasing is so incredibly gross. No one speaks like this except
| in corporate announcements.
| dymk wrote:
| > Why would anyone contribute to a commercial product unless
| they're getting paid to do so.
|
| Because they get to use it for free?
| dastbe wrote:
| > Why would anyone contribute to a commercial product unless
| they're getting paid to do so.
|
| Because they'd be getting paid to do it for their company? I
| know of a few customers who, if they could, would have their
| employees contribute minor features to AWS services to solve
| issues.
| ezekg wrote:
| > Dancing around the "so it's not open source" by not clearly
| saying "correct, it's no longer open source".
|
| CockroachDB hasn't been open source for over 5 years:
| https://web.archive.org/web/20190604173131/https://www.cockr...
| scblock wrote:
| Yet it's one of the top questions on their announcement page
| and they won't clearly answer it.
| ezekg wrote:
| Likely because most people think "source available on
| GitHub" = "open source", so they're just answering the low-
| hanging-fruit even if the question is technically
| incorrect. They don't claim to be open source anywhere, and
| I haven't seen them claiming to be open source since they
| relicensed to the BUSL over 5 years ago. I don't think
| there's malice here.
| ted_dunning wrote:
| > Why would anyone contribute to a commercial product unless
| they're getting paid to do so.
|
| Because they need a bug fix in the code as soon as possible
| without waiting for the vendor's priorities to match their own?
| AYBABTME wrote:
| I understand the goal, and the perceived abuse of the Core
| edition. But the problem with the Enterprise edition is that it's
| quite expensive, "contact us" salesy, and it feels like taking a
| bite of this edition is possibly getting into bed with a future
| Oracle/landlord type of relationship where you end up squeezed by
| your database vendor.
|
| The Core offering made this palatable, one could fallback to Core
| features if the relationship with Cockroach Labs degraded, which
| made it possible to entertain the Enterprise license since
| there's was a way to walk back from it. But now there's no such
| mitigation available. By using non-PG native features, users of
| the Enterprise edition are accepting to get in bed with Cockroach
| Labs for effectively forever (databases), a single provider that
| has no competition.
|
| I think this may backfire, as it now seems imprudent to go all in
| on Cockroach Labs. They may be nice folks today, but who knows
| who will run the place in 5y when the next round of squeeze
| comes?
|
| I wish them the best, they're a great team and I always liked the
| project and toyed with it for years, and currently am involved
| with a paid Enterprise license. But this change in the dynamics
| is really giving me pause.
|
| Getting in bed with a single vendor for an incredibly sticky tool
| comes with a _lot_ of risk. It took at least 17y for Amazon to
| get rid of its last Oracle database:
| https://aws.amazon.com/blogs/aws/migration-complete-amazons-...
| ROFISH wrote:
| Agreed. I talked with them in the past and the pricing was far
| too expensive to make it worth it.
|
| As always: "If you have to ask, you can't afford it."
| candiddevmike wrote:
| There is no abuse here. They released software under a specific
| license (BSL at that, plenty of opportunities to restrict).
| AYBABTME wrote:
| It can be construed as "abuse" if another commercial entity
| is deriving value from the core license while Cockroach Labs
| doesn't get to enjoy a "fair" share of this created value,
| while pouring its own resources into a product that enables
| this value creation.
|
| I think CR Labs needs to make money from their activities.
| However they do it, should be in a way that incentivizes a
| win-win for them and their customers. Right now I think they
| attempted to "correct" for the uncaptured value, but the game
| theory switched toward discouraging adoption (in my
| perspective). I may be wrong, probably am.
| andrewmutz wrote:
| It seems that whenever an open source project is run by a VC-
| backed company, it sooner or later ends up like this.
| Increasingly it seems that "open source" is just the teaser to
| get people interested and then when investors want revenue
| growth, the rug gets pulled.
|
| IMO, it's not really open source if its run by a company that
| will eventually use its position to squeeze its users for cash.
| candiddevmike wrote:
| Like other folks have said, anytime you see a CLA, you see
| the true intentions of the project. A project that will
| always be FOSS won't have a need for a CLA.
| _benedict wrote:
| The ASF requires a CLA for all regular contributors or
| large contributions, so I don't think this is a
| particularly good barometer.
| remram wrote:
| That's a good point. The ASF's FAQ [1] states that "All
| software developed by all projects of The Apache Software
| Foundation is freely available without charge" and that
| it "is specified in the Foundation's Articles of
| Incorporation [2]", however I see no such specification
| in the linked incorporation. Is there some actual legal
| guarantee there?
|
| [1]: https://www.apache.org/foundation/license-
| faq.html#IsItFree
|
| [2]: https://www.apache.org/foundation/records/incorporat
| or.html
| fweimer wrote:
| I think it's mentioned in this document: https://www.apac
| he.org/foundation/records/certificate.html
| remram wrote:
| Thanks!
|
| It seems a little short of the claim in their FAQ though,
| but it's something:
|
| > The purpose of the Corporation is to engage in any
| lawful act or activity [...] including the creation and
| maintenance of "open source" software distributed by the
| Corporation to the public at no charge
| ted_dunning wrote:
| I don't think that falls short.
|
| The reason for the "any lawful act" language is to allow
| the ASF to do things like run a conference, accept
| donations, sell t-shirts and other activities. If the
| statement was only "develop open-source software" there
| are all kinds of important activities that support open
| source development that would be impossible.
|
| The fact is, however, that certificates can be changed by
| the people who can vote. IN the case of the ASF, the
| members are the ones who vote. Getting those ~800 members
| to radically trash the traditional goal of the foundation
| is not going to be possible as long as the current
| membership is active.
| remram wrote:
| What I mean is that, if they made some software non-free
| alongside some free ones (to make money to finance the
| free ones, for example), that still seems valid as to the
| current certificate of incorporation.
|
| Their FAQ says "all software free no exception" and this
| document says something weaker.
| saurik wrote:
| The difference with the ASF/FSF is that they are non-
| profits with a mission statement (and, if we don't trust
| that enough--due to OpenAI, as I don't _entirely_
| understand what happened there--with clearly-mission-
| aligned board leadership) that prevent them from pulling
| the rug out from under their license. (...and, right as I
| pushed this comment, I see that someone else looked into
| it, and maybe the ASF fails to have such a clause
| anywhere ;P but hopefully it is there and just a bit
| hidden.)
| cortesoft wrote:
| Sure, but that contradicts the statement made in the
| comment they are replying to:
|
| > anytime you see a CLA, you see the true intentions of
| the project. A project that will always be FOSS won't
| have a need for a CLA.
|
| If there are conditions to the statement, it isn't
| "anytime you see a CLA".
| saurik wrote:
| Sure, but now we would need to find another epicycle for
| why giving a for-profit corporation this dangerous power
| over its licensees is safe/benign. There is, at times,
| some logic to "the exception that proves the rule".
| fweimer wrote:
| It depends on the CLA. In some countries, you cannot not
| have a CLA because there's always an implied contract.
|
| Many CLAs are just a hassle (basically, DCO that has to be
| reviewed by the legal department). But a lot are
| asymmetrical in a substantial way and the original
| developer gets to play by different rules than the rest.
| CLAs in the second category tend to be problematic.
|
| Even that is not a completely clear indicator because in
| some cases, the asymmetry is only intended to help with
| potential future relicensing in alignment with the
| project's goals, and not to enable commercialization
| (either today or at some point in the future). Some
| organizations have resisted direct commercialization of the
| code they have been entrusted with for decades, so that can
| happen even with an asymmetrical CLA.
| ziddoap wrote:
| For those of us not in-the-know about licensing acronyms.
|
| CLA = Contributor License Agreement
| kodablah wrote:
| This is not necessarily true. Sometimes it's needed to
| pivot to a better/different open source license without
| going through the pain of contacting every contributor
| ever. I have seen that pain in some projects that want to
| go from LGPL to MIT or something.
|
| For many contributors, they're ok giving full ownership of
| their contributions to a project owner on the owner's
| terms. Some contributors may not be ok with that of course,
| but it doesn't mean that every project owner has nefarious
| plans with said code ownership.
| drdaeman wrote:
| > better/different open source license
|
| And that's why "open source" is a really bad term that no
| one should use unironically, unless they want to confuse
| the hell out of people.
|
| There are protective (copyleft) licenses, and there are
| permissive licenses - and they're very different beasts.
| And it's, like, software licensing 101.
|
| > that want to go from LGPL to MIT or something
|
| I find this extremely weird.
|
| In a sane world, picking a copyleft license _must_ mean
| that you care about user freedoms and want to make sure
| they 're respected no matter what happens. Because that's
| the whole point of picking a copyleft license - not about
| letting people peek or tweak some code, not about social
| brownie points, and most certainly not about marketing
| campaigns - but about granting users their freedoms.
|
| Either people get confused about "open source" and
| pick... I don't know, whatever looks cool, without even
| understanding what they're doing; or they're giving up on
| their principles when they smell the money.
|
| I can understand wanting to go from, say, GPL to AGPL, or
| GPLv2 to GPLv3[+] - it would make sense, as it all goes
| in line of protecting freedoms. But LGPL to MIT is truly
| a weird one.
| riffraff wrote:
| (L)GPL to MIT is a choice many projects made when they
| decided they cared more about their code being used than
| about it staying free.
|
| Copyleft licenses were the default choice at some point
| in time, but then in the '10s most big projects seemed to
| pick a permissive license, and many switched.
| drdaeman wrote:
| Yea, and the point is that they really should not have
| picked LGPL in the first place. If you pick a copyleft
| license, please don't do it because it's cool - do it if
| and because you care for what it stands for.
|
| However, I thought about it and I think I can get the
| cases where monetary opportunities started to outweigh
| what's essentially are political ideals. Happens all the
| time, heh. I guess I can imagine person not being honest
| with themselves until the temptation really comes.
| Especially if it's about casual developers trying to have
| some money to live comfortably (as opposed to lowering
| their standards of living), rather than getting rich.
|
| I can only hope it's that and not a simple ignorance.
| kodablah wrote:
| > picking a copyleft license must mean that you care
| about user freedoms [...] they're giving up on their
| principles
|
| This is a personal bias and disregards others' definition
| of true do-whatever-you-want freedom. Different project
| owners may think differently on what free means and alter
| the license to respect their principles (and may consider
| copyleft to be the restrictive/anti-free mistake made
| early on based on these same kinds of personal biases).
|
| And many contributors don't really care what the project
| owner does with their code and the CLA lets them delegate
| responsibility.
| immibis wrote:
| It's been popular in the last decade and a half to think
| that freedom is when everyone, including massive
| corporations, can do anything they want with your
| software, including closing it and taking away everyone
| else's freedom. Don't people think it would be better if
| they couldn't do that?
|
| People who value attention over principles are known as
| "pick mes" apparently.
| chii wrote:
| > including closing it and taking away everyone else's
| freedom.
|
| unless the corp owns the rights, they cannot "close it",
| nor take away everyone else's freedom. The old version
| that was open source licensed is always going to be
| available.
|
| Unless you're talking about the additions these
| corporations made, which they keep closed, and charge you
| for it. But if they are able to charge for it, they
| deserve it.
| immibis wrote:
| Embrace, extend, extinguish - AGPL makes it harder and
| SSPL even harder still.
| sgarland wrote:
| > But if they are able to charge for it, they deserve it.
|
| This is an extremely black-and-white view. If I make a
| competing product to you and it's superior to yours, then
| yes, I deserve profits (though of course consumers may
| still choose yours for a litany of other reasons). If a
| trillion-dollar corporation becomes a competitor, that's
| not exactly fair. They can, if they want, spin up an
| entire team dedicated to the product, and by sheer
| numbers, they will win. Is it legal? Yes. Is it ethical?
| That's subjective.
| graemep wrote:
| That example is exactly why many people will not want to
| sign a CLA.
|
| Someone who is has a strong preference for copyleft
| licences may not want to contribute to a project with a
| permissive license.
|
| The intent may not be for the project owners to use the
| code in proprietary software, but it would be to allow
| someone to do so.
| kodablah wrote:
| Sure, and I think the CLA is a good signal to those that
| care about how their contribution is used to stay away.
| But for everyone else that's not concerned with that, the
| CLA is not inherently evil.
| shagie wrote:
| I wonder... if you do something with AGPL that requires
| releasing the changes back ... you don't need to sign a
| CLA to do that.
|
| _However_ that would also mean that the core project
| couldn 't accept your changes without the CLA since that
| would _also_ bind them to never switching the license or
| relicensing your contributions for an enterprise license.
|
| ... I think. My head hurts when trying to consider the
| implications for CLAs and AGPL and the endless debates
| that lawyers could have over this.
| orthecreedence wrote:
| I think that's a bit reductive. It's possible to have a CLA
| because you want to sell a non-GPL version of your app to
| some corporation that's worried about the legalities of the
| license. This is an additional revenue stream that open-
| source projects make use of, and it's not fair to say "any
| project with a CLA is selling out."
|
| There's this balance between being a project forever run
| out of someone's garage and actually growing into a larger
| and more used system. I'd say the line is dilineated by
| many factors: who is the project's primary user?
| Enterprise? Devs? How much money is changing hands? What's
| the business model? Is there investment involved? How
| restrictive is the primary license? How restrictive is the
| CLA?
|
| I think any open-source project that has aspirations to
| actually make money for the creators is shooting themselves
| in the foot without a CLA. And it's fine to judge them for
| this, but we live in a system where people have to extract
| value out of this shit even if it's against their ethos.
|
| If people truly and ultimately believe in open-source, then
| the most logical conclusion is that capitalism does not
| allow for open source and _that_ must be changed. Fighting
| things at the license level can only delay the inevitable.
| But people want to have their cake and eat it too: "I want
| the system to stay the same AND I want open-source creators
| to keep pumping out stuff for free forever."
| lacker wrote:
| This is not true. Many companies want a CLA because their
| lawyers are worried about unclear patent law. They don't
| want someone to contribute some code, and then later claim
| the contributed code violates their patents.
|
| Good examples are React from Facebook, and TypeScript from
| Microsoft. Both require a CLA. But these projects are never
| going to go closed-source. They are complements to the
| companies' core business strategies.
| yawboakye wrote:
| start open/source available has become a trend among yc-
| backed startups lately. one wonders how long before a "well,
| actually, we need a business-y license."
| brianwawok wrote:
| Lately? This was cool like 12 years ago. Then you turn
| commercial once you get enough users. It's the open source
| chameleon model.
| acedTrex wrote:
| Open source and profit go together like oil and water
| valyala wrote:
| Open source works great for for-profit companies. Take a
| look at RedHat.
| JohnDeHope wrote:
| Maybe we will have to replace "open source" with "spec
| driven". As you point out, open source can be just as bad as
| closed source, given future changes in direction by the
| project team. But "spec driven" means that anybody can come
| along and compete, and you can switch to them, regardless of
| how the original developers feel about it.
| graemep wrote:
| Is it not more about who does the development?
|
| If cone entity does the development, they can change
| direction or licensing and it is hard for anyone to fork.
|
| If you have more of a bazaar form of development with many
| contributors neither is as easy (even less so if you do not
| have a CLA). Even if you have a small core team of
| developers, a really bad direction is likely to lead to a
| split.
| evantbyrne wrote:
| I think you are right to think of it in terms of who is
| doing development. The plus of a non open-source license
| is well-funded development. The downside is fewer outside
| contributions. In this specific instance, I think
| Cockroach was BSL? So, it can be forked into a community
| project where new contributions are open-source. Another
| corporation just wouldn't be able to profiteer off the
| fork directly until the changeover date.
| haolez wrote:
| Old(?) school open source with GPL licenses doesn't seem to
| suffer from this, on a first glance. Maybe Stallman was
| right. Would love to hear from someone more knowledgeable on
| this. I'm not trying to troll.
| ghshephard wrote:
| GPL is actually a great license for this scenario. The
| software advances to a particular level of development,
| inertia, market penetration - then the company that _owns_
| the software dual licenses with GPLv3 - which no company
| can risk to have on their premise, distribute, or use
| /touch, etc... - ergo you then have to pay for a commercial
| license to avoid the GPLv3 taint.
| graemep wrote:
| Why can companies not use GPL3 software? I cannot see how
| its so different from GPL 2 for companies that are users.
|
| I can see it has some disadvantages for companies
| incorporating GPL software in their products, but none
| for companies merely using GPL 3 software.
| ghshephard wrote:
| I can't say for certain _why_ they can 't use GPLv3 -
| just that no company I've ever worked for (n=4 since
| GPLv3 came out) - will allow it on premise. It's probably
| why Apple stopped updating all their GNU binaries, and
| you have to sideload stuff with brew to use anything
| released in the last 10 years.
|
| If I had to guess - The patent rights clause weirds out a
| lot of lawyers. Obviously anyone who works with hardware
| doesn't like the anti-tivoization clause. Another
| possibility is the AGPL (which _IS_ lethal for obvious
| reasons) is often conflated with GPLv3.
|
| All I know is GPLv2 is fine, GPLv3 is usually not, and
| AGPL is never possible in corporations that I've worked
| for.
| graemep wrote:
| I can see it makes sense for Apple (anti-tivoization is
| something they do not want).
|
| > I can't say for certain why they can't use GPLv3 - just
| that no company I've ever worked for (n=4 since GPLv3
| came out) - will allow it on premise
|
| So they do not allow the use of things like Bash or GNU
| coreutils? That seems quite restrictive and difficult.
| swiftcoder wrote:
| They often use older version of things like Bash and
| Coreutils, or equivalents from other ecosystems (i.e.
| Apple ships the BSD versions thereof)
| graemep wrote:
| So, for example, if they use RHEL version 6 or later they
| will install it without the default shell?
|
| Apple is different as they produce their own OS. I am
| asking about non-software companies avoiding GPL3 which
| would be necessary for (as the comment I responded to
| earlier in the tread claims) the use of GPL3 providing a
| motive to pay for licenses for dual licensed software in
| a way GPL2 does not.
| trws wrote:
| A small refinement here, your statements are largely my
| experience dealing with people _linking against_ gpl3
| software because of the vitality and the patent
| exemptions. Most places _run_ gpl3 stuff just fine. The
| one organizations won't touch with a ten foot pole, even
| to run it, is AGPL.
| graemep wrote:
| > A small refinement here, your statements are largely my
| experience dealing with people linking against gpl3
| software because of the vitality and the patent
| exemptions
|
| In the context of the thread (the claim GPL 3 provides
| more of a motive for people to by paid licences for dual
| licensed software) I think that "small refinement" covers
| most of what we are talking about though.
| worik wrote:
| > won't touch with a ten foot pole, even to run it, is
| AGPL.
|
| I feel out of touch
|
| Why?>
| swiftcoder wrote:
| The AGPL has a significantly stronger viral clause than
| the plain GPL. You must offer the source code to anyone
| who connects to the AGPL-covered code via a network
| connection (i.e. must open source the entire server if it
| is using any AGPL code)
| orthoxerox wrote:
| Releasing the whole server sounds more like the Commons
| Clause or the SSPL. AGPL requires you only to provide the
| source code of your fork to its users.
| swiftcoder wrote:
| > AGPL requires you only to provide the source code of
| your fork to its users
|
| The AGPLv3 is exactly the same as the GPLv3, except with
| the _added_ clause that connecting to a server counts as
| distribution for the purposes of triggering the right to
| obtain source code.
|
| That means all the usual GPL copyleft rules apply: if you
| include an AGPL library in your server binary, the entire
| binary becomes subject to the AGPL. And being subject to
| the AGPL, you are obligated to provide access to the
| source code for your entire server binary to anyone who
| connects to and interacts with your service across a
| network.
|
| Quoting from https://www.fsf.org/bulletin/2021/fall/the-
| fundamentals-of-t... :
|
| > Simply put, the AGPLv3 is effectively the GPLv3, but
| with an additional licensing term that ensures that users
| who interact over a network with modified versions of the
| program can receive the source code for that program...
|
| > These terms cover the distribution of verbatim or
| modified source code as well as compiled executable
| binaries. However, they only apply when a program is
| distributed, or more specifically, conveyed to a
| recipient...
|
| > The AGPLv3 does not adjust or expand the definition of
| conveying. Instead, it includes an additional right that
| if the program is expressly designed to accept user
| requests and send responses over a network, the user is
| entitled to receive the source code of the version being
| used.
| orthoxerox wrote:
| Yes, but are there any AGPL-licensed libraries? I've only
| seen runnable binaries licensed under AGPL. I can
| theoretically imagine one, "if you want to build a server
| application using my binary, I don't want you hiding my
| source code from your users", but even GPL-licensed
| libraries are rare, LGPL is more common.
| frant-hartm wrote:
| I remember that Neo4j Enterprise used to be available
| under AGPL. They pulled it and now it's available only
| under a commercial license.
|
| AGPL is not a problem for server-side software if you
| don't need to modify it. Your application (talking to the
| server) doesn't become infected by AGPL.
| coldpie wrote:
| > I can't say for certain why they can't use GPLv3 - just
| that no company I've ever worked for (n=4 since GPLv3
| came out) - will allow it on premise
|
| My limited experience with IP lawyers at big software
| companies is that they have zero understanding of
| software licensing and patent law. They just seem to
| parrot some line they learned in college 10 years ago,
| even when the plain text of the license or law sitting in
| front of them proves them wrong. It's honestly baffling
| how they get these jobs.
| PeterCorless wrote:
| I used to work for a company that used AGPL. For
| databases, in particular, it's not as noxious as people
| make it seem, other than if you are a hyperscalar trying
| to commercialize someone else's hard work and run them
| out of business, or a bottom feeding hosted service
| company also trying to commercialize someone else's hard
| work and coattail on their success.
|
| Otherwise it works great for end-user adoption.
| omoikane wrote:
| Old school open source projects don't seem particularly
| profitable. The projects themselves might thrive, but that
| seem to rely on altruistic developers with other sources of
| income.
|
| Richard Stallman himself doesn't seem to make money from
| any software he made directly, but from various grants and
| such, for example:
|
| https://web.archive.org/web/20220123032418/http://tech.mit.
| e...
|
| I thought he was on the payroll for FSF, but his reportable
| compensation has been zero from 2002 to 2022 according to:
|
| https://www.fsf.org/about/financial
| wussboy wrote:
| > Old school open source projects don't seem particularly
| profitable.
|
| And is also subject to survivorship bias. For every OSS
| project that makes it, tens of thousands do not.
| bigiain wrote:
| You're kinda saying the same thing there.
|
| As a developer, I don't want to rely on code from a
| project that "seems particularly profitable", because one
| day it's 100% certain they're going to start making their
| profit off me.
|
| I'm _extremely_ wary of any "open source" projects
| that're VC funded, because the entire VC industry exists
| to make rich people richer at everybody else's expense,
| throwing a few bones at a few of the founders and a
| vanishingly small portion of the startup employees. As
| soon as they think that can get away with it because they
| have enough "free" open source users locked, they're
| gonna turn all the screws to chase the "100x or bust"
| exit strategy the VCs rely on. At the expense of
| everybody who foolishly built something on to of that
| project without an easy way to replace it.
| omoikane wrote:
| I am saying that old school projects aren't paying the
| developers' bills because they aren't profitable. The
| developers realize this too, there is only so much
| altruism to go around but you got mouths to feed and
| rents to pay.
|
| As an alternative to working on a second job to fund
| their passion, we are seeing developers trying various
| things to make their one passion job pay, such as
| licensing tweaks or VC funding. These don't seem to work
| out very well, I think it's best explained here:
|
| https://apenwarr.ca/log/20211229 "So it
| is with free software. You literally cannot pay for it.
| If you do, it becomes something else."
| haolez wrote:
| You are correct, but there is also an interesting
| phenomenon going on here: old school open source projects
| last longer. They end up being more reliable in the long
| term. It's kind of weird that the unprofitable option is
| the stable one.
| immibis wrote:
| It's almost like capitalism is a destructive force and a
| poor way to organise a society.
| graemep wrote:
| Capitalism works fine under certain conditions: free
| markets, which implies competition.
|
| The problem is that these conditions do not always
| prevail.
|
| I used to think this was fixable:
| https://pietersz.co.uk/2009/11/fix-capitalism
|
| I now think it is more complex and we need a mixed
| economy.
| ath3nd wrote:
| > Capitalism works fine under certain conditions: free
| markets, which implies competition. The problem is that
| these conditions do not always prevail.
|
| Eventually, on the free market there are winners, and
| these winners form a monopoly. See Nestle, Tyson foods,
| Apple. The big corps, having cornered the market, then
| squeeze the hapless users (and the ecosystem, in Apple's
| case) into exorbitant prices, because there is no
| competition. You started with your beloved "free market",
| ended up with a monstrous monopoly. Surprise, this is how
| any "free market" story ends.
|
| If you want to avoid the trash situations that we are in
| today, you need to regulate the shit out of companies
| with antitrust, breaking them down when they become too
| big, not allowing them to acquire others under certain
| conditions and forcing them to treat their workers and
| customers well. This is the opposite of "free markets",
| and is the only way if you want a stable society.
| chii wrote:
| > They end up being more reliable in the long term.
|
| you're just seeing survivorship bias.
|
| Plenty of them would've also disappeared, because their
| core contributor no longer wanted to give out free labour
| and moved on.
| FireBeyond wrote:
| > I thought he was on the payroll for FSF, but his
| reportable compensation has been zero from 2002 to 2022
| according to:
|
| He resigned in 2019 following allegations of
| inappropriate behavior towards women
| (https://news.ycombinator.com/item?id=20990583).
| lucianbr wrote:
| Maybe? Every day it seems clearer that Stallman is right.
| Mouse subscription? Windows displaying ads in start menu
| and recording everything you do? How many devices have
| become useless when the servers shot down, or games became
| unplayable? How many times books or songs or movies have
| disappeared from "online collections" after being paid for?
| "The right to read" seems more and more realistic as time
| passes.
|
| In my opinion, Stallman has been proven right many times
| over.
| monero-xmr wrote:
| Well what do you expect to maintain the mouse's cloud
| servers, if not subscription revenue? The greed here!
| chii wrote:
| if the server was integral to the running of the service
| then yes, it makes sense to discontinue it when there's
| no more profit to be made.
|
| However, increasingly more and more services which
| could've been an on-premises deployment become SAAS. This
| includes games (live services they call it). It is
| _designed_ to end, and designed to not be able to run
| locally.
|
| Tell me who's the greedy one.
| linker3000 wrote:
| 1. Create a mouse that needs Cloud services.
|
| 2. Need revenue to pay for the Cloud services.
|
| 3, Charge mouse users for the Cloud services.
|
| It's the (stupid) circle of life.
| spion wrote:
| Was he though? If we didn't have GPL perhaps at least our
| software and data would've still been on our computers
| instead of a privately owned cloud...
| eikenberry wrote:
| FSF requires signing of a CLA. A CLA would let them change
| the license to whatever they want, just like these
| companies. Some people were not happy with GPL3 yet that
| didn't stop the FSF from changing the licenses on their
| software.
| teddyh wrote:
| The FSF does not require a CLA.
| eikenberry wrote:
| If they don't that is something new. Do you know when
| that started (or rather, stopped)?
| SoftTalker wrote:
| What is the GPL-licensed product that is comparable in
| functionality and scalability to CockroachDB? If there is
| one, you're free to use it.
| tsimionescu wrote:
| MongoDB switched from AGPL to their own license when they
| couldn't compete with others offering their software as
| SaaS, so I don't think the GPL is any kind of protection
| from this. It's just that the GPL is less popular than
| alternatives for this type of business model.
| haolez wrote:
| That's a very good counter example. Although, I'd
| imagine, the latest AGPL version will be useful for a
| long time and any further progress in the code base would
| also be under AGPL, which would not be under risk of
| becoming an open core project.
| pjmlp wrote:
| Which is exactly why we are back into Public
| Domain/Shareware kind of models, and GPL is an endangered
| license model, only some old school projects keep it
| around.
|
| It will be even worse after the GPL developer generation is
| gone.
| karmakaze wrote:
| Opensource is opensource: CockroachDB Core up until Nov 24,
| 2024 is, and not afterward. Anyone who wants to fork it can
| do so. Mind you this will be a hard fork as there's no way to
| keep in sync with their enterprise product.
|
| What you say is true in that you shouldn't view a VC backed
| opensource offering as 'permanently' opensource by the same
| group.
| geenat wrote:
| Kind of... Certain extensions such as basic backups are
| closed source and have never been in the OSS version.
|
| Many things would have to be re-added from scratch in a
| fork.
| karmakaze wrote:
| I'm having trouble parsing/making sense of this. Was
| basic backup in Core? If you were running anything more
| than Core you weren't running an OSS version and had
| already crossed that line before this announcement. If
| you were running an OSS version there's nothing to add,
| just fork, no?
| gerwim wrote:
| Core only has the "full backup". Incremental and other
| types are available to enterprise. I run the Core edition
| (with full backups) for my personal projects.
| geenat wrote:
| CockroachDB Core uses 3 licenses: CCL, BSL, Apache
|
| CCL, BSL = "source available"
|
| Apache = open source
|
| Parts of CockroachDB under CCL that do NOT transition to
| Apache OSS: https://github.com/cockroachdb/cockroach/tree
| /master/pkg/ccl > the sub-tree under
| pkg/ccl is under a different license (CCL) that does not
| transition to APL2 after a set duration.
|
| https://github.com/cockroachdb/cockroach/discussions/1271
| 40#...
| a-robinson wrote:
| "Basic" (i.e. full) backups have been included in the OSS
| version since its November 2020 release (20.2):
| https://www.cockroachlabs.com/blog/backup-restore/
|
| They are still pretty limited compared to what's in the
| enterprise version, but it's not right to say basic
| backups are closed source and have never been there.
| geenat wrote:
| CockroachDB Core uses 3 licenses: CCL, BSL, Apache
|
| CCL, BSL = "source available"
|
| Apache = open source
|
| Parts of CockroachDB under CCL that do NOT transition to
| Apache OSS: https://github.com/cockroachdb/cockroach/tree
| /master/pkg/ccl > the sub-tree under
| pkg/ccl is under a different license (CCL) that does not
| transition to APL2 after a set duration.
|
| https://github.com/cockroachdb/cockroach/discussions/1271
| 40#...
| jen20 wrote:
| CockroachDB Core has not been offered under an OSI (i.e.
| Open Source) license since 2019 - everything subsequently
| has either been under Business Source License or the
| Cockroach Community License.
| karmakaze wrote:
| I searched github and thought this[0] was it.
|
| > Source code in this repository is variously licensed
| under the Business Source License 1.1 (BSL), the
| CockroachDB Community License (CCL), the MIT license,
| BSD-style licenses, and other licenses specified in the
| source code. Source code in a given file is licensed
| under the BSL and the copyright belongs to The Cockroach
| Authors unless otherwise noted at the beginning of the
| file.
|
| Is the caveat in this part (that I didn't catch before)?
| "Source code in a given file is licensed under the BSL
| and ..." That is sucky.
|
| [0] https://github.com/cockroachdb/cockroach?tab=License-
| 1-ov-fi...
| nazka wrote:
| What happens the day where the only way to fork it
| realistically is to pay people. And I mean good people to
| even keep up? And what if on top of that the bests in the
| game are already in the corporations that you want to fork
| from?
| nsm wrote:
| Yep! I actually far prefer closed source software, made by
| non-VC funded companies, where there business is to create
| good software that actually adds value for the license I'm
| paying for. Something like Sublime Text or JetBrains.
|
| Sure <VC funded editor company> can have people spend years
| of their life working on something, but release it as open
| source because VCs are paying for it, and that leads to more
| mindshare, but it leaves a bad taste in my mouth. Similar
| reasons to not use VSCode (commoditizing the complement by
| using billions of dollars from other products).
|
| The "must be open source (I think they actually mean free as
| in $$) at all costs" crowd baffles me because the money to
| support the humans creating the software in the real world
| doesn't just magically appear.
| ElijahLynn wrote:
| I'm imagining that those closed source softwares wouldn't
| be possible without open source libraries and tools...
| pasc1878 wrote:
| I would imagine there is a lot on Windows possibly macOS.
|
| Many c/C++ libraries are not open source - even more .Net
| ones
| sauercrowd wrote:
| Open source as a byproduct of a company absolutely works
| - it's been proven by tons of tech companies.
|
| But if you open source your revenue-generating parts, and
| only charge for support/managed version/enterprisey
| features you'll end up with quite weird incentives,
| particularly with infrastructure tools, in which the big
| cloud providers will happily compete with you, using the
| version you open sourced and providing and ecosystem to
| their customers that one simply cannot compete with
| swiftcoder wrote:
| In the sense that most modern programming languages and
| compilers are open-source, sure, nothing outside the
| embedded world can truly be built without relying on open
| source.
|
| There are still native shops that rely on very little
| open source, though at this point probably only in niches
| like gamedev or defence.
| sgarland wrote:
| Correct. This is what makes me feel guilty about
| releasing a closed-source product, or even one with a
| non-OSI license. It's irrational, but I feel like I've
| benefited so massively from FOSS that I owe it to the
| community to contribute back.
|
| EDIT: as another commenter wrote below, OSI is driven by
| massive cloud vendors, who have a vested interest in
| having their freedoms to take projects and monetize them.
| Perhaps a somewhat restrictive license isn't a bad thing.
| jaaron wrote:
| > IMO, it's not really open source if its run by a company
| that will eventually use its position to squeeze its users
| for cash.
|
| I know it's not as popular or sexy as it used to be, but the
| whole point of a foundation like Apache was to avoid these
| situations, even more than the way the Linux Foundation is
| setup. Apache _explicitly_ manages projects to avoid these
| downsides.
|
| - Single corporation ownership. Projects cannot get out of
| the Incubator unless they demonstrate a diverse and healthy
| community. That doesn't mean popular, it doesn't necessarily
| mean best-in-class, but it means that there shouldn't be just
| one entity backing a project.
|
| - Membership in Apache is _personal_ not a seat for a given
| company. If you're a committer on an Apache project and you
| move jobs, you're _still_ a committer on that project
|
| - The Foundation owns the trademarks. There have been fights
| about this in the past, but the whole idea is that the
| _community_ owns the name, so some corporation can't claim to
| be the sole or official owner by naming their company or
| product after the open source product.
|
| The core premise of the Apache Software Foundation is
| community over code, that healthy, diverse communities have a
| better chance of standing the test of time than open source
| projects backed by a single individual or company. That's the
| thesis at least.
|
| The is starkly different from several other foundations,
| notably the Linux Foundation or Eclipse Foundation which are
| modeled more around industry consortiums.
|
| Both models have their place, but I believe Apache better
| models the core values many of us feel strongly about when it
| comes to free and open source software.
| timcobb wrote:
| What is more popular than the Apache Foundation? I thought
| Apache was top... Is there a cooler/better Apache? If so,
| please let me know.
|
| And when was Apache more popular? I thought it was the
| uncool place where stuff was written in Java, that became
| popular because people's conception of Java (and the
| language/ecosystem itself) changed.
| mcpherrinm wrote:
| I think CNCF is home to most of the big projects I've
| been contributing to or using lately.
| mikeyouse wrote:
| CNCF is a project of the Linux Foundation - which has
| become absolutely massive:
| https://www.linuxfoundation.org/projects
| Someone wrote:
| Apache is both popular and "the place where projects go
| to die". They have many, many projects that see limited
| development activity and aren't well-known (how many
| projects in
| https://projects.apache.org/projects.html?name do you
| even vaguely know of what they're about?)
|
| I also think the popularity of the Apache license is part
| of what makes Apache popular.
|
| > I thought it was the uncool place where stuff was
| written in Java
|
| They have lots of projects running on the JVM, but
| "written in Java" isn't a requirement, nor is "running on
| the JVM". See
| https://projects.apache.org/projects.html?language
| cmrdporcupine wrote:
| EDIT: wrote something stupid here before my morning
| coffee
| pquerna wrote:
| This is an Eclipse foundation project, not an Apache
| Software Foundation (ASF) project?
|
| it's all volunteers/open source, but this isn't an ASF
| project.
| cmrdporcupine wrote:
| I'm sorry, I hadn't finished my coffee yet.
|
| I'm gonna go embarrasingly delete this thread tail
| between my legs...
| caniszczyk wrote:
| Apache isn't a silver bullet... there are plenty of Apache
| projects where the individuals are compromised mostly from
| one company and hide behind the veneer of the ASF... where
| they are working on the projects per their employment.
| Gerrymandering is definitely possible and has happened in
| the past, that's why you have to look at governance and
| ownership of the marks/build systems etc:
| https://www.aniszczyk.org/2019/10/08/open-source-
| gerrymander...
|
| I actually prefer the approach of LF, EF or CNCF where it's
| transparent where folks work for and your affiliation is
| disclosed upfront. In the CNCF for example, we separate out
| technical project decisions (maintainers) from funding
| decisions (members). That is healthier than blending it all
| in one at the ASF imho and having no idea where person is
| working for imho.
| FireBeyond wrote:
| Agreed. Red Hat isn't perfect, but when I worked there we
| had a few products that were CNCF under my umbrella,
| including a few incubator projects. Even though we had
| several developers working full or part time on those
| projects, it was always something I was meaningful of,
| not stacking the project board Red Hat-heavy, to not make
| it a defacto RH project.
| KetoManx64 wrote:
| After the RedHat/Hyprland fiasco, it feels like RedHat is
| corrupt with SJW that are focused more on polics than on
| actual code
| eikenberry wrote:
| This is one reason to avoid any company run software that
| requires a CLA to contribute. No CLA makes it a lot harder to
| do this, at least if they have very much in the way of
| community contributions. Distributed ownership would keep
| them honest.
| gsich wrote:
| EEE all over again.
| jzb wrote:
| This is one of the reasons people should hold the line for open
| source licensing for any infrastructure software: Any licensing
| scheme that forces a relationship with a single entity /
| doesn't allow for forking is open to abuse of users and
| customers at some point.
| JohnDeHope wrote:
| > They may be nice folks today, but who knows who will run the
| place in 5y when the next round of squeeze comes?
|
| The same idea applies to political questions. A politician I
| like is proposing a policy I approve of. Great! Now what
| happens in the next election cycle, when a politician I don't
| like gets to use that same power to do something I don't
| approve of? Woops.
| nickpsecurity wrote:
| We can vote for different politicians after a few years. The
| politicians can vote to remove laws that were problems.
| There's a straight-forward solution to that.
|
| Building critical features on a single, closed-standard
| database means you can't leave unless you rewrite all code
| that relied on it. The new code must integrate in the system
| well. The change must also happen without taking down the
| business.
|
| For these reasons, politicians and laws change regularly but
| companies rarely escape database lockin.
| zeeg wrote:
| You have nailed their issues - packaging and their revenue
| model. If you align this well with your target audience the
| license would have not been a problem for them. Wrote about
| this a bit here: https://cra.mr/open-source-is-not-a-business-
| model/
| wrycoder wrote:
| Well named! It is like a roach motel - once in, you can never
| leave.
| nailer wrote:
| Slightly off-topic but:
|
| > a future Oracle/landlord
|
| I don't think I've ever heard Oracle's business model described
| so accurately.
| pas wrote:
| it's the classic vendor lock-in, it's the feudal serfdom
| model.
|
| https://www.reddit.com/r/AskHistorians/comments/weva2v/did_p.
| ..
|
| we can see that as long as there were "expoitable resources"
| competition led to "good times".
|
| as long as "software lordships" are competing for users,
| users tend to enjoy "lots of rights".
| SoftTalker wrote:
| > the problem with the Enterprise edition is that it's quite
| expensive
|
| Seems to me that it's still free for development, and small
| business use. If you're over $10M in revenue, with a business
| or product built on CockroachDB, they want a share of what they
| made possible. That seems totally reasonable to me.
| yencabulator wrote:
| You'd be a fool to put all your eggs in this basket:
|
| > Annual term. Can be renewed subject to meeting the then-
| current eligibility requirements
| WuxiFingerHold wrote:
| > perceived abuse of the Core edition
|
| They don't say that this was the reason for the change. What
| makes you presume it was "perceived" if they had said it was a
| reason for the change? I think it's the opposite: Too few used
| the open core edition, as it is quite limited. They want to
| increase the overall usage. They want to get growing companies
| using it. I think it's a fair move: Use it for free as long as
| you grow. You benefit. When you're large, pay us back. We
| benefit.
|
| > feels like taking a bite of this edition is possibly getting
| into bed with a future Oracle/landlord type of relationship
| where you end up squeezed by your database vendor
|
| That's about the strongest negative allegation one could come
| up with. Unobjective content and wording. There're thousands of
| software vendors or service providers out there (DB and not)
| that are competitive (they all are) but fair. _Every_ of our
| much liked startups like Supabase, Neon, Vercel makes the entry
| very cheap or free and compensates for that with larger fees
| from the larger customers. There 's nothing shady about it.
|
| As I said, your post has to much negative bias in content and
| esp. wording. I don't see that. Factually, there's not risk at
| all. Every company (see Redis) can change their license of
| their future work. So you _never_ have any guarantees. With or
| without a core edition.
|
| If you want "true" open source, you can't choose a software
| developed by a company. The goal of a company is to make money.
| That should not be surprising.
| leeoniya wrote:
| > It took at least 17y for Amazon to get rid of its last Oracle
| database:
|
| this is from CockroachDB license, pretty much straight out of
| Oracle's playbook:
|
| > You will not perform Benchmarks against any products or
| services provided under terms that restrict performing and
| disclosing the results of benchmarks of such products or
| services, unless You have the lawful right to waive such terms.
| If You perform or disclose, or direct or permit any third party
| to perform or disclose, any Benchmark, You will include in any
| disclosure and will disclose to Licensor all information
| necessary to replicate such Benchmark, and You agree that
| Licensor may perform and disclose the results of benchmarks of
| Your products or services, irrespective of any restrictions on
| benchmarks in the terms governing Your products or services.
| statusgraph wrote:
| That seems... fine? The terms basically imply that if you
| publish a benchmark you need to let CRDB reproduce your
| benchmark and discuss it publicly
| wvh wrote:
| Very much this sentiment. While these sort of licenses and
| business relationships might make sense for high-margin
| industries that have specific needs, as somebody who has been
| doing consultancy for the last x years, I tend to advise most
| companies against the use of software with vendor or data lock-
| in, and I'm always sad and weary when this happens to
| interesting long-term projects where such business decisions
| get made which erode the trust in a healthy future [for smaller
| companies and more general purposes].
|
| I'm not criticising a company's business decisions here, it
| might make sense for CockroachDB's business and profit goals;
| but such decisions also impact the decisions of dependent
| users, and I've been too long in this to recommend products and
| services with increasingly restrictive licensing or technical
| features that create unhealthy dependencies.
|
| Since the AWSification of software licenses, I'm seeing more
| and more projects where a company is trying to get out of
| product/service X or license Y because they're unhappy or
| pivoting and the license or tech just doesn't fit the purpose
| any more, at high cost, occasionally even taking down the
| company.
|
| I guess it's not trivial to balance abusive practices from big
| players that don't contribute much back with necessary freedom
| for smaller customers to experiment and freely move between
| technical solutions.
| xnx wrote:
| What are the remaining use cases for CockroachDB where there
| isn't a better/open-source alternative?
| Cwizard wrote:
| multi-master writes with serializable transactions
| sroussey wrote:
| FoundationDB
| geenat wrote:
| AFAIK more of a document store unless you use mvsqlite
|
| The architecture is ingenious, though.
| Cwizard wrote:
| Does not have a SQL API (or something similar). The record
| layer is interesting but requires your application to be
| build in Java.
| c4pt0r wrote:
| TiDB
| _joel wrote:
| Enforced telemetry for free users? That's gross.
| red_admiral wrote:
| Not only that, but according to the licence agreement, there
| are "technical countermeasures" to stop you from using the
| product if you were to block telemetry with a firewall
| (presumably it stops working if the telemetry server doesn't
| send back an acknowledgement), and "You understand and agree
| that Licensor may use and disclose personal information
| collected as part of Telemetry in accordance with Licensor's
| Privacy Policy" ... wait, what?
| michaelt wrote:
| In the closed source world it's common enough that free
| trials will be something along the lines of "we give you a
| license key tied to your name, and every time you start the
| software it calls into our license server to validate the
| license key"
|
| It's bad, but it's not unusual if you use closed-source
| software.
| ezekg wrote:
| Sure, but I'm not sure why they wouldn't just use a signed
| license file with a start- and stop-date in this case. Lots
| of companies, especially enterprises, run air-gaps and
| telemetry just won't work there. And they should know
| that... it's their target market after all...
| red_admiral wrote:
| I guess this is fine for a free _trial_, if you can host it
| in some separate firewalled-off subnet where it doesn't
| touch your real customer data.
|
| The issue here is that if you're an org with less than $10M
| turnover, you're currently on the Core plan and don't want
| to negotiate the full "Enterprise" licence (which is
| presumably priced towards larger users than you anyway),
| then you can't use the thing at all anymore unless you
| agree to telemetry and some vague disclosure of personal
| data thing that will get your lawyers in a spin (especially
| if you serve states in which GDPR applies).
|
| EDIT: oh, and PCI-DSS requirements if you want to take
| credit cards? That's going to be fun.
| sakjur wrote:
| I really hope they're more lenient than that. Having a
| database go offline because their telemetry servers are
| down, slow, or unreachable seems inconvenient.
| WatchDog wrote:
| They have indicated that they will continue to make the
| source available.
|
| Assuming you pay for a license, does the license prevent you
| from building your own fork, and patching out the telemetry
| code?
| dzonga wrote:
| predictable and pretty good business move.
|
| these things are easy to evaluate - 1. what's your appetite in
| running infra ? low - then use the SAAS offering 2. doable - then
| use a db that has good scalable solutions in this case mysql ->
| vitess since those products don't come from a database vendor.
| mongo might qualify too
| ensignavenger wrote:
| Whats your appetite for a SaaS vendor unpredictably and without
| enough warning changing the price they are charging you, or
| pushing updates to the SaaS that break your business? Better
| get it put into the contract.
| evantbyrne wrote:
| Their target customers for self-hosting are Enterprises with
| a capital E who are used to signing multi-year software
| contracts.
| ensignavenger wrote:
| I don't know much about CockroachDB's business, so I was
| just speaking in general about SaaS products and licensing
| non-open source software.
| jauntywundrkind wrote:
| You need an enterprise that's already decided to use CockroachDB
| if your trial offer is only 30 days long. We've barely walked
| around the car & kicked the tires before that trial runs out;
| it's not respectful of the time it takes enterprises to move at
| all.
| 999900000999 wrote:
| I'm trying to figure out how this is better than Postgress ?
|
| Does it perform significantly better to justify the cost? Back in
| the day I worked heavily with databases and we always tilted
| towards open source.
| red_admiral wrote:
| CockroachDB is basically "run postgres on a cluster with more
| fault tolerance" - you can have machines (or entire
| datacenters) going down, netsplits etc. and as long as there's
| enough infra up to keep going, it will.
|
| Presumably only a small subset of postgres users really need
| this feature - and those that do, are big enough to need an
| enterprise licence.
| 999900000999 wrote:
| I'll admit I haven't worked directly in this space in a good
| while, but the whole mystery terms really rubs me the wrong
| way .
|
| For example if I have a company that provisions databases on
| behalf of my clients, is this 10 million revenue cap for my
| company, or for the clients themselves .
|
| The pricing isn't even on the website for self hosting, I
| presume it's one of those if you need to ask you can't afford
| it type situations.
|
| Plus you're locking yourself into a vendor that has no
| worries about changing its terms again later on.
|
| >Required only during the trial period. Businesses that
| cannot accommodate telemetry may contact sales to request an
| exception. Paid use does not require telemetry.
|
| From some of the industries I've worked in, this is a massive
| red flag. We don't want to give you telemetry at any point in
| our process.
| zellyn wrote:
| For most databases (like Postgres), you typically run a single
| database (per shard, possibly), and replicate changes to a live
| read-only backup as fast as possible. If the live R/W database
| fails, you quickly switch the backup to R/W, and point traffic
| there instead.
|
| Then, there's a class of databases that tries to actively
| commit across multiple geographies. You pay a cost (in terms of
| latency, and typically also $$$), but when a commit succeeds,
| it has been written durably and reliably, using some consensus
| protocol, across multiple geographies.
|
| The exemplar is probably Spanner, which uses atomic clocks to
| get very specific about time to narrow the latency gap as much
| as possible. Cockroach is broadly in the same class, although
| without atomic clocks I believe it's using network roundtrip
| measurements and/or some kind of mathematical time abstraction
| (like counters of come kind) to do the same thing. Can't ever
| be quite as fast, but you don't need atomic clocks!
|
| What's _really_ funny is when people start out choosing Spanner
| because of its global replication, then decide it's too
| expensive, and settle on regional non-replicated Spanner DBs to
| save cost. Like, that's just a database, man. (Or maybe
| something slightly above a single database, like Aurora
| replicated across Availability Zones in the same Region).
|
| Other folks can chime in, but there are a growing number of
| databases in this class. TiDB I believe is one. I _thought_
| PlanetScale was just sharded mysql (Vitess+MySQL = clever
| auto-(re-)sharding), but perhaps it does replicated writes too
| - I see it getting mentioned here a bunch.
| 999900000999 wrote:
| Assuming I need to host on prem, do any fully open source
| solutions exist for this .
|
| It really looks like every database company is trying to
| become Oracle. You want your clients to be trapped and unable
| to leave, so if you hypothetically just up the price by 30 or
| 40% upon renewal they either have to rewrite their entire
| stack, or pay the piper.
| WuxiFingerHold wrote:
| Sharding (huge data and local distribution, even worldwide) and
| HA by retaining serializable transactions. Possibly easier to
| operate.
|
| The downsides are:
|
| - slower - Postgres (if it can handle the amount of data, which
| is very much on proper hardware and partitioning of > 1B row
| tables) is much faster, esp. for joins
|
| - features
|
| - ecosystem (see the countless extensions)
|
| - cost of course
| PeterZaitsev wrote:
| Finally all Open Source pretense is dropped. CockroachDB becomes
| Enterprise+Cloud database company with a free tier, not
| dissimilar from Oracle.
|
| The revenue driver as a driver for freemium tier is interesting
| as it seems like it would require company to regularly disclose
| their revenue to CockroachDB which looks intrusive.
| bonzini wrote:
| Props for calling it source available and not hiding behind
| "you can't police the meaning of open source", though.
| jpgvm wrote:
| I actually think source available software is great. Not
| every piece of software can survive as OSS but source
| available eliminates most the downsides of closed-source
| software from a technical perspective.
|
| In my daily life I use a lot of essentially source-available
| software that I pay for. I spend like 4+ hours a day every
| day in IntelliJ IDEA etc. I don't have a problem paying for
| software, I have huge problems paying for software that I
| don't sufficiently control and/or it's closed-source nature
| affects it's ability to get it's job done - i.e anything
| mission critical where uptime and security are paramount.
| Vespasian wrote:
| I certainly agree.
|
| And it makes sense (for Enterprise "tech stack" software).
| A license violator would just crack your software anyway
| and legitimate paying users pay for it and want less
| hassle.
|
| You probably will save on some support calls if their
| engineers can take a quick look themselves.
|
| Same goes for any "secret Sauce" in the Code. Most Software
| of that Type isn't algorithmically novel enough to warrant
| drm and obfuscation.
|
| And again a serious criminal comoetitor would spend the
| money to reverse it
| ThinkBeat wrote:
| I am a great fan of scaling vertically as far sa possible on DB
| servers. These days that is pretty damn high. It avoids a lot of
| prickly edge cases.
|
| It is definitively not one solution for all. There are many cases
| where it just won't work.
|
| I would like to see more IBM Z servers being used. $$$$$$$$
| though
| ted_dunning wrote:
| It doesn't solve for required multi-region data storage. Nor
| for data center failure resilience.
|
| Scaling up is fine for a few things, but hopeless for many
| others.
| JackSlateur wrote:
| For data-center failure, it does: the underlying storage can
| be resilient.
|
| For multi-region, indeed, that will not be possible. Master-
| slave would be the way.
| kelsey98765431 wrote:
| Another database fails to be better and ends up worse. This is
| why we use DAL agnosticism.
| cynicalsecurity wrote:
| I've never seen this database used by anyone in real life.
| traderj0e wrote:
| I'm skeptical of this kind of multi-master horizontal DBMS to
| begin with. Never used Cockroach but have used Spanner, and
| even besides the $, you pay with complexity, slowness, and
| limitations. Even the in-betweens like Citus have their issues.
| As far as I can tell, the world runs on traditional DBMSes like
| Postgres, maybe with HA. If you're big, you run multiple and
| shard at the application level. I don't think there's a better
| option yet.
|
| Btw, Spanner and Cockroach both have fully serializable
| transactions. Even single-node Postgres doesn't do that by
| default (though it can) because they didn't think the
| performance tradeoff was worthwhile. Read-committed is good
| enough.
| dilyevsky wrote:
| Is Netflix[0] real life enough?
|
| [0] - https://www.cockroachlabs.com/blog/netflix-at-
| cockroachdb/
| redwood wrote:
| That's impressive. I'm genuinely surprised they have users at
| this scale. Are there others?
| dilyevsky wrote:
| I heard that doordash ran a cluster serving >1M qps, there
| maybe still a setup at square/block where the team
| originated from
| redwood wrote:
| I guess most of the larger deployments are self-managed
| rather than their SaaS offering... Do you think this is
| mostly running on top of hyperscaler infrastructure? Or
| in traditional enterprise data centers? I'm just
| surprised because I never see it
| dilyevsky wrote:
| It looks like[0] DoorDash is running theirs self-hosted
| and just on their cloud, not in the DC. At former gig we
| ran our much smaller clusters (largest one was ~10T and
| 20k qps) on kubernetes on cloud. Deployment/updates and
| what not wasn't difficult - the biggest difficulty was
| not accidentally overloading the DB from the application
| layer as always.
|
| [0] - https://www.youtube.com/watch?time_continue=97&v=jC
| jrfpF64Kc
| ezekg wrote:
| I posted it on Twitter, but I feel like revenue-based licensing
| models unnecessarily push the compliance burden onto the user.
| It's an honor system, and even they admit it [0]; even Unity, who
| also uses a revenue-based model, admits it [1]. I'd prefer
| licensing models that are able to automatically segment users
| into customers at the software-level, such as a feature-based or
| usage-based model. For example, they could segment on CPU count
| or disk size, requiring an Enterprise offering for databases or
| clusters over a certain threshold.
|
| But completely doing away with Core and requiring license keys
| even for free users [2] (which I assume is for revenue auditing
| purposes) ... I feel like that's a big step backwards. All of
| this because their Enterprise offering seemingly wasn't valuable
| enough (or from the comments -- it was too expensive).
|
| I'd of focused there, on making Enterprise more valuable or more
| accessible, instead of doing something this drastic.
|
| AFAICT, they're also doing away with BUSL and DOSP [3], which is
| a big bummer.
|
| [0]: https://techcrunch.com/2024/08/15/cockroach-labs-shakes-
| up-i...
|
| [1]:
| https://www.reddit.com/r/Unity3D/comments/82mfwh/how_could_u...
|
| [2]: https://www.cockroachlabs.com/blog/enterprise-license-
| announ...
|
| [3]: https://opensource.org/dosp
| Eumenes wrote:
| They're following the Mongo playbook
| joeblubaugh wrote:
| > Even by conservative estimates, the vast majority of the
| world's businesses will meet the eligibility requirements for the
| Enterprise Free Tier license
|
| This feels dishonest. What percentage of the world's business
| need a system like CockroachDB? Of those, what percentage are
| under 10 million in revenue?
| Nathanba wrote:
| if it were really the case that the vast majority of businesses
| doesn't need to pay then they'll just adjust it down to 1
| million in revenue
| rmoriz wrote:
| How to comply with telemetry in air-gapped environments?
| sroussey wrote:
| You don't. I assume the free version is not licensed for that
| use case.
|
| :/
| jappgar wrote:
| "Open-source" in 2024 is a synonym for "ransomware."
|
| It's still nice that I can audit the code and contribute (unpaid)
| changes, but I no longer assume anyone is acting in good faith.
| max-privatevoid wrote:
| This is why you should look for software that calls itself
| "FOSS" or "Free Software" instead. Avoid CLAs at all costs as
| well. If the software is licensed under a GPL-like license
| without a CLA and has had significant contributions from
| multiple people, this relicensing rugpull is nearly impossible.
| simonebrunozzi wrote:
| I spotted this company in their seed stage and wanted to invest.
| The founders asked us to provide names for reference checks, etc
| - a bit unusual, but we were almost done with the commitment, so
| why not?
|
| After quite a lot of work, introductions, and back and forth,
| they told us: sorry, Google Ventures is investing and we're
| kicking everyone else out, despite we expected an allocation at
| that point (50k, not very large). Not nice by them, and not nice
| by GV, but... Just another lesson learned in the epicenter of
| startup investing which is San Francisco. This was Feb 2015. Wow,
| almost 10 years ago. Time flies.
|
| I am still happy to see they've been successful at building the
| company. I loved the product from the very beginning.
| Thoreandan wrote:
| > Does this mean that CockroachDB is no longer open source?
|
| > CockroachDB will remain source available under a new license.
| While the new license is a proprietary enterprise license, the
| source code will still be available for viewing and
| contributions.
|
| The word you're looking for is "yes".
| JonChesterfield wrote:
| I'm just so shocked that VC is following the open source for a
| while then fuck you business playbook. If only there was prior
| art to warn people that this was a risk, like all the other VC
| backed software projects.
| ezekg wrote:
| I said it somewhere else, but this FAQ is likely because most
| people think "source available on GitHub" = "open source", so
| they're just answering the low-hanging-fruit even if the
| question is technically incorrect. Not everybody is aware of
| the differences between "on GitHub" vs OSS, the OSI, the FSF,
| etc.
| drdaeman wrote:
| Coming next decade: companies marketing their product as "open
| source" because they have an empty GitHub repo for issues.
| yencabulator wrote:
| Or a repository with some source code under a free license,
| and then some .so and executables in a subdirectory. I'm
| looking at you Sciter.
| croes wrote:
| It's always obvious when they need multiple sentences to answer
| a simple yes or no question.
| lolinder wrote:
| It was already not open source, hence the weasel language. "It
| will remain source available" is the second-most
| straightforward way to say "it already wasn't, but it's awkward
| to admit that given that we allowed you to misunderstand the
| license for five years".
|
| Discussion from five years ago:
|
| _Relicensing CockroachDB_ June 4, 2019 (487 points, 282
| comments) https://news.ycombinator.com/item?id=20097077
|
| The blog post is a 404, here's the archive:
| https://web.archive.org/web/20190604173131/https://www.cockr...
| JonChesterfield wrote:
| Ensure your data is secure with our mandatory telemetry. No deal.
| jillesvangurp wrote:
| That's another company that feels like they don't want to be an
| OSS company after all. After Elastic, I pay more attention to
| contributor agreements. Basically I consider any project that
| requires transfer of copyright for OSS contributions as likely to
| change their license at some point. It's fine; I'm not against
| that sort of thing and I sometimes pay for software. But I like
| to know what I'm getting into before and I don't appreciate the
| bait and switch. It also guides decisions as to what I contribute
| to actively.
|
| I do a simple sanity check with any OSS software before using it:
|
| - Make sure there is no contributor agreement requirements. This
| is a gigantic red flag that the license can and probably will be
| changed at some point.
|
| - Make sure the license is not overly restrictive (like AGPL). I
| appreciate people have good reasons for picking this license; but
| it comes with some serious restrictions in a commercial
| environment. And like it or not, a lot of companies have active
| policies against this. Either way, I avoid anything with this
| license.
|
| - Make sure the project is actively maintained. You don't want to
| get stuck with unmaintained software. Replacing dependencies is a
| PITA.
|
| - Make sure the project is not overly dependent on VC funding.
| Startups fail all the time at which point anything they worked on
| turns into abandon ware.
|
| - Ideally, make sure the project has a healthy diverse group of
| committers. Healthy here means more than one company is involved.
| Most projects that fail one or more of the above tests usually
| aren't very healthy in this sense.
| mplanchard wrote:
| tbf I think both GNU and Linux require copyright assignment,
| and I don't think that either of those are likely to swap
| licenses any time soon
| orra wrote:
| FYI, you're right about GNU (by and large), but mistaken
| about Linux.
| ddtaylor wrote:
| GNU has contributor agreements?
| rpdillon wrote:
| Absolutely! They want to have standing in court so they
| can defend infringers, and that's materially easier to
| establish with copyright assignment agreements.
|
| https://www.gnu.org/licenses/why-assign.en.html
|
| So while I agree with other commenters that a CLA is a
| clear indication that the entity seeking to have
| copyright assigned wants to reserve the right to take
| some kind of legal action at some point (like changing
| the license), it also applies in cases where the legal
| action is benevolent rather than malevolent (like
| defending the copyright).
| mplanchard wrote:
| Whoops, you're right! I thought there was some kind of sign
| off in there. My mistake.
| jillesvangurp wrote:
| Neither of those licenses require copyright ownership
| transfer. It's what makes Linux completely bullet proof
| against license changes. You'd have to track down every
| copyright holder (everyone that contributed, even if it's
| just a 1 line change) to get their permission for re-
| licensing their contribution. Which in the case of Linux is
| literally tens of thousands of individuals and companies, if
| not more.
| arp242 wrote:
| Most GNU projects require a copyright assignment. For
| example, GNU coreutils: _" note that non trivial changes
| require copyright assignment to the FSF as detailed in the
| "Copyright Assignment" section of the Coreutils HACKING
| notes."_ (from:
| https://www.gnu.org/software/coreutils/coreutils).
|
| As far as I know, this is case for most GNU projects.
|
| Linux only requires a confirmation that you wrote the
| patch; previous poster was mistaken about that, but they
| were correct about GNU.
| znpy wrote:
| This is a trust point, though: assigning copyright to the
| free software foundation allows code to be relicensed
| under new versions of the gpl.
| shagie wrote:
| https://www.gnu.org/licenses/gpl-3.0.en.html - section 14
| The Free Software Foundation may publish revised and/or
| new versions of the GNU General Public License from time
| to time. Such new versions will be similar in spirit to
| the present version, but may differ in detail to address
| new problems or concerns. Each version is
| given a distinguishing version number. If the Program
| specifies that a certain numbered version of the GNU
| General Public License "or any later version" applies to
| it, you have the option of following the terms and
| conditions either of that numbered version or of any
| later version published by the Free Software Foundation.
| If the Program does not specify a version number of the
| GNU General Public License, you may choose any version
| ever published by the Free Software Foundation.
|
| Note the "or any later version" verbiage in there. If the
| software is licensed under "GPLv3 or any later version" -
| no permission is required or assignment of copyright.
|
| And so when you see things like
| https://directory.fsf.org/wiki/Coreutils
|
| Note _also_ the "if you used the GPL _without_ a version
| number, you can relicense it under any version "
|
| ---
|
| The "why they require a CLA" is for enforcement.
|
| https://www.gnu.org/licenses/why-assign.en.html
| In order to make sure that all of our copyrights can meet
| the recordkeeping and other requirements of registration,
| and in order to be able to enforce the GPL most
| effectively, FSF requires that each author of code
| incorporated in FSF projects provide a copyright
| assignment, and, where appropriate, a disclaimer of any
| work-for-hire ownership claims by the programmer's
| employer.
| deathanatos wrote:
| > _The "why they require a CLA" is for enforcement._
|
| None of that seems like a "why" to me; to cynically
| paraphrase it, "our policies require our polices." _Why_
| does your record-keeping require a CLA? Why is a CLA
| required to enforce the GPL?
| tsimionescu wrote:
| A CLA is required to be able to sue someone infringing
| the GPL and represent yourself as the legal owner of the
| entirety of that code. If you have a hugely fractured
| ownership like Linux, it may be very expensive to bring a
| suit against an infringer.
| jillesvangurp wrote:
| That might be true for the GNU foundation. But they don't
| actually control/host the vast majority of software
| licensed under the many GPL variants. None of the GPL
| licenses actually cover any form of copyright transfers.
| Including the AGPL. That's done via separate contributor
| agreements typically. The GNU foundation doesn't control
| the licenses either. That's a job done by the free
| software foundation. Which doesn't host any projects as
| far as I know.
|
| At this point the GNU foundation mostly just runs
| relatively small, older projects and that definitely does
| not include the linux kernel. That one has its own
| foundation called the Linux foundation. The Linux
| foundation runs many hundreds of projects and they
| operate mostly without contributor licenses as far as I
| know. And in so far they do those agreements are not
| about transferring ownership of the copyright but
| asserting ownership to ensure that the contributions
| people make are actually legal.
|
| Big corporations moving code bases under their control
| seems to be a regular thing and that includes some pretty
| high profile projects recently. And of course there are
| many more projects on Github that use one of the GPL
| licenses. The vast majority of which don't have any
| contributor license.
|
| So, I don't think I'm that wrong here at all that this is
| not that common. The previous poster seems to confuse the
| license with the GNU foundation which is a tiny subset of
| the overall GPL licensed software ecosystem.
| hollerith wrote:
| There is a Gnu Foundation, but it has nothing to do with
| computing: http://www.gnufoundation.org/who-we-are
|
| You mean the GNU Project.
| F3nd0 wrote:
| I don't think either of the comments you replied to has
| stated the opposite. They both spoke of GNU, not the
| overall GPL licensed software ecosystem.
| arp242 wrote:
| > But they don't actually control/host the vast majority
| of software licensed under the many GPL variants. None of
| the GPL licenses actually cover any form of copyright
| transfers.
|
| No one claimed this is the case. The only person
| conflating "GNU" with "GPL" is you.
|
| You said projects with copyright assignments should be
| distrusted. Someone pointed out that GNU projects require
| this, which you promptly denied, and I just wanted to
| correct the record on that. Nothing more, nothing less.
| aseipp wrote:
| No, the FSF specifically requires ownership transfer for
| GNU projects, so that they can do things like go after
| infringements in court, or relicense GNU projects to newer
| versions of the GPL unconditionally, e.g. when GPLv3 was
| released.
|
| Ironically, CLAs like the one Google and Meta use for their
| projects on GitHub do not require ownership transfer --
| only the rights to redistribute, because the prevailing
| Lawyer-brain belief is (roughly, to my understanding) that
| just _assuming_ that right from the license itself isn 't
| necessarily sound.
|
| For licenses like Apache 2.0, assignment/ownership is a
| kind of irrelevant practical distinction because entities
| can just distribute proprietary versions anyway (and
| because it's not clear if you really agree to much more
| than e.g. Apache 2.0 implies), which is the prevailing
| worry people have. Most of the people here actually want
| GPL-style copyleft licenses along with some vague idea of a
| "communal project", even if they don't know it. Because
| that's the only way to achieve the practical desired
| outcome, where your code and contributions stay open and
| are difficult to "rework" in this way. The talk about CLAs
| and all the other stuff is irrelevant; it's a matter of the
| politics and composition of the project, not the exact
| legal words in the license.
|
| > everyone that contributed, even if it's just a 1 line
| change
|
| That depends on the jurisdiction. There is a concept called
| the "threshold of originality" in the US which states
| roughly that some obvious, trivial things just can't be
| copyrighted. Typofix patches that change "form" to "from"
| aren't meaningful enough to be given copyright, so you
| literally do not need to be consulted on the matter at all.
| It is not clear that simple bugfixes fit under this
| definition either for example, because they may be obvious.
| Realistically, I'd say there are very few contributions
| that are going to fit in 1 line while being original enough
| for copyright to apply. They could also just not include
| your patch too or rewrite it, in that case, so the "1 line"
| case is pretty much meaningless in practice.
| teddyh wrote:
| > _No, the FSF specifically requires ownership transfer
| for GNU projects_
|
| No they do not. _Individual GNU software projects_ might
| require it, but this choice is up to the project, not the
| FSF.
| orra wrote:
| > That's another company that feels like they don't want to be
| an OSS company after all
|
| TBH that's nothing new for Cockroach. Even back when they were
| open core, the core was so restricted it didn't include backup
| & restore.
|
| I think that may have changed, but only when they changed the
| license of the core to BSL, that is making the core non open
| source for three years.
| dilyevsky wrote:
| Correction - backup and restore was there, just not
| _incremental_ backups. Which, yes, on very large DBs = no
| backup.
| mixmastamyk wrote:
| AGPL + commercial license is a solution for keeping a project
| open while avoiding the situation where profit goes to cloud
| hosting.
|
| Is there a better solution?
| jillesvangurp wrote:
| Unfortunately you can't do commercial licenses unless you
| take full ownership of each and every source contribution.
| So, it means there is zero guarantees the project stays open.
| AGPL without that is a non starter for commercial usage.
| tsimionescu wrote:
| Some of the most popular database and database related
| projects & products have been or are AGPL. MongoDB became
| massively successful as AGPL from the start. Grafana has
| been AGPL for 3+ years.
|
| The AGPL is absolutely viable in commercial contexts. There
| are a handful of companies that have hangups about it, but
| the industry overall has long since realized that it is
| almost identical to the GPL for most practical purposes.
| johannes1234321 wrote:
| Mi d that those companies do dual licensing. All
| companies which worry about AGPL got to buy the
| commercial license to be on the safe side. While only the
| original vendor is able to do that, creating an imbalance
| between what they can do and an external contributor can
| do. (While external contributions are of limited interest
| for vendors who want to control a roadmap etc. and treat
| open source as marketing vehicle anyways)
| OutOfHere wrote:
| LGPL is friendlier for commercial use. Keep the core LGPL,
| and the enterprise version proprietary.
| tsimionescu wrote:
| This one is not a solution.
|
| The first of these open source companies to switch to a
| closed source license because the big bad cloud was eating
| their lunch was MongoDB, which was already AGPL. The AGPL, by
| design, doesn't stop anyone from offering your code: it
| merely makes sure that they provide the source code and
| installation instructions to anyone who is using the service.
| Amazon is only to happy to provide this, and they always have
| for all of the services they offer (that require it). They
| even contribute to some of these projects.
|
| Also, from the perspective of the free software movement at
| least, there is nothing to solve here. The whole point of the
| GPLs is that you don't get to have any special power over the
| code that you create: everyone who gets a copy has the exact
| same rights to it that you do, including the right to run
| your company under the ground if they can outcompete you.
| bityard wrote:
| CockroachDB hasn't been an open source project in more than 5
| years.
|
| They took down the blog post (I'd be curious to know why), but
| here is the announcement:
| https://web.archive.org/web/20190604173131/https://www.cockr...
|
| What started as a neat project with a vibrant and enthusiastic
| community is now just another dull beige enterprise vendor.
| zachmu wrote:
| The BSL doesn't make it closed source, it prevents a
| competitor from running their own DBaaS business using
| Cockroach as the backend. This has happened to various open
| source projects, AWS started selling their technology and ate
| their lunch.
|
| BSL is a totally fair compromise for commercial open source
| licensing imho.
|
| If you see BSL as the first step to an announcement like
| today's, that's a fair criticism. Not sure how often that
| happens. But BSL doesn't disqualify software from being open
| source.
| jen20 wrote:
| The BSL is not an OSI-approved license, so it's certainly
| not "open source" by the commonly used definition.
|
| I agree it's a reasonable license. But it's not an open
| source license.
| LtdJorge wrote:
| It even says it is not an open source license right in
| the license
| immibis wrote:
| The OSI is a consortium of cloud platform vendors (really
| - check for yourself). Of course they'll define open
| source in a way that excludes licenses that restrict them
| from turning your work into closed-source cloud
| platforms. The good news is that we're not beholden to
| their definition as they have no official status
| whatsoever. We don't have to believe them just because
| they put the words Open Source in their company name.
|
| The BSL is clearly not open source since it requires
| approval from the licensor in certain applications, but
| the OSI also rejected the SSPL, which is just an extended
| AGPL that requires source code publication in even more
| cases, and is clearly open source because of that.
| sgarland wrote:
| I hadn't considered this angle, stupidly. Now I have to
| rethink a minor belief system.
| jen20 wrote:
| OSI, and the open source definition they produced,
| predate the very notion of public cloud by close to a
| decade. While you don't have to accept the definition,
| you are out of step with the industry at large, who
| broadly use "open source" to refer to things which meet
| the OSI definition. There's no need for a competing
| definition: it's fine for software to not be open source.
|
| As to the specifics of SSPL, I personally don't see the
| rationale for accepting AGPL but not SSPL.
| AntonCTO wrote:
| At large? As you can see, there is room for a community
| with a different view on that. My personal definition of
| an "open source license" is that, as the name implies, I
| can access the code, preferably without much gatekeeping
| (e.g., creating a free account in a private GitLab
| instance). And, to be honest, I prefer the BSL with an
| Additional Use Grant over any other license, because this
| is the most reliable option to ensure that the project
| has a future and won't be abandoned because no one wants
| to invest their time for free.
| yencabulator wrote:
| > but the OSI also rejected the SSPL
|
| So did Debian and Red Hat. Do you think AWS leads them
| both?
| chrisoverzero wrote:
| > The BSL doesn't make it closed source [...]
|
| Yes, that's right!
|
| > But BSL doesn't disqualify software from being open
| source.
|
| No, that's wrong: https://spdx.org/licenses/BUSL-1.1.html
|
| > The Business Source License [...] is not an Open Source
| license.
| tsimionescu wrote:
| Any license that prevents others from selling your code and
| eating your lunch is, by definition, not an open source
| license.
|
| One good way of looking at the goals of open source
| licenses is to force companies to compete on offering
| services related to the code. Whether this is a sustainable
| idea is a different question, but this is one of the
| bedrock ideas about OSS (and FLOSS as well). The other is
| of course that the rights of those running the software are
| absolute and trump any rights that the original creators
| have, except where the users would try to prevent other
| users from gaining the same rights.
| lolinder wrote:
| > The Business Source License (this document, or the
| "License") is not an Open Source license. However, the
| Licensed Work will eventually be made available under an
| Open Source License, as stated in this License.
|
| -- The Business Source License
|
| https://mariadb.com/bsl11/
| tbarbugli wrote:
| https://github.com/cockroachdb/cockroach/graphs/contributors
| tristor wrote:
| I like the technology here, but at the same time I feel like
| they've been on this trajectory since the beginning. It's just
| another VC-backed company using open source for marketing,
| without any legitimate desire to actually be open source. At
| least now they've pulled the wool off of it.
| osigurdson wrote:
| I think the reality is, only exceeding common codebases (Linux
| and Postgres for example), can survive with an open source model.
| If the value created by the product is 1M times greater than the
| costs, fine, a way to support it will materialize. Otherwise,
| economics take over and people need to get paid. The fact that
| source is publicly available is largely irrelevant.
| tsimionescu wrote:
| I don't think the point is how common it is, it's about a
| organizational model.
|
| Linux and Postgres are not reliant on any one commercial entity
| being successful for their continued existence. Even many of
| the maintainers are not reliant: if the company/foundation
| Linus Torvalds is working for at the moment has to close down,
| someone else will pay him to keep working on Linux. And even if
| he couldn't personally work on Linux anymore, there are enough
| other people in a similar position that Linux won't die.
|
| I'm sure there are many much smaller and more obscure projects
| in a similar boat, especially in academia. If the code is not
| dependent on a single entity for maintenance, both in terms of
| someone knowing it and in terms of someone paying for it, then
| it will naturally thrive for a very long time.
| alexvitkov wrote:
| I'm not even going to read this, we all know what it is and we
| all know it's just the first step in a long series of very shitty
| changes, expect all new development to be in the "contact us"
| tier.
|
| Ignorance was maybe excusable the first 15 times, but if you keep
| falling for corporate owned rug-pull OSS packages in 2024, you
| deserve what's coming for you.
|
| Weird databases are NFTs for startup founders. You're not too
| cool for Postgres. Use it.
| Yasuraka wrote:
| This actually moves stuff out of the "contact us" tier, where
| it used to be, and makes everything available to all.
|
| There are new hooks, but paywalling capabilities was not the
| point here.
| 999900000999 wrote:
| New hooks like disabling my database if the telemetry API
| call fails?
| ezekg wrote:
| Per their announcement, it sounds like a free user will have
| to get an annual Enterprise Free license key to use it.
|
| I'd hope that'd be automated, but could also be a "contact
| us" tier to audit revenue. Time will tell.
| zachmu wrote:
| Sometimes it's a reasonable choice to pay for software,
| especially if you're a large company that can easily afford it.
| It's not like "just using postgres" in a manner similar to
| Cockroach's capabilities is trivial, building your own solution
| also has a whole set of risks.
|
| If you're absolutely opposed to ever paying for a software
| solution, then sure, avoid commercial projects. I'm happy to
| spend my (company's) money on useful software.
| vdfs wrote:
| Without marketing bs, what's something that can be done only
| with Cockroach and not postgres or other truly-OSS
| alternatives? I'm curios because I've been reading news about
| it forever but never had the chance to work with it
| vvern wrote:
| Transactional workloads over datasets in the single digit
| petabytes.
| zachmu wrote:
| Think of it as a replacement for spanner with a postgres
| frontend. It's about global availability and replication
| without application-level sharding.
| stickfigure wrote:
| Maybe not cool, but you can, in fact, be both too big and too
| geographically distributed for Postgres.
| dang wrote:
| Can you please not post in the flamewar style here? It's not
| what this site is for, and destroys what it is for.
|
| You can make your substantive points without it, so please do
| that instead.
|
| https://news.ycombinator.com/newsguidelines.html
| pianoben wrote:
| Wow, what a rug-pull! Good luck to Cockroach Labs, but I doubt
| their product is entrenched-enough to make this strategy
| sustainable - it's going to _kill_ growth.
| mehulashah wrote:
| It seems a shame that to grow, companies are backing away from
| the vector that got them there: open source.
|
| I agree that current cloud providers are gaining more benefit
| from open source than they're putting in. So, it seems logical
| that the main developers want to recapture some of that.
|
| On the other hand, open source is supposed to help build a bigger
| pie. If the pie gets bigger faster (i.e. more people using
| CockroachDB) then is the recapture worth it?
|
| It seems the smaller companies think so. But, I don't know of a
| solid analysis that shows this to be true.
| GiorgioG wrote:
| Yeah no thanks, I'll stick with Postgres
| dilyevsky wrote:
| Anyone here migrated to TiDB from cockroach and can share
| experience? Asking for a friend...
| geenat wrote:
| It's a lot more moving parts unfortunately and the TiDB team
| has historically little interest in fixing that.
| dilyevsky wrote:
| Single binary is for sure preferable but given that they have
| k8s operator shouldn't be too bad? CRDB also had its faults -
| their CDC to kafka had terrible reliability even on
| enterprise versions.
| c4pt0r wrote:
| TiDB CTO here, I think that a clear boundary between
| components is beneficial for the maintainability of a
| distributed systems like TiDB, and automated deployment tools
| like `tiup`(https://tiup.io) and the Operator of Kubernetes
| shield end-users from this complexity in order to maintain
| best practices in deployment. While still providing enough
| debugging details for advanced users.
| steeeeeve wrote:
| I'm really not a big fan of holding backups and DR behind
| licensing. That's base level functionality. That and row level
| security, but at least with row level, I get that there has been
| a lot of time and energy expended on that feature.
|
| Cluster optimization, and enhanced security sure. And responsive
| support, absolutely.
| paxys wrote:
| The ability to turn off telemetry collection is missing from
| the free version as well. No thanks.
| FireBeyond wrote:
| It's the same with SSO, and I think it hurts some companies
| more than it helps. SSO too often is an arbitrary selection for
| "Enterprise/$Call Us".
|
| Then you're two or three founders, you set up G Suite, and
| think oh, let's use SSO for this service, and then you're
| paying $$$.
| paxys wrote:
| I get wanting large companies and cloud providers to pay, but
| mandatory telemetry collection in the self-hosted version of the
| product is an absolute non starter.
| purpleblue wrote:
| I guess I don't get it. CockroachDB is decidedly an enterprise
| product. There's no need for even a medium sized company to
| require distributed database the likes of CockroachDB. If you're
| a small company using it, you're just using it for fun, and
| you're probably not paying.
|
| If you're using it and paying for it, then this doesn't seem like
| a problem. If you're not using it, then it shouldn't matter. If
| you're using it but not paying for it, then maybe it's okay that
| you have to start paying for it.
| smw wrote:
| There are quite a few situations where running the (previously)
| open source core was a good fit for business problems which
| would become unprofitable if the enterprise license was used.
| victorbjorklund wrote:
| another open source project has died. At least we will always
| have Postgres.
| znpy wrote:
| Friendly reminder that if you contributed code but signed a
| contribution agreement (which assigns copyright on the code
| contribution to cockroachlabs) you've got nothing to complain
| about.
|
| Never sign contributions agreement: it will be used against you
| when the license inevitably get changed.
| OptionOfT wrote:
| WRT CockroachDB Enterprise Free's telemetry requirement:
|
| > Required (excluding ephemeral clusters of 7 days or less)
|
| Does that mean the cluster will stop working when it can no
| longer report?
| anticensor wrote:
| I understood it as "it pings the HQ once a week".
| timenova wrote:
| I'm guessing the Required Telemetry thing is gonna cause a
| technical/security problem too. Most production databases would
| be running in private isolated networks with no inbound or
| outbound internet access on the VMs, and because of this
| requirement, they'll have to open outbound access to at least
| Cockroach's IPs.
| djaouen wrote:
| Thank God I stuck with Postgres lol
| rnavi wrote:
| Amidst the frequent noise - its hard to notice that even the most
| stringent of OSS licenses like AGPL was written way back in 2002!
| Cloud was not even in the picture. Since then, ever growing cloud
| players have been playing the 'state' role and misusing OSS as
| 'religion' heavily affecting infra OSS products or companies.
| th3w3bmast3r wrote:
| Yup - another "Contact Us" for pricing. God forbid if your
| business grows more than 10 Million ARR and now you owe them
| undisclosed amount of money.
| port19 wrote:
| At this point I'm convinced "Contact Us" is worse for
| business/sales than just disclosing any outrageous fees upfront
| redwood wrote:
| I just don't understand why they didn't go with a copyleft
| license like SSPL; is it because they're worried too many people
| will self-manage in the Enterprise and not pay them?
| 486sx33 wrote:
| It seems cockroach was aptly named
| h_tbob wrote:
| I always use good ol' MySQL. If anything happens can hop to Maria
| WuxiFingerHold wrote:
| It's a surprising and very welcome change. Most will benefit.
|
| If you have more than $10M revenue, why on earth would you run
| the limited open core version of CochroachDB just to save some
| $1K-$10K (which is about the enterprise license cost). The open
| core version has limitations you don't want to miss esp. reg.
| backup and restore, encryption, follower reads. Now all those
| features are available for free if you're small.
| smw wrote:
| That's _not_ what the enterprise license costs for reasonably
| large deployments.
| vinay_ys wrote:
| This made me wonder about postgres. Is Postgres at risk of being
| taken over by some corporate? What can we learn from all these
| free open-source databases that has gone enterprise commercial.
| WuxiFingerHold wrote:
| That is a valid concern, see what happened with Redis or MySQL.
| But I think (while valid) it's very unlikely. Postgres can't be
| "bought". A company would need to start building an own version
| and make it better than the still existing open source version.
| Then they would need to convince people to pay for it. Not a
| good business idea.
| samat wrote:
| PostgreSQL's global, decentralized community, including
| companies like PostgreSQL Professional in Russia, makes a
| corporate takeover unlikely.
|
| Even if the name is taken, the community and independent
| providers would carry on.
| indulona wrote:
| If you prefer mysql sql flavour, pingcap has titanium db(tidb)
| alternative.
| hannob wrote:
| I like this part:
|
| "4. Does this mean CockroachDB is no longer open source?
|
| CockroachDB will remain source available under a new license.
| While the new license is a proprietary enterprise license, the
| source code will still be available for viewing and
| contributions."
|
| I mean... "The answer is kinda sorta 'No', but we really would
| prefer not to phrase it like that."
| port19 wrote:
| Good on them for not mincing words and being upfront about this
| hnarn wrote:
| It's honestly getting tiresome reading about yet another company
| that rides on the wave of open source for popularity and growth,
| but only for as long as it suits their own bottom line. Just like
| every other example, the page is filled to the brim with
| borderline unparsable marketing speak and, excuse my french, pure
| bullshit. Here's an example:
|
| > we are updating our licensing model to better serve our diverse
| community of users
|
| One could hope that whoever wrote this at least had the decency
| to blush while doing so. So here's what's actually happening, as
| I understand it at least:
|
| CockroachDB _used to be_ split into "Core" and "Enterprise".
| Core was Apache 2.0 licensed (open source), Enterprise was BSL
| (fake open source, "source available", bullshit). After three
| years, BSL code becomes real open source. This setup that they
| are sunsetting is already pretty restrictive, and is by no means
| uncontroversially "open source".
|
| The New And Improved(tm) idea they have to "better serve" their
| "diverse community of users" is even worse: it's free as in beer
| to use, but other than that it's completely proprietary, and it
| also includes *mandatory telemetry* for non-paying users. Any
| reference to "open" in regards to this product is a complete lie,
| because being able to read the source code does not make a
| product open source -- Microsoft allows you to read their code
| too, if you sign a piece of paper with them.
|
| I've never used CockroachDB, but I'm glad I saw this, because now
| I know there's a 0% chance I will ever consider using it.
| m463 wrote:
| That's the problem with the term "open source". It is ambiguous
| and can mean anything from public domain to source available.
| If you just allow people to look at the source, you can call it
| "open source" and nobody can really argue.
|
| If you did that and called it GPL, things would be different.
| hnarn wrote:
| It's certainly not ambiguous, but the reason why companies
| like CockroachDB and others would like to make it appear so
| certainly is obvious. Anyone confused can just be referred to
| "The Open Source Definition"[1] by the OSI.
|
| [1]: https://opensource.org/osd
| Aeolun wrote:
| Mandatory telemetry?
| emocin wrote:
| I worked with the cockroachdb founders at a previous company.
|
| They're clowns.
| valyala wrote:
| VictoriaMetrics CTO here.
|
| I don't understand why pure open-source license such as Apache2,
| MIT or BSD should be replaced with some source available license
| in order to increase profits from enterprise support contracts:
|
| - The license change won't force cloud companies signing the
| enterprise agreement with you in most cases. If they didn't want
| paying you before the license change, why they will change their
| mind after the licence change? It is better from costs and
| freedom perspective forking open-source version of your product
| and using it for free like Amazon did with Elasticsearch.
|
| - The license change leads to user base fragmentation - some of
| your users switch to forks run by cloud companies. Others start
| searching for alternative open-source products. So, you start
| losing users and market share after the license change.
|
| - The license change doesn't bring you new beefy enterprise
| contracts, since it doesn't include any incentives for your users
| to sign such contracts.
|
| That's why we at VictoriaMetrics aren't going to change the
| Apache2 license for our products. Our main goal is to provide
| good products to users, and to help users use these products in
| the most efficient way. https://docs.victoriametrics.com/goals/
| chrsig wrote:
| I hope you can appreciate that the problem here is that the
| proposition that you "aren't going to change" is entirely
| unfalsifiable, reliant on trust, and that the individuals
| making the proposition are in a position to enforce it ad
| infinitum.
|
| Consider me skeptical.
| valyala wrote:
| I tried providing good reasons why changing the license from
| truly open source to some source-available license has little
| sense from business perspective. Of course, something may
| change in the future, which could force us reconsider the
| decision on sticking with Apache2 license. But currently I
| don't see any reasons to change the license. And I'm sure
| there will no be such reasons in the next 10 years.
|
| P.S. IMHO, the main reason to change the license at
| CocroachDB, Redis, Elasticsearch, MongoDB, TimescaleDB,
| Grafana and other products is weak revenue growth rate.
| Shareholders falsely think that the license change may help
| increasing the revenue growth rate, but I don't understand
| why...
| 999900000999 wrote:
| What if AWS launches AWS Metrics which just takes your code and
| hosts it.
|
| You can't out compete Amazon here. I vastly prefer to use MIT
| or Apache code for my projects. It just makes things easier,
| but I also respect companies like yours have a right to seek a
| profit.
| valyala wrote:
| If Amazon will make a product on top of open-source
| VictoriaMetrics, then we'll say thanks to Amazon, since this
| is great marketing - more people will be aware of great
| products provided by VictoriaMetrics!
|
| There is close to zero probability that Amazon will pay us
| for this product, so there is no any sense in changing the
| license from Apache2 to some BSL-like license, since they
| never sign long-term contracts with open-source product
| vendors.
| 999900000999 wrote:
| But if I could just go to Amazon directly,presumably they'd
| offer support, how do I give you money.
|
| I just don't understand how for-profit company can develop
| true open source software. You can have a non profit
| foundation and a for profit support studio. Godot
| effectively does this.
|
| Plus if you've taken VC money you can always get voted out
| in a few years. Or just have a nice exit. I wouldn't be mad
| at anyone for taking a large payday and retiring. But then
| the for profit company is free to change the license.
|
| It feels more straightforward to use a proprietary or copy
| left license from the start. Your company exists to make
| money, and I think most of us can respect that. We just
| don't want to start building our projects off of open
| source software, that converts to some other license years
| down the road.
| valyala wrote:
| If you go to Amazon directly, this is great - you
| continue using our products and recommending them to your
| friends. Probably, next time you'll become our customer.
| For example, if you aren't satisfied with the support
| from Amazon, or there are some missing features at
| Amazon, or if you just switch department or company.
|
| We develop open source products, we are profitable and we
| have good revenue growth rate. We make money mostly on
| high-quality enterprise technical support for our open-
| source products. Some of our products have enterprise-
| only features [1], but most of our paid customers
| continue using open-source versions of VictoriaMetrics
| products.
|
| [1] https://docs.victoriametrics.com/enterprise/
| Havoc wrote:
| Are any of the databases certain (as certain as one can be) to
| stay open?
| nijave wrote:
| MySQL/Perconna/MariaDB has a pretty community with three
| different, large entities supporting it. At least there's some
| redundancy if one decides to change course
|
| Postgres also has some separate large entities supporting it
| but it rolls up to the same codebase
___________________________________________________________________
(page generated 2024-08-16 23:02 UTC)