Hacker News Reader

Comment by bionhoward | Hacker News Reader

Damn this looks cool but it’s got a customer noncompete, “you will not (and will not enable others to) use the AI Features: (e) for the development of any service or other offering that competes with or replicates the Services.”

That’s real bad since they also write “ Memex may generate aggregate, deidentified data from your use of the Services and Subscriber Data ("Usage Data") and use it to operate, improve and support the Services”

AKA “we can learn from your codebase and you aren’t allowed to compete with us”

Basically, it’s a brain-rape machine for idiots who don’t read the fine print. Sad

View on HN

HN Community: We had this clause in our Terms and Conditions: "you will not (and will not enable others to) use the AI Features: (e) for the development of any service or other offering that competes with or replicates the Services.”

That clause was boilerplate our lawyers included, and it doesn't reflect how we operate or what we intend to enforce. I should have caught it, but I missed it.

The terms and conditions are now updated to not include a anti-competition clause.

thanks for calling this out

To be 100% clear: we do not prevent anyone from using Memex to build a Memex competitor. That clause was boilerplate our lawyers included, and it doesn't reflect how we operate or what we intend to enforce. I should have caught it and we'll fix it.

On the Usage Data side, your code is never stored anywhere other than your machine when you use Memex. And you can enable "Privacy mode" to not have your prompts stored either.

> I should have caught it and we'll fix it.

That's a great reply and hoping for it to give memex a try, not that i want to give a competitor but I can use and give back to OpenAIs codex codebase because its MIT, it would suck to use an app you cannot modify for your own pleasure or build your own specific itching solving version of, most so as a tool for builders

That's fair. We do plan to open source components of Memex to allow for extensibility while also having a strong enough revenue model to build without being fully dependent on VCs

I can respect that, maybe just an sdk and plugin architecture or hooks is fine too.

will check memex out and give any concrete feedback on that regards if i have it

thanks!

> On the Usage Data side, your code is never stored anywhere other than your machine when you use Memex. And you can enable "Privacy mode" to not have your prompts stored either.

It would be nice if there's some kind of auto-censoring of secrets if sharing code etc, cursor handling of this is very bad bc if I block .env files, then i can't never add them as context and it thinks they dont exist, instaed of knowing they're secrets and to be treated as such.

hoping a less binary solution for controlling what gets shared and not is possibe

That's a good feature idea and something we've considered but not gotten around to yet.

We do have a secrets mgmt feature that uses keyring, so you can store secrets through the app in your system keychain, which then requires your approval before Memex uses it.

We're hoping to make that feature easier to use with MCP

Reply on news.ycombinator.com