Meta: Обвинения в "изпиране" на отворен код

Meta, технологичният гигант, отново е в центъра на критики, този път заради обвинения в “изпиране” на отворен код (open washing). Противоречието произтича от спонсорството на Meta за изследователска статия на Linux Foundation, която разглежда разширяващия се пейзаж от AI решения с отворен код (open-source). Същността на проблема е в убеждението, че Meta използва това спонсорство, за да промотира своите Llama AI модели, като същевременно заобикаля истинската дефиниция за “отворен код”.

Изследването на Linux Foundation: Двуостър меч

Изследването на Linux Foundation, публикувано по-рано този месец, защитава предимствата на AI системи с отворен код, подчертавайки тяхната рентабилност за бизнеси от всякакъв мащаб, особено малки предприятия. Проучването предполага, че организациите, които избират AI модели със затворен код, могат да понесат разходи за софтуер три пъти и половина по-високи в сравнение с тези, които използват алтернативи с отворен код.

Това изследване е в съответствие с нарастващия брой доказателства в подкрепа на ползите от AI с отворен код. Например, проучване, проведено от IBM и Morning Consult през януари, разкри, че над половината от предприятията, използващи AI инструменти с отворен код, е по-вероятно да отчетат положителна възвръщаемост на инвестициите (ROI). Освен това, две пети от респондентите, които все още не са приели AI решения с отворен код, изразиха намерение да интегрират тези инструменти в своите AI проекти през следващата година.

Въпреки това, участието на Meta в изследването на Linux Foundation предизвика противоречия, като критиците твърдят, че то служи като тънко завоалирана маркетингова кампания за Llama AI моделите на компанията.

Дилемата “Отворен код”: Llama е под контрол

Amanda Brock, главен изпълнителен директор на OpenUK, твърди, че Llama моделите на Meta не отговарят на необходимите критерии, за да бъдат класифицирани като наистина “отворен код”. Тя посочва, че нито Meta, нито проучването признават това несъответствие.

“Llama не е "отворен код", независимо от дефиницията, която изберете”, заяви Brock. “Аз лично предпочитам дефиницията за софтуер с отворен код (OSD) от Open Source Initiative (OSI). Llama не отговаря на нейния стандарт за отворен код поради няколко причини, включително включването на търговско ограничение в лицензирането.”

Brock допълнително разясни последиците от това ограничение: “Това ограничение нарушава свободния поток, който е от централно значение за лицензирането на отворен код, и създава триене. Разчитаме на отворения код, който да бъде използваем от всеки за всяка цел, а Llama не изпълнява това изискване.”

Исканията на Meta за отворен код: Спорно издание

Гамата модели Llama на Meta е обозначена като “отворен код”, но компанията е изправена пред постоянни предизвикателства от заинтересованите страни в индустрията относно това твърдение. Основната точка на противоречие се върти около различните интерпретации на това какво наистина представлява “отворен код”.

Сърцевината на несъгласието се състои в условията за лицензиране, наложени на потребителите, след като достигнат определено ниво на комерсиализация. Въпреки че Llama моделите предлагат отворен достъп, ограничения се налагат на потребителите при определени обстоятелства.

По-рано тази година Open Source Initiative (OSI) публично критикува Meta по този въпрос, заявявайки, че компанията “продължава невярно да промотира Llama като отворен код”.

Признавайки усилията на Meta с гамата Llama като “стъпка в правилната посока” в насърчаването на осведомеността за отворен код, Brock подчертава, че е необходим значителен напредък, за да се справи ефективно с “изпирането” на отворен код в технологичната индустрия.

“Като се има предвид, че уебсайтът на Meta подчертава ключов извод от техния доклад като ‘Изследването на Linux Foundation показва как AI моделите с отворен код, като Llama, стимулират икономическия растеж, иновациите и конкуренцията, като правят ключови технологични решения по-достъпни’, едва ли е изненадващо, че OSI е разтревожена и обвинява Linux Foundation в подкрепа на изпирането на отворен код”, отбеляза Brock.

Тя допълнително подчерта по-широките последици от изпирането на отворен код, заявявайки: “Изпирането на отворен код днес не е само проблем с отворения код. Тъй като регулатори като ЕС използват термина отворен код като основа за изключения от отговорност в AI и стандартите, които трябва да бъдат изпълнени в AI, въздействието на изпирането на отворен код се превърна в обществено такова.”

