41–50 of 60 posts
Worth mentioning: https://docs.nango.dev/nango-deploy/oss-limitations To keep the setup of the Nango open source version simple we have made some choices that may not be ideal for production. Please take them into consideration before using it in production: The database is bundled in the docker container with transient storage. This means that updating the Docker image causes configs/credentials loss. We recommend t…
Worth mentioning: https://docs.nango.dev/nango-deploy/oss-limitations To keep the setup of the Nango open source version simple we have made some choices that may not be ideal for production. Please take them into consideration before using it in production: The database is bundled in the docker container with transient storage. This means that updating the Docker image causes configs/credentials loss. We recommend t…
LOL. Advertising something as a security product and doing this is absolutely ridiculous.
Worth mentioning: https://docs.nango.dev/nango-deploy/oss-limitations To keep the setup of the Nango open source version simple we have made some choices that may not be ideal for production. Please take them into consideration before using it in production: The database is bundled in the docker container with transient storage. This means that updating the Docker image causes configs/credentials loss. We recommend t…
> Credentials are not encrypted at rest and stored in plain text LOL. Advertising something as a security product and doing this is absolutely ridiculous.
However, it seems reasonable to infer they are referring to storage in the DB itself. How would you suggest they encrypt it securely at rest for an out-of-the-box "setup and go" scenario?
I will note that a lot of the existing "plugin" OAuth type providers for popular web frameworks don't encrypt user tokens in the DB by default either.
It's not under an OSI-approved license. https://github.com/NangoHQ/nango/blob/master/LICENSE
fine but it only restricts aws type users, the rest have no trouble using it?
Edit; come to think of it; make it a ‘contribute GPL3 or MIT license’ (not sure if something like it exists); you can use it for anything, however, if you offer it as a hosted product to your clients (aws etc), you must contribute x.y% of your staff FTE to it. GitHub/Gitlab can do the KYC per employee for which the company has to pay.
It's not under an OSI-approved license. https://github.com/NangoHQ/nango/blob/master/LICENSE
OSI doesn't own the term "open source" [0] [1] [0]: https://writing.kemitchell.com/2019/05/05/Rely-on-OSI.html [1]: https://writing.kemitchell.com/2021/03/18/You-Can-Still-Use-...
Language is useful.
Earlier quoted context omitted.
fine but it only restricts aws type users, the rest have no trouble using it?
I cannot add it into my hosted product as a small company (I am not Amazon) either. Imagine I have a tiny niche product that needs this; the trouble is that it could as well not be open source as I am not allowed to use include it anyway. I understand not wanting aws type of users, but why not just name them instead? Just include a clause; ‘the following companies cannot use this software unless they contribute to it…
that is a big difference
Earlier quoted context omitted.
I cannot add it into my hosted product as a small company (I am not Amazon) either. Imagine I have a tiny niche product that needs this; the trouble is that it could as well not be open source as I am not allowed to use include it anyway. I understand not wanting aws type of users, but why not just name them instead? Just include a clause; ‘the following companies cannot use this software unless they contribute to it…
no no no.... my understanding is if you are using it in house for a product, you are fine but you cannot offer it as a hosted service to your customers. read "aws offers managed DB" you cannot do that but you should be able to use this in your "cat picture search engine that uses this DB hosted inhouse". that is a big difference
You are right about in-house, but the lawyers won’t care so much becuase ‘in house’ is not so clear. In house cannot include clients or partners using it? They pay and we host so seems to violate. Pretty useless for most businesses. And it’s not dual licensed, so I cannot contribute or pay to change this outcome. For me, it’s just the same as a closed source saas product. That’s fine, I just find it strange that people would let Amazon etc bully people into crap licenses while they could just use MIT-but-not-for-Amazon.
Earlier quoted context omitted.
> Credentials are not encrypted at rest and stored in plain text LOL. Advertising something as a security product and doing this is absolutely ridiculous.
Well, you _could_ encrypt the tokens but you can't hash them like a password so they have to be stored in some format in their entirety. However, it seems reasonable to infer they are referring to storage in the DB itself. How would you suggest they encrypt it securely at rest for an out-of-the-box "setup and go" scenario? I will note that a lot of the existing "plugin" OAuth type providers for popular web frameworks…
Interesting point on existing providers not encrypting user tokens in the DB by default tho - wouldn't expect that hmmm
Earlier quoted context omitted.
no no no.... my understanding is if you are using it in house for a product, you are fine but you cannot offer it as a hosted service to your customers. read "aws offers managed DB" you cannot do that but you should be able to use this in your "cat picture search engine that uses this DB hosted inhouse". that is a big difference
As far as I understand the elastic license I cannot create a SAAS product that includes this and then create a company selling that saas product to 1000s of paying clients (again; not the size of evil Amazon but a not that successful, lifestyle b2b saas business). It’s a crippling license that goes against many of the modern ideas of oss and only becuase Amazon abused it. So name and shame but don’t punish the rest.…
but that the problem. There cannot be MIT-but-not-for-Amazon. MIT is a do whatever you want license.
The problem of 4 freedoms is restricted in MIT, that is why GPL exists. SSPL or this license extends that to exclude AWS.
You are right, they could just exclude AWS but you cannot build a license around specific people or names, aws could just change their name and avoid that.
If you were writing the license, how would you rewrite this offending line to exclude only AWS like businesses?
> It’s a crippling license that goes against many of the modern ideas of oss
yes. this goes against MIT because that assumes AWS or the mom and pop store can use your work without contributing back and use your open source code to build a closed source software.
the entire premise of 4 freedoms is that the freedom of seeing/editing code made by author is given to the ultimate end user. MIT goes against that so there is that.
again, how would you rewrite that line to exclude SAAS providers who just leech off of open source projects for their own gain?