- We offer a private PyPI server to release early security fixes and features.
Don't they rely on the entire PyPI community to offer their product? Holding security fixes back in exchange for money doesn't look fair to me from this perspective.
It's for 1-day attacks I'd imagine. Especially for python, once the patch is public threat actors can abuse it but they can embargo the cve and offer private patches for commercial customers early to avoid that scenario.
Or to avoid legal uncertainty. The bigger the company, the more willing they are to pay $1000 a year to not have to track a potential risk, no matter how small that risk is. And another $1000 for paying by invoice, so the accounting department is happy.
It may also be a way to make financially supporting a project easier for users in corp environments -- it can be easier to get an expense through for a $1k software license than a $100 donation to an open source project or individual author.
Right, shouldn't it be GPL? BSD can be used in commercial products.
And even if the licensing of this project holds up as the author intends: If I make an Open Source project based on this, and someone else uses that in a commercial product, it would be 100% legal according to the BSD license.
The commercial license comes with some added functionality, and support. I suspect the "for open source projects" and "for commercial software" labels aren't meant as restrictions (i.e., "Only these kinds of projects can use this license") but rather as suggestions ("If you have this kind of project, you'll probably want to use this license"). Though as it stands, it's definitely ambiguous, which is the last thing anyone wants from their licensing agreement.
I could create a fork that differs only in name and maybe changes one or two default settings. See also: Chromium forks that disable telemetry and nothing else.
Don't some organizations want a business relationship for one reason or another?
From looking at the plans, the value is mostly in support for the commercial license, which is a pretty common approach. I think the wording is the only part that is odd, although it may be an intention nudge.
Also, based on a blurb from their sponsorship page, it appears they give security patches to commercial license holders before the public. https://github.com/sponsors/lepture
If the closed source project redistributes the BSD project, then it must comply with its license:
Redistribution and use in source and binary forms [...] are permitted [...] provided that the following conditions are met:
[...]
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
[...]
This makes it a non-starter for a lot of teams I think, in large enterprises it can be difficult to keep track of licenses like this, especially if you have situations like open core but commercial tiers and whatnot.
The project is clearly licensed under the BSD License. See the LICENSE file and the in-file comments below. You can't both license under the standard BSD License and carve out commercial usage.
"""
authlib
~~~~~~~
The ultimate Python library in building OAuth 1.0, OAuth 2.0 and OpenID
Connect clients and providers. It covers from low level specification
implementation to high level framework integrations.
:copyright: (c) 2017 by Hsiaoming Yang.
:license: BSD, see LICENSE for more details.
Do we really need to reimplement and use OAuth anymore? I don't know any service that still uses OAuth last I checked, usually everything is just API keys.
Besides, for any new project I just go for Auth0 these days, that's just me.
Your experience is not necessarily others': IME, OAuth is widely adopted, and OIDC is rapidly gaining traction. GitHub Actions, for example, offers ephemeral identity credentials through OIDC.
Allowing users to register to your app using another service (e.g. Facebook, Spotify, Google) requires OAuth. That’s what I use authlib for, anyways. It simplifies the OAuth process so much that I don’t have to think about the authentication process when designing an app.
I was just at a developer conference and was amazed at how many people used Auth0 and OAuth interchangeably. They've done a super job of capturing mindshare, and have a great brand.
Full disclosure, I work for an auth server vendor.
So there are three primary use cases for OAuth (I'll include OIDC as well, as they are often paired and OIDC is built on top of OAuth).
* Authentication. Using OIDC for authentication lets you use one of many authentication servers (FusionAuth [my employer], Keycloak, Python OAuthlib, Django with https://django-oidc-provider.readthedocs.io/en/latest/ Auth0, Cognito, etc etc). Using such an identity server lets you have one single place to store user data. It's normalizing user data, which has the same benefits and tradeoffs as normalizing any other kind of data.
* First party API authentication (where the same org controls both the end client and the API server). This is comparable to API keys, but has some differences. Setup is more complicated, but you have credentials that are automatically time bound (tokens expire), support multiple useful flows, and have a refresh mechanism built in. Plenty of security experts have banged on OIDC/OAuth and helped fix issues, and j random developer you just hired is probably more familiar with OAuth than your custom API key scheme. You also have the ability to put more data in the token (if you use JWTs) and have the tokens verified without contacting a central server. This can lead to some nice scaling properties.
* Third party API access. When you are the client and want access to third party APIs, you have to use what the API dictates. That is often either OAuth or API keys. OAuth here has a lot of flavors. See this article which was on HN a month or two ago: https://www.nango.dev/blog/why-is-oauth-still-hard
Source: I work for FusionAuth, an auth provider which supports OAuth and OIDC, and help support users and customers implementing FusionAuth.
OAuth (OIDC) still makes a lot of sense in some scenarios. I work at a university and I just used Authlib a few months ago to consume our single sign-on, and let me tell you, that was much easier than using the API would have been.
Can you use Auth0 in your own , Airgapped intranet?
Can you use Auth0 without exposing your user information to Auth0 providers?
Can you modify source code of Auth0 for your customizaiton needs?
- This plan is for commercial projects.
- License: Commercial License
- security maillist
- quick responses
- private PyPI
- commercial support
- making Authlib sustainable
then:
- We offer a private PyPI server to release early security fixes and features.
Don't they rely on the entire PyPI community to offer their product? Holding security fixes back in exchange for money doesn't look fair to me from this perspective.