Отвъд Meta: По-широка индустриална тенденция

Meta не е единственият разработчик в индустрията, попаднал в прицела на дебата за дефиницията на отворен код.

През март 2024 г. Databricks пусна свой собствен голям езиков модел, DBRX, за който експерти също твърдят, че не се придържа към стандартите за отворен код. Това се дължи на включването на външна политика за приемлива употреба и нейната работа под лиценз извън юрисдикцията на рамката на OSI. Противоречието около DBRX допълнително подчертава неяснотата и сложността около термина “отворен код” и предизвикателствата, пред които са изправени разработчиците при навигирането му в различните интерпретации. Дебатът подчертава необходимостта от по-голяма яснота и стандартизация при определянето на принципите на отворен код, особено в бързо развиващата се област на изкуствения интелект. Без универсално приета дефиниция рискът от “изпиране” на отворен код ще продължи да съществува, като потенциално подкопава доверието и целостта на движението за отворен код.

Дефиниране на отворен код: Основните принципи

За да разберем противоречията около Llama на Meta и DBRX на Databricks, е важно да се задълбочим в основните принципи, които определят софтуера с отворен код. Open Source Initiative (OSI) предоставя широко призната дефиниция, очертаваща десет ключови критерия, на които един софтуерен лиценз трябва да отговаря, за да се счита за отворен код:

1. Свободно преразпределение: Лицензът не трябва да ограничава никоя страна да продава или дава софтуера като компонент от съвкупност от софтуер, съдържащ програми от няколко различни източника. Лицензът не трябва да изисква възнаграждение или друга такса за такава продажба.
2. Изходен код: Програмата трябва да включва изходен код и трябва да позволява разпространение в изходен код, както и в компилиран вид. Когато дадена форма на продукт не се разпространява с изходен код, трябва да има добре популяризиран начин за получаване на изходния код на разумна цена за възпроизвеждане -за предпочитане изтегляне чрез интернет безплатно. Изходният код трябва да бъде предпочитаната форма, в която програмистът би модифицирал програмата. Умишлено замъглен изходен код не е разрешен. Междинни форми, като изход от препроцесор или преводач, не са разрешени.
3. Производни произведения: Лицензът трябва да позволява модификации и производни произведения и трябва да позволява те да бъдат разпространявани при същите условия като лиценза на оригиналния софтуер.
4. Цялостност на авторския изходен код: Лицензът може да ограничи изходния код от разпространение в модифицирана форма само ако лицензът позволява разпространението на “patch files” с изходния код с цел модифициране на програмата по време на компилиране. Лицензът трябва изрично да позволява разпространение на софтуер, създаден от модифициран изходен код. Лицензът може да изисква производните произведения да носят различно име или номер на версия от оригиналния софтуер.
5. Без дискриминация срещу лица или групи: Лицензът не трябва да дискриминира никое лице или група от лица.
6. Без дискриминация срещу области на дейност: Лицензът не трябва да ограничава никого да използва програмата в определена област на дейност. Например, той не може да ограничи програмата да се използва в бизнес или за генетични изследвания.
7. Разпространение на лиценза: Правата, приложени към програмата, трябва да се прилагат към всички, на които програмата е преразпределена, без необходимост от изпълнение на допълнителен лиценз от тези страни.
8. Лицензът не трябва да е специфичен за даден продукт: Правата, приложени към програмата, не трябва да зависят от това, че програмата е част от определено софтуерно разпространение. Ако програмата е извлечена от това разпространение и се използва или разпространява в рамките на условията на лиценза на програмата, всички страни, на които програмата е преразпределена, трябва да имат същите права като тези, които са предоставени във връзка с оригиналното разпространение на софтуера.
9. Лицензът не трябва да ограничава друг софтуер: Лицензът не трябва да поставя ограничения върху друг софтуер, който се разпространява заедно с лицензирания софтуер. Например, лицензът не трябва да настоява, че всички други програми, разпространявани на същия носител, трябва да бъдат софтуер с отворен код.
10. Лицензът трябва да бъде технологично неутрален: Никоя клауза от лиценза не може да се основава на отделна технология или стил на интерфейс.

