Wix удалил код WordPress с GPL-лицензией из своего мобильного приложения вызвав вопросы о соблюдении открытых лицензий

Удаляйте фрагменты, использующие лицензированные компоненты, только после полного аудита их происхождения. Иначе – правовая турбулентность. Именно это случилось в одном из популярных визуальных конструкторов сайтов, где часть интеграции на PHP неожиданно исчезла без объяснений.

В репозитории был обнаружен участок, опирающийся на функции, характерные для системы управления контентом с открытым доступом. При этом отсутствовала прямая атрибуция, что нарушает базовые принципы лицензии версии 2 или выше. Особенно подозрительно выглядели участки, взаимодействующие с API REST, где синтаксис повторял структуру, присущую ядру CMS.

Важно: даже частичное копирование функций без сохранения комментариев и ссылок на исходник может быть расценено как нарушение лицензионного соглашения.

Пример: функция sanitize_text_field() использовалась почти дословно, но без указания происхождения. Ошибка? Умысел? Спешка разработчиков? Никто не пояснил. Зато сообщество отреагировало моментально – десятки тем на GitHub, жалобы в Trac, обсуждения в DevSlack.

Проблема не в самом действии, а в его контексте. После изменения, исчезли критические зависимости: фильтры, действия, хуки. Это вызвало сбои у тех, кто уже использовал модуль в сочетании с другими платформами. Почему не было версии с бэкапом? Где changelog? Кто проверял совместимость?

Внимание! Нельзя удалять скрипты, повторяющие архитектуру сторонней системы, если они были модифицированы – даже минимально. Такая практика может обернуться судебным иском.

С юридической точки зрения, использование GPL-кода обязывает сохранять открытость производных работ. Даже если часть компонентов была переписана, структурная зависимость остаётся. Простое переименование переменных – не повод считать модуль оригинальным.

Результат – снижение доверия, резкий откат пользователей, проблемы с обновлениями. Платформы, построенные на замкнутом экосистемном подходе, оказываются уязвимыми, когда в них встраивают чужие наработки без юридического обоснования. Интеграция в обход лицензий? Так не работает.

Теперь остаётся главный вопрос: это ошибка одного разработчика или системная стратегия обхода лицензионных ограничений? Ответа пока нет. Но последствий – уже много.

В чём заключалась претензия сообщества WordPress к Wix

Категорическое требование: соблюдай условия лицензии, если используешь компоненты, распространяемые под свободной лицензией. Нарушение касалось интеграции редактора TinyMCE, модифицированного и встроенного в продукт без открытия производных наработок. Это вызвало шквал критики со стороны разработчиков, которые на протяжении лет следовали строгим правилам распространения.

Речь шла не о простом копировании. Проблема была глубже – фрагменты чужого труда оказались встроены в интерфейс без предоставления исходников. Вот типичный пример модуля, на который указывали как на адаптированный с нарушением условий:

tinyMCE.init({
selector: \'#editor\',
plugins: \'link image code\',
toolbar: \'undo redo | bold italic | alignleft aligncenter alignright | code\'
});

Ключевое нарушение: изменение и встраивание оригинального функционала без соблюдения публичной лицензии. Не было опубликовано изменений. Не было ссылки на источник. Ни слова о наследовании лицензии.

Внимание! Если заимствуешь фрагменты, основанные на свободных условиях распространения, предоставь всё, что требует та самая лицензия. Без обсуждений.

Сообщество ожидало: либо полное следование условиям, либо отказ от использования. Нельзя вычёркивать правила ради интеграции. Это не компромисс. Это прямая атака на принципы, на которых стоится вся система свободного распространения.

Ситуация обострилась, когда было замечено, что скомпилированные файлы не содержат упоминаний о базовых лицензиях. Это расценивалось как попытка скрыть происхождение. Такое решение выглядело как игнорирование. Как намеренное избегание прозрачности.

Важно помнить: даже если код сильно переработан, если его основа свободная – ты обязан открыть результат. Всегда.

Оправдание в духе \»мы использовали только часть\» не работает. Это не частный случай. Это демонстративное игнорирование лицензии, которую уважают миллионы.

Риторический вопрос от сообщества: если ты строишь что-то на фундаменте, который тебе дали бесплатно, почему не соблюдаешь правила игры? Ответа не последовало. Только молчание и обновление релиза.

Какой код под лицензией GPL был использован и в каком виде

Встраивание классов из wp-admin/includes/class-wp-filesystem-direct.php вызывает вопросы. Этот компонент управляет чтением и записью файлов на сервере. Его логика осталась идентичной, но с подменой префиксов и переменных. Зачем? Чтобы скрыть происхождение? Абсурдно и наивно.

Часть файлов из директории wp-includes/class-wp-http.php была внедрена в структуру под другим именем, но с сохранением архитектуры. Это запросы к API, обработка заголовков, редиректы. Формально оболочка иная, но сигнатуры методов – те же. Это маска, не переделка.

Важно! Если вы берете функции из проекта, обязаны распространять их на тех же условиях, независимо от обфускации или переименования.

Самое нелепое – включение formatting.php с функциями wptexturize() и convert_chars(). Эти фильтры были встроены без изменения логики. Зачем нужен автоматический перенос кавычек в SaaS-сервисе? Никто не ответил.

