Open Source Initiative Blog

I don't think SSPL is worse than AGPL in practice, in fact it is better. The SSPL is effectively a stronger AGPL. This makes it non-OSI-approved, but the licence itself is completely fine. The major difference is that the SSPL also mandates that you release everything needed to run the software, not just the software itself. For reference, it's worth to read the OSI's blogpost about this, it's quite illuminating: https://blog.opensource.org/the-sspl-is-not-an-open-source-license/ It's also worth mentioning that most of the attacks against the GPL, AGPL and SSPL are done by corporate shills, and OSI is also full of them. They pretend to support "non-discrimination of fields of endeavour" but they are undermining free software to SaaS-ify it. Don't fall for the "SSPL is not open source" propaganda.

Basically under the actual terms of what open source is there can be no limits to particular users. Meta, in order to protect their competitive market share has said explicitly in Paragraph Two of their licensing terms --- " If, on the Llama 2 version release date, the monthly active users of the products or services made available by or for Licensee, or Licensee’s affiliates, is greater than 700 million monthly active users in the preceding calendar month, you must request a license from Meta, which Meta may grant to you in its sole discretion. -- Doing so, technically, takes the license out of the category of “Open Source.” Sources: Open Source Initiate Argument https://blog.opensource.org/metas-llama-2-license-is-not-open-source/ Llama Terms https://ai.meta.com/resources/models-and-libraries/llama-downloads/

This has been a long way coming and is, in my opinion, a important step in the professionalization of software development. This article seems to refer to the Cyber Resilience Act but doesn't really explain the problem many[1] open source communities seem to have with the current draft. The CRA actually attempts to exempt open-source software by exempting non-commercial software contributions from its rules. "Commercial Activity" however includes more activities than some open-source developers would like. Any kind of regular income related to the project might fulfill the requirements to count as commercial activity. I recommend the linuxfoundations article[2] for a more comprehensive understanding of the proposed rules. [1] https://blog.opensource.org/the-ultimate-list-of-reactions-to-the-cybe… [2] https://www.linuxfoundation.org/blog/understanding-the-cyber-resilienc…

There is a lot of interesting discussion already, but I think there is also some (perhaps unnecessary) disagreements regarding licensing arising from what I believe are the very different backgrounds in the community. Thus, I will attempt to summarise my own perspective as someone that has been active in the artificial intelligence community for nearly 15 years at this point. Firstly, I will state that I am in full agreement with LeCun on what he states in the video about the need for AI systems such as LLMs to be open [1]. I am not sure if I entirely agree with his very high optimism regarding AI safety, but I have always been far more concerned about current risks and I suspect that in practice we are very much aligned. [1]: https://yewtu.be/watch?v=EGDG3hgPNp8&t=6525s Now, let me move to the issue of licensing that I have already talked about at great length in comments on other, older submissions. So let me do something new here and try to put it into a historical context. Computer science and machine learning in particular has a tradition of openness that goes beyond that of many other fields. What I mean by this is that over the last twenty or so years, there has been a gradual move towards open sharing of research, research outcomes, etc. All under the umbrella of open science and FLOSS. One of the earliest examples I am aware of (there may be others) is how the Journal of Machine Learning Research was established as a direct reaction to the resistance against…

It’s been a while since FerretDB (well, we were called MangoDB back then) was first posted on HN. Back then, it was nothing but a tech demo - today, FerretDB is being used in production. We’ve received a lot of great feedback on HN, which we used to set the direction of our project. So it’s only natural that we want to show HN what we used your input for. Please give it a try and let us know how it went. Read more about the new release in our blog post.[1] As a recap, FerretDB is an open source alternative to MongoDB. We started building it because we believe that there should be an OSS alternative to MongoDB, as they changed over to the proprietary and controversial SSPL license [2]. We built it on Postgres, because we believe that Postgres as a backend is more than capable of playing the part. FerretDB is written in Go; it also can be used as a Go library. We started adding support for SQLite as well, as there is a lot of interest in it. Our long-term goal is to create an open standard for document databases, similarly to how SQL is a standard for interfacing with RDBMS. [1]: https://blog.ferretdb.io/ferretdb-1-0-ga-opensource-mongodb-alternativ… [2]: https://blog.opensource.org/the-sspl-is-not-an-open-source-license/

