Заимствование кода и нарушения лицензий


Исследование повторного использования кода из более чем двадцати тысяч Java-проектов на GitHub показало, что почти 30% из них могут быть вовлечены в потенциальное заимствование кода, и почти 10% из них потенциально могут нарушать оригинальные лицензии.

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

Исследователи связаны с российскими университетами и JetBrains и объясняют в своей статье arxiv: 

Мы выбрали Java в качестве языка из-за его популярности в промышленности, где проблема плагиата особенно актуальна из-за возможных судебных исков.

Исследователи использовали Публичный архив Git (PGA), большой набор данных, который был составлен в начале 2018 года. Он состоит из всех проектов GitHub с 50 или более звездами, которые могут быть отфильтрованы по языку. Они извлекают все проекты, по крайней мере, с одной строкой, написанной на Java, что привело к 24 810 проектам в целом и окончательному набору данных из 23 378 репозиториев Java.

Для обнаружения клонов использовалась улучшенная версия SourcererCC. SourcererCC-это токен, определяющий токен как ключевое слово языка программирования, литерал или идентификатор. Инструмент анализирует файлы и маркирует данные, а затем использует эту маркировку для сравнения фрагментов кода для обнаружения возможных клонов. Исследователи переписали его на Python 3 и изменили его, чтобы открыть каждый файл с кодировкой UTF-8, чтобы решить проблему файлов, в которых отсутствуют символы, отличные от ASCII. Обнаружение клонов выполнялось в нескольких параллельных экземплярах с различными параметрами для порога сходства и более низкого порога длины токена. Основной поиск был выполнен с порогом сходства 75% и более низким порогом длины токена в 19 токенов, чтобы отфильтровать тривиальные фрагменты кода. Как только результаты обнаружения клонов были объединены вместе, выходные данные состояли из списка всех пар клонов плюс информация о каждом блоке, включая проект, из которого он был получен, адрес файла в проекте и строки в файле.

Для изучения нарушений лицензий исследователям необходимо было собрать два типа данных для этих фрагментов: лицензии и время последней модификации, что позволяет им предположить, какой код мог быть скопирован откуда. Для определения лицензий они использовали Ninka, инструмент, написанный на Perl, который использует подход, основанный на предложениях, для анализа верхней части каждого файла и сопоставления его с известными лицензиями. Для времени модификации они использовали команду git blame, вывод которой включает в себя каждую строку файла, а также его последнее время модификации (дату и время) и автора этой модификации.:

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

В это исследование было вложено впечатляющее количество усилий:

Сбор набора данных занял около одного дня, а обнаружение клонов заняло чуть более двух месяцев непрерывных вычислений. В общей сложности набор данных был токенизирован на 38 617 427 уникальных блоков кода. 11 762 703 блока кода прошли порог в 19 токенов, из которых 7 601 738 участвовали в процессе клонирования (64,6%). В общей сложности было обнаружено 1 163 989 420 пар клонов, которые поступили из 20 824 различных проектов, что означает, что в 2 554 проектах вообще не было клонов, превышающих пороговое значение. Из этих пар 560 656 419 были межпроектными (48,2%).

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

Apache 2.0 был, безусловно, самым распространенным и применялся более чем к половине файлов. Исследователи отмечают, что этот вывод согласуется с другими недавними исследованиями и состоянием:

Лицензия очень популярна из-за того, насколько она разрешительна и детализирована.

Как отмечается в статье, второй по распространенности, GitHub, на самом деле вовсе не лицензия, а отсутствие какой-либо лицензии.:

Когда разработчик загружает код на GitHub и не предоставляет никакой лицензии на него, все права защищены, и заимствование кода требует явного разрешения автора. Использование GitHub в качестве платформы подразумевает согласие с его Условиями предоставления услуг, что позволяет бесплатно просматривать и разветвлять код, однако бесплатное копирование не допускается.

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

Как показано на приведенной выше диаграмме, 35,4% блоков не имели клонов, а еще 35% были уникальными, что означает, что у них были клоны в рамках их проекта, или клоны между форками, или клоны в рамках одного автора или организации, но не было клонов, которые могли бы представлять собой заимствование кода или нарушение лицензии. Это оставило 29,6% блоков, которые так или иначе возникают парами из несвязанных проектов. Исходные блоки, на долю которых приходится 8% блоков, имеют клоны в других проектах, все из которых были изменены совсем недавно, что означает, что этот фрагмент кода может выступать только в качестве исходной точки возможного заимствования. Еще 10,4% блоков представляют собой легальные заимствования, что означает, что у них есть более старые клоны, но все их лицензии допускают этот переход. Остальные 9,4% блоков представляют собой возможные нарушения лицензии – 5,4% классифицируются как слабые нарушения, что означает, что только некоторые из их старых клонов запрещают возможное заимствование, в то время как 4% представляют собой сильные нарушения, что означает, что у них есть более старые клоны, и все они происходят из ограничительной лицензии.

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

“относительная симметрия: для каждой пары лицензий количество возможных заимствований от A до B и возможных заимствований от B до A, по крайней мере, одинаково”.

Исследователи комментируют:

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

Заимствование кода из Apache 2.0 в Apache 2.0, безусловно, является наиболее распространенным, и, поскольку это разрешительная лицензия, их можно считать “законными” заимствованиями. Проблемы возникают, когда нет лицензии – например, лицензии GitHub – или копирование кода с ограничительной лицензией, такой как Публичная лицензия GNU (GPL). Однако вывод о том, что только 4% заимствований кода представляют собой серьезные нарушения, хотя и не являются основанием для самоуспокоенности, указывает на то, что нарушения лицензий относительно редки.


Добавить комментарий