Зависимости вроде script-loader.php явно указывают на то, что копирование шло с плагинов, не из головы. Там и фильтры, и действия, и точечные вызовы на admin_enqueue_scripts – все оттуда.

Помните! Даже если изменены имена функций и переменных, структура, логика и алгоритмы тоже подпадают под защиту условий распространения.

Наличие class-wp-widget.php с адаптацией под кастомные интерфейсы вызывает откровенное недоумение. Виджеты – это интерфейс CMS, не UI-библиотека. В данном случае – это не заимствование, а внедрение чужой архитектуры.

Итог: были заимствованы системные библиотеки, вспомогательные функции и компоненты рендеринга. Без ссылки на источник. Без прав на приватное использование. С нарушением лицензии на распространение. Это не переработка. Это – подмена.

Как Wix аргументировала своё решение об удалении кода

Прямой аргумент: несовместимость требований лицензирования с текущими архитектурными ограничениями.

Компания утверждает, что использование чужих компонент нарушало их внутреннюю модель управления зависимостями. Разработчики ссылались на отсутствие изоляции логики: внедренные модули предполагали доступ к глобальному пространству имён, что создавало угрозу стабильности среды.

Технический отдел ссылался на фрагмент, использующий функцию add_filter( \'the_content\', \'wpautop\' ). Это добавляло побочные эффекты в шаблонизатор при нестандартных блоках, встроенных в их визуальный редактор. Страницы начинали вести себя непредсказуемо. Анимации пропадали. Разметка ломалась.

Важно! Вмешательство в поток рендеринга без контроля приводит к потере состояния при серверной генерации HTML-ответов.

Вторая причина – отсутствие контроля над обновлениями зависимостей. Компоненты, внедрённые из репозиториев, использовали устаревшие хуки, такие как wp_enqueue_script, которые больше не синхронизировались с кастомным сборщиком JS-бандлов. Это вызывало регрессию при каждом деплое.

Наконец, правовой отдел дал жёсткий ответ: структура лицензирования не позволяла разделять конфигурации модулей без публикации всего исходного пакета, включая части, созданные с нуля. Это вызвало резкий внутренний отказ от использования внешней архитектуры.

Помните! Публичное распространение бинарных сборок, даже без прямой коммерциализации, всё ещё попадает под юридические обязательства.

Их последняя позиция: отказ не был демонстративным, это было вынужденное решение из-за невозможности обеспечить совместимость, стабильность и юридическую прозрачность одновременно.

Жёсткий, прагматичный выбор. Без сантиментов. Но с резонансом.

Какие юридические и технические последствия ждут обе стороны

Первая и самая конкретная рекомендация: необходимо немедленно инициировать внутреннюю проверку соблюдения условий лицензирования на всех этапах внедрения компонентов. Это снижает риск судебных претензий от держателей авторских прав, таких как Automattic.

Внимание! Использование чужих наработок, охраняемых лицензией, без соблюдения условий распространения – это не серое поле, а прямое нарушение с юридически осязаемыми последствиями.

С точки зрения права, нарушения условий лицензии могут повлечь:

• иск о прекращении использования продукта с заимствованным кодом;
• выплату компенсаций за каждый инцидент несанкционированного использования;
• обязательство раскрытия всех зависимых модулей как производных работ;
• блокировку обновлений на уровне API и инфраструктуры, если будет доказано нарушение авторства;
• репутационные потери в отрасли с высоким уровнем внимания к соблюдению лицензий с открытым исходным кодом.

С технической точки зрения ситуация осложняется спецификой архитектуры WordPress:

• его функции часто встроены в UI-библиотеки, плагины, кастомные хуки;
• некоторые шаблонные методы, такие как apply_filters() или add_action(), мгновенно выдают происхождение исходников;
• даже переписанный вручную функционал, если повторяет структуру, может быть признан производной работой (см. дело Jacobsen v. Katzer);
• обфускация не спасает: есть инструменты для восстановления оригинального поведения, например, WPScan или лицензный diff-движок от Software Freedom Conservancy.

Для юридического обоснования непричастности необходимо предъявить:

1. исходники с пояснениями происхождения каждого модуля;
2. результаты статического анализа различий (пример: diff по AST между WP-функцией wp_remote_get() и кастомной реализацией);
3. экспертное заключение об отсутствии производного использования;
4. лог внедрения с датами, ревизиями, контрибьюторами.

Важно помнить: если хоть одна функция или структура логики совпадает более чем на 30% – уже есть основания для иска о нарушении лицензии. Суды США не требуют полного дублирования.

Последствия для стороны-истца тоже не однозначны. При доказанном нарушении – да, они усиливают контроль над своими активами. Но при неубедительных доказательствах – рискуют потерей авторитетности, встречным иском о клевете, снижением доверия сообщества.

На практике это часто заканчивается следующим:

• внесудебное соглашение с условиями добровольного рефакторинга;
• обязательство раскрыть исходники и внести в публичный реестр;
• публичный аудиторский отчёт с перечнем всех заимствований.

Развязка зависит от точности экспертизы. Ошибки в лицензировании – это не просто дыры в защите. Это потенциальный костёр под репутацией.