Some potentially useful advice below. Remember to apply it to all the software you use, including operating systems on local machines, company infrastructure, things you deploy in the cloud etc. Possibly your team has added workarounds and technical debt to your codebase for issues in your dependencies, that is probably a good place for them to start. It is also nice to give back to projects by working on "papercuts"; things that are easy to fix but annoy lots of people (Ubuntu did this for eg). Working on bigger stuff is good too, like fixing all crashes or adding important features from the roadmap etc. https://ubuntu.com/blog/tag/papercuts https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Mission Some companies have a "20% time (or X hours) on open source" policy, which is great for the sort of issues mentioned above. Some open source projects have a list of ways companies can support them with resources (like sponsorship, download mirrors etc), for example here is the one for Debian: https://www.debian.org/intro/help#organizations It is a good idea to reword your employee contracts to mention the company policy on open source and give employees copyright over their contributions to open source projects. Some projects like Samba do not allow corporate copyright ownership. For other open source projects, having a diverse copyright holder base of individuals and a broad contributor community helps protect projects (at least those that are copyleft) from license and…

Mongo and Elastic have changed there licenses to the "service-side public license" (SSPL) which is a particular own flavor of AGPL. The OSI has stated that this isn't an open source license. [1] Barring a discussion about whether or not a license is "open source", what matters is that these businesses asserted that commonly used licenses - (A)GPL, Apache, MIT,... - are leaving ample room for competitors to setup their own managed / hosted services and compete with them through scale (e.g. Amazon's Open Search offering undercutting ElasticSearch). [1] https://blog.opensource.org/the-sspl-is-not-an-open-source-license/

Yes, but these licenses have far more protection for me than regular licenses. I'm working with a lawyer to ensure that these licenses are void if the user expects me to have any duty, like the Bitcoin lawsuits ([1], see comments at [2]) or the EU's upcoming Cybersecurity Resilience Act that might require me to be audited or worse [3], which I can't afford. (I do want an audit when I can afford it, though.) [1]: https://laanwj.github.io/2023/02/06/regrets.html [2]: https://news.ycombinator.com/item?id=34684715 [3]: https://blog.opensource.org/what-is-the-cyber-resilience-act-and-why-i…

That will lead to even more confusion in the minds of the hundreds of policy makers and courts worldwide, who already have plenty of opportunities to be confused. More: https://blog.opensource.org/court-affirms-its-false-advertising-to-cla… Use other terms, there are plenty of other options

True. That gives these companies a little less than two months to start contributing, with the easier license restrictions in mind. But, Llama 2 is not open source [1]. [1] https://blog.opensource.org/metas-llama-2-license-is-not-open-source/

That article is obfuscating why the license was going to be rejected by the OSI. The OSI has as part of their definition of open-source that there can be no field of use discriminators. It had nothing to do with the fact that it was drafted by a commercial company. OSI has approved plenty of licenses drafted by for-profit companies (e.g. Intel, IBM, Microsoft.) https://blog.opensource.org/the-sspl-is-not-an-open-source-license/ https://opensource.org/osd/

TL;DR The EU is working on the Cyber Resilience Act (CRA) which will be voted on the 19th of July. The current wording makes it look like it will affect open source projects that receice donations; which have contribution from corporate developers; and might break coordinated vulnerability disclousure. If you live in the EC area, there's a link on the blog to contact to MEP. The blog also links to other posts from OSS organisations sharing the same concer. * https://blogs.eclipse.org/post/mike-milinkovich/european-cyber-resilie… * https://pyfound.blogspot.com/2023/04/the-eus-proposed-cra-law-may-have… * https://blog.opensource.org/the-ultimate-list-of-reactions-to-the-cybe…

MongoDB’s SSPL is neither an open source license[1] nor, most likely, a free software one[2]. Its definition of offering the licensed software as a service is so broad most Linux distributions[3–6] flat out refuse to ship MongoDB (not even in a nonfree repository or the equivalent) so as to (among other things) avoid placing the operators of their package mirrors in legal jeopardy. [1] https://blog.opensource.org/the-sspl-is-not-an-open-source-license/ [2] https://opensource.stackexchange.com/q/13888 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915537 [4] https://fedoraproject.org/wiki/Changes/MongoDB_Removal [5] https://bugzilla.opensuse.org/show_bug.cgi?id=1122267 [6] https://lists.archlinux.org/archives/list/[email protected]…

I have already stored some links about this act. As it is written in the register "The road to hell is paved with good intentions". https://www.internetsociety.org/blog/2022/10/the-eus-proposed-cyber-re… https://blog.nlnetlabs.nl/open-source-software-vs-the-cyber-resilience… https://blog.opensource.org/what-is-the-cyber-resilience-act-and-why-i… https://devclass.com/2023/01/24/eus-proposed-ce-mark-for-software-coul… https://berthub.eu/articles/posts/eu-cra-secure-coding-solution/ https://www.theregister.com/2023/05/12/eu_cyber_resilience_act/