Тези принципи подчертават важността на свободата, прозрачността и сътрудничеството в екосистемата с отворен код. Когато софтуерен лиценз се отклонява от тези принципи, това повдига въпроси дали софтуерът наистина може да се счита за отворен код. В случаите на Llama на Meta и DBRX на Databricks опасенията се въртят около търговските ограничения, политиките за приемлива употреба и рамките на лицензиране, които може да не са в пълно съответствие с дефиницията на OSI.

Последиците от “Изпиране” на отворен код

Практиката на “изпиране” на отворен код, при която компаниите погрешно представят своя софтуер като отворен код, когато той не отговаря напълно на критериите, може да има няколко отрицателни последици:

• Ерозия на доверието: Може да ерозира доверието в самото движение за отворен код, което да затрудни потребителите да разграничават истинските проекти с отворен код от тези, които просто се опитват да се представят за такива.
• Обезкуражаване на приноса: Може да обезкуражи приноса от програмисти, които са ангажирани с принципите на отворен код, тъй като може да почувстват, че усилията им се подкопават от компании, които не играят по същите правила.
• Правна несигурност: Може да създаде правна несигурност за потребителите, които разчитат на софтуера, тъй като може да не са сигурни за техните права и задължения съгласно лиценза.
• Забавяне на иновациите: Може да попречи на иновациите, като ограничи свободата за модифициране и преразпределение на софтуера, което е ключов двигател на иновациите в общността с отворен код.

Следователно е от съществено значение компаниите да бъдат прозрачни относно условията за лицензиране на техния софтуер и да избягват да правят подвеждащи твърдения относно неговия статус на отворен код.

Необходимостта от по-голяма яснота и стандартизация

Продължаващият дебат относно Llama на Meta и DBRX на Databricks подчертава необходимостта от по-голяма яснота и стандартизация при определянето на принципите на отворен код. Липсата на универсално приета дефиниция създава объркване и позволява на компаниите да експлоатират вратички и да се занимават с “изпиране” на отворен код.

Няколко инициативи са в ход за справяне с този проблем:

• Open Source Initiative (OSI): OSI продължава да играе решаваща роля в определянето и насърчаването на принципите на отворен код. Той предоставя широко призната дефиниция за отворен код и сертифицира лицензи, които отговарят на нейните критерии.
• Linux Foundation: Linux Foundation работи за насърчаване на сътрудничеството и иновациите в общността с отворен код. Той предоставя платформа за проекти с отворен код и е домакин на събития, които обединяват програмисти, потребители и компании.
• Европейският съюз (ЕС): ЕС все повече признава важността на отворения код и го включва в своите политики и разпоредби. Той използва термина “отворен код” като основа за изключения от отговорност в AI и стандартите, които трябва да бъдат изпълнени в AI.

Тези инициативи помагат за създаването на по-прозрачна и стандартизирана екосистема с отворен код. Въпреки това е необходимо повече работа, за да се гарантира, че принципите на отворен код са ясно дефинирани и последователно прилагани.

Напредък: Прозрачност и отчетност

За ефективна борба с “изпирането” на отворен код и насърчаване на истински отворен код е необходим многостранен подход:

• Прозрачност: Компаниите трябва да бъдат прозрачни относно условията за лицензиране на техния софтуер и да избягват да правят подвеждащи твърдения относно неговия статус на отворен код.
• Отчетност: Индустриалните организации и регулаторните органи трябва да държат компаниите отговорни за техните твърдения за отворен-код и да предприемат действия срещу тези, които се занимават с “изпиране” на отворен код.
• Образование: Потребителите и програмистите трябва да бъдат образовани относно принципите на отворен код и как да идентифицират истински проекти с отворен код.
• Сътрудничество: Общността с отворен код трябва да продължи да си сътрудничи, за да дефинира и насърчава принципите на отворен код и да разработва инструменти и ресурси, които помагат на потребителите и програмистите да навигират в екосистемата с отворен код.

Работейки заедно, можем да създадем по-прозрачна, отговорна и иновативна екосистема с отворен код, която е от полза за всички. Бъдещето на AI и други технологии зависи от това.