Cal.com 因 AI 从开源转为闭源

2026-04-16 14:21 by 永生粮

日程安排平台 Cal.com 宣布从开源转为闭源，理由是 AI 工具更容易从开源代码中发现漏洞，而安全性依赖于模糊，因此闭源有助于提高安全。Cal 联合创始人 Peer Richelsen 称 AI 攻击者正在利用开源项目的透明特性，CEO Bailey Pumfleet 说，开源就好比银行公开其金库的图纸，在 AI 工具的帮助下研究图纸的黑客数量增加了百倍。Cal.com 表示会继续支持开源，将为爱好者提供一个独立的开源版本 Cal.diy。该公司核心产品则将从开源许可证 GNU Affero General Public License(AGPL)切换到闭源许可证。Pumfleet 表示，他们不希望因为漏洞而暴露客户敏感的订购数据，他们旨在成为一家日程安排公司，而不是一家网络安全公司。

https://cal.com/blog/cal-com-goes-closed-source-why
https://yro.slashdot.org/story/26/04/15/1913213/calcom-is-going-closed-source-because-of-ai

#开源

经Project Trans制作委员会批准，出于友好原则，我们决定对法人实体[数据删除]（淘宝店铺「凌叁秋实验室」[1]及其他平台同名店铺）追加授予商业使用本组织VI设计[2]进行实体商品制作的授权。

1. 该法人实体与Project Trans无除此授权合作外的任何商业关系、隶属关系和其他合作关系。
2. Project Trans未从此授权合作中获得任何经济报酬。
3. 该法人实体须在任何售卖包含Project Trans设计的商品时明确声明以上两点。

我们也欢迎其他从事跨性别与性别多元文化产品的伙伴向我们申请相关授权。

1. https://shop488468554.taobao.com
2. https://github.com/project-trans/artworks

OpenJDK Interim Policy on Generative AI
OpenJDK关于生成式人工智能的临时政策
Contributions in the OpenJDK Community must not include content generated, in part or in full, by large language models, diffusion models, or similar deep-learning systems. Content, in this context, includes but is not limited to source code, text, and images in OpenJDK Git repositories, GitHub pull requests, e-mail messages, wiki pages, and JBS issues.
OpenJDK 社区的贡献不得包含由大型语言模型、扩散模型或类似深度学习系统生成的全部或部分内容。此处的内容包括但不限于 OpenJDK Git 仓库、GitHub 拉取请求、电子邮件、Wiki 页面和 JBS 问题中的源代码、文本和图像。

Contributors in the OpenJDK Community may use generative AI tools privately to help comprehend, debug, and review OpenJDK code and other content, and to do research related to OpenJDK Projects, so long as they do not contribute content generated by such tools.
OpenJDK 社区的贡献者可以私下使用生成式 AI 工具来帮助理解、调试和审查 OpenJDK 代码及其他内容，并进行与 OpenJDK 项目相关的研究，但前提是他们不得贡献由此类工具生成的内容。

https://openjdk.org/legal/ai

喜报：Component "archive.ubuntu.com" and a few other components are Down
http://status.canonical.com

IETF 发布 meow 草案

互联网工程任务组（IETF）发布了 meow（meow）草案。该协议喵喵喵喵喵喵喵喵喵，喵喵喵喵喵喵喵喵喵，喵喵喵喵喵喵喵喵喵喵喵，喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵。喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵，喵喵喵喵喵喵喵喵喵喵喵喵喵，喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵。

喵喵喵喵喵喵喵喵喵喵喵喵，喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵，喵喵喵喵喵喵喵、喵喵喵喵喵喵喵喵喵喵喵喵喵。此外，喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵，喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵。喵喵喵喵喵喵喵喵喵喵喵喵，通过喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵。

IETF

ISC.org (@iscdotorg@fosstodon.org)

I just posted a blog, it is 100% nicer and more restrained than our development team would have posted. Read between the lines, people.... ;-)

https://www.isc.org/blogs/2026-04-16-How-to-report-a-vulnerability/


https://fosstodon.org/@iscdotorg/116416426577631380

NLnet Labs (@nlnetlabs@social.nlnetlabs.nl)

In case you’re wondering: while not as extreme as illustrated by ISC (we don’t offer a bug bounty program), NLnet Labs suffers from a similar situation, in particular for Unbound.

Handling vulnerability reports, both valid ones and false positives, has now become a full time job for the entire Unbound team.

You can argue that it ultimately makes our resolver more secure, it also means we cannot work on building and releasing new features, like:

https://github.com/NLnetLabs/unbound/pulls/wcawijngaards

https://social.nlnetlabs.nl/@nlnetlabs/116418470657329812