Пересмотр политики Eclipse IP: сторонний контент

Фонд Eclipse находится в процессе серьезного обновления нашей Политики в области интеллектуальной собственности. Большая часть этого обновления — это изменение в способе управления сторонним контентом.

В контексте политики Eclipse IP «сторонний контент» — это контент, который используется проектом с открытым исходным кодом Eclipse, но не создается и не управляется проектом с открытым исходным кодом Eclipse. Библиотека, созданная, скажем, проектом с открытым исходным кодом Apache, считается сторонним контентом. Сегодня политика IP требует, чтобы весь сторонний контент был проверен командой Eclipse IP прежде, чем он будет использован проектом Eclipse. В ожидании одобрения Совета директоров Eclipse мы планируем изменить это.

После одобрения этих обновлений проектные группы смогут вводить новый сторонний контент в течение цикла разработки без предварительной проверки с командой IP. Таким образом, команда проекта может передать сценарии сборки, ссылки на код и т. Д. В стороннее содержимое в свой репозиторий исходного кода, не создавая сначала вопросник (CQ) для запроса, чтобы команда IP Team просмотрела и одобрила содержимое стороннего производителя. По крайней мере, в период разработки между выпусками ответственность за проектную группу возлагается на группу разработчиков — с достаточной степенью уверенности — гарантировать, что любой вводимый ими сторонний контент совместим с лицензией проекта. Прежде чем какой-либо контент может быть включен в какой-либо официальный выпуск, команда проекта должна проверить, что сторонние лицензии на контент совместимы с лицензией проекта.

Традиционно выпускам предшествует обзор выпусков, и, как часть этого обзора, Eclipse IP Team занимается проверкой записей проекта о вкладе интеллектуальной собственности и использовании стороннего контента (журнал IP). Именно во время проверки журнала IP IP Team проверит состояние совместимости лицензии. Я говорю «традиционно», потому что мы изменили традицию, или, более конкретно, мы изменили процесс разработки Eclipse в конце 2018 года, чтобы сделать так, чтобы команда проекта могла участвовать в любом количестве основных и второстепенных выпусков в течение всего года после успешного завершения. обзор выпуска. В случае, когда выпуск не требует проверки (и, следовательно, нет триггера для участия в проверке журнала IP), ответственность за совместимость лицензий для всех указанных сторонних материалов лежит на команде проекта. Но мы не покидаем проектные команды в одиночку: команда IP все еще может помочь с проверкой, даже если формальная проверка не требуется.

Мы экспериментировали с процессами и инструментами, чтобы помочь нам с проверкой совместимости лицензий. Эти инструменты будут использоваться Группой ИС во время оценки, а также будут доступны проектным командам. В идеале проектные группы должны интегрировать инструмент проверки совместимости лицензий в свои сборки, чтобы инструмент мог идентифицировать контент, требующий дальнейшего изучения, и представить его команде IP для разрешения на раннем этапе их цикла разработки, чтобы к тому времени, когда мы запустим инструмент для проверки содержимого в конце цикла выпуска — все идентифицированное содержимое уже будет разрешено, и команда IP может просто «штамповать» его.

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

Важной частью, делающей эту работу, является использование существующих информационных баз данных. За эти годы мы накопили значительное количество знаний о множестве библиотек, но другие также проделали большую работу. Новый процесс будет использовать другие надежные источники информации (подробнее об этом в будущем посте). Мы собираемся выйти из бизнеса сканирования каждого отдельного бита исходного кода и вместо этого доверять нашей собственной базе данных и другим источникам информации (и вносить вклад в эти другие источники информации).

Наш инструмент-прототип ориентирован на спецификацию. Каждая запись в ведомости материалов идентифицирует определенную стороннюю библиотеку. Чтобы определить конкретную стороннюю библиотеку, мы решили принять пять идентификаторов проекта ClearlyDefined , которые включают в себя: тип контента, его источник программного репозитория, его пространство имен и имя, а также версию. Координаты ClearlyDefined примерно аналогичны координатам Maven, которые однозначно идентифицируют конкретную часть программного обеспечения по groupid , artifactid и версии (например, org.junit.jupiter:junit-jupiter:5.5.2 однозначно идентифицирует контент, который, как известно, относится к EPL -2,0). Система координат ClearlyDefined добавляет тип содержимого как «maven», а его источник — «mavencentral», поэтому org.junit.jupiter:junit-jupiter:5.5.2 становится maven/mavencentral/org.junit.jupiter/junit-jupiter/5.5.2 (обратите внимание, что, по крайней мере, теоретически, источником может быть другой репозиторий Maven). Мы выбрали ClearlyDefined координаты хотя бы частично, потому что у нас есть проекты, использующие языки, которые не являются Java, и программные репозитории, которые не являются Maven Central; используя эти координаты, мы также можем идентифицировать, например, содержание NPM (например, npm/npmjs/@babel/generator/7.6.2 ).

Таким образом, ведомость материалов представляет собой список координат ClearlyDefined (инструмент-прототип автоматически переводит список зависимостей Maven или файл блокировки пакета узла в эту систему координат).

Плагин Maven Dependency можно использовать для создания списка зависимостей (в виде координат Maven):

Вывод плагина Maven Dependency имеет следующий вид:

Инструмент-прототип создает список материалов, который выглядит примерно так:

Вывод на самом деле также включает в себя несколько URL с выводом (например, указатели на исходный код, когда они известны), но я удалил их, чтобы сосредоточиться на важных битах. Вы также заметите, что содержимое, которое повторяется в списке зависимостей, появляется только один раз в выходных данных.

Для каждой библиотеки инструмент определяет лицензию и одобряет ли она использование (я буду обсуждать, как она работает в следующем посте). Любой контент, который указан как ограниченный, а не одобренный, должен быть рассмотрен и разрешен Группой ИС, прежде чем его можно будет включить в любой официальный релиз проекта (об этом я расскажу в следующем посте).

В настоящее время инструмент-прототип только идентифицирует лицензии и оценивает совместимость, чтобы определить, утвержден ли контент. Вывод легко анализируется для выявления проблемного контента, но наша цель — сделать его более полезным, не требуя дополнительных навыков bash-fu. Существует множество возможностей для дальнейшей автоматизации, включая превращение прототипа в плагин Maven для непосредственного включения в сборку и поддержки других систем сборки.

Этот список материалов становится сторонней контентной частью проекта IP Log. Это дает дополнительное преимущество, заключающееся в точности на 100% без необходимости использования таких вопросов, как комбинированные вопросники (CQ). По крайней мере, в краткосрочной перспективе система IPzilla и CQ останутся основными средствами взаимодействия коммиттеров проекта с командой IP, но только для контента, требующего расследования.