While we are at it, what about an explicit mention of the four freedoms in the OSD introduction?
3 Likes
This is a great idea and one @gvlx and I discussed this week (I initially thought he might have suggested it) ā apparently thereās a version in free software circles they refer to as the 4 Fās and 10 Pās. Did you have preferred wording we can add?
Hi Cora, and welcome! 
Do you have a specific patch to suggest?
Open source doesnāt just mean access to the source code, but granting users the freedom to study, use, modify and share the program.
3 Likes
Added to the WIP, linked back to this thread, and tagged āwipā.
2 Likes
Hi everyone.
Let me start by saying that all the work here must be anchored the Four Freedoms.
So it is extremely important they are exposed so that the first thing anyone sees when entering the website by the first time (the so called āabove the foldā message).
I know the website name and domain are meant to explain the OSD but that only exists as a clarification on the Four Freedoms (which have their own clarification in the link above).
Keep on sharing! 
Hi @sam,
Iām afraid Iāve been using this term myself but I realize now that itās already heavily overloaded semantically so it is better to stop using it.
And itās even worse with the other.
don't look here
The first rule of referencing the urban dictionary is to never link to itā¦
1 Like
I propose that going forward we refer to them as the more inclusive/less elitist ā4 Freedoms + 10 Principlesā then, and incorporate them into the document itself. The only modification I would make to @coraās suggested wording is that they be spelled out as bullet points, which may or may not be something we can bring in from the Free Software Definition:
A program is free software if the programās users have the four essential freedoms:
- The freedom to run the program as you wish, for any purpose (freedom 0).
- The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
- The freedom to redistribute copies so you can help others (freedom 2).
- The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
Or alternatively, the OSAID drafts:
An Open Source AI is an AI system made available under terms and in a way that grant the freedoms to:
- Use the system for any purpose and without having to ask for permission.
- Study how the system works and inspect its components.
- Modify the system for any purpose, including to change its output.
- Share the system for others to use with or without modifications, for any purpose.
Or, more likely, something tailored to the needs of the document. For example, weāve seen the freedom to modify being interpreted as the freedom to make any modification (i.e., fine-tuning) rather than all modifications. The FSD touches on this issue, but the modifiers āfor any purposeā, āwithout having to ask for permissionā, and possibly others apply to all four points, not just the last one:
Whether a change constitutes an improvement is a subjective matter. If your right to modify a program is limited, in substance, to changes that someone else considers an improvement, that program is not free.
I have included the explanatory sentence because I believe it is critical. I had until recently thought of this omission as another deliberate layer of abstraction, with the principles implementing in an abstract way the freedoms, which is then made concrete by the licenses which are applied to the software:
Four Freedoms 
Open Source Definition License Software
While the license (perhaps better termed instrument given recent discussions and the apparent need for frameworks like an updated MOF, and the use of Terms of Service in lieu of a license) layer of indirection is a critical part of the landscape as it allows anyone to apply and obtain Open Source status without having to ask for permission from any authority, the freedoms & principles could and arguably should be tightly coupled.
Furthermore, it should be done in such a way that the freedoms are the foundation and take priority over the principles which implement them. This should protect against future weakening of the principles, but as weāve seen with the OSAID (which references the freedoms but does not fully protect them), this point needs to be explicit to provide any safety. IANAL and this likely eventually needs one.
3 Likes
Well said, your flow follows the best practices of establishing and steering a principled organization.
Mission Purpose Process Action
4 Likes
Not sure: the whole OSD is already a numbered list and a set of bullet points inside the intro would look a bit messy. Also it would be a much larger patch, so much some would argue that the document is not OSD anymore.
While it would be funny and mind-blowing, Iām not sure we could define āopen sourceā from scratch without unintended side effects. Itās not impossible, but would require a huge consensus among developers.
The problem with that list is that it mention in the same point the freedom to study and the freedom to modify. While the Italian translation is crystal-clear, this is unfortunate in English, because a superficial reading might miss the comma: freedom 1 is not the āfreedom to study how the program works and change itā, but the āfreedom to study how the program works, and change itā.
That comma in English means that you should be free to study how the program works even if you do not plan to modify it. But people who canāt read carefully end up claiming that the freedom to study is a second class citizen in free and open source software.
Ironically, thatās a bit better, but again gain, the freedom to study is being watered down: why just āinspectā the systemās components? I want the freedom to study each of them as well!
Any competent and relevant input is certainly welcome, but note that a definition is not a license: it is descriptive, not prescriptive.
The OSD is first and foremost a social contract among the software creators (developers, artists, data scientists and so onā¦) who share their time and highly valuable skills through the software.
As such, itās up to software creators to decide its values, goals and principles.
OSI didnāt understand this simple fact, didnāt listen to practitioners, and built OSAID that ignore their needs while pretending to grant the four freedoms.
Iām sure it was not intentional: detached from their base, they entered an echo chamber with too few developers and too many corporate representatives.
Letās try as hard as possible to not repeat their error here.
1 Like
If less is more,
Open source doesnāt just mean access to the source code, but granting users the freedom to study, use, modify, and share the program, for any purpose and without having to ask for permission.
1 Like
Hmm. I donāt want to derail this thread, but I think it may also be time to rethink the four freedoms.
Freedoms are without obligations. It may be time to bring mutual responsibility into the picture that is currently missing.
1 Like
Hi @jfinkhaeuser, feel free to open a new thread with an actual proposal change and let see if it gain consensus.
1 Like
This is the type of question that would have been a better fit for the OSAIDās āco-designā process, as itās getting to what is actually expected and required of Open Source. Instead, it was applied to the technical question of what specific components would actually be required to protect the four freedoms, and in what form, and at that it failed.
I think most of the discussions on this topic would probably go in the direction of demanding more, for example, in the area of patents. Iām personally not convinced thatās helpful as the low bar, as licenses like Apache 2.0 can always raise the bar in those dimensions (and indeed, have).
Obligations are an interesting idea that you should float in a separate thread, to @giacomoās point. Currently we have warranty & liability waivers, basically saying do what you want with this but donāt complain when it kills your dog. I again think itās probably something best reserved for licenses that choose to go beyond the basics, but maybe thatās just me.
Everyone is entitled to their opinions, of course, which is why I am raising it to be discussed, and have indeed opened another thread on that topic.
An interesting and under-appreciated aspect of the OSAIDās inclusion of the checklist is that they appear to be setting themselves up as the gatekeeper and eliminating the safety of a layer of indirection that would support such special interests @jfinkhaeuser.
Currently we have self-service licenses covering the spectrum of needs that meet a common minimum standard, but rather than certifying e.g. Linux Foundationās MOF Class I (which wouldnāt be Open Source under the Open Source Definition, suggesting thereās a need for a Class 0 which does), the OSI decided to release their own checklist.
The OSI establishing itself as the certification authority for Open Source AI would be good for its growing budget, but incredibly damaging for the industry, a point @giacomo already raised during the process:
- OSI as a single point of failure: since each new version of each candidate Open Source AI system world wide should undergo to the certification process again, this would turn OSI to a vulnerable bottleneck in AI development, that would be the target of unprecedented lobbying from the industry.
2 Likes
Certifications are an inevitable component to regulating AI. It sounds their perverse incentive to attract corporate support to grow their budget is stronger than whatever duty they have to protect open source standards.