На днях состоялся запуск Creative Commons Legal Database одного из долгожданных проектов от Creative Commons, нацеленного на сбор и систематизацию информации, связанной с лицензиями Creative Commons (судебные дела и юридические статьи). Проект выглядит многообещающим (конечно, там есть судебная классика по опенсорсу Jacobsen v Katzer, правда, в очень сжатом виде), но пока не впечатляет своим объемом надеюсь, в скором времени там появится информация и по России, например. А пока предлагаю узнать про эту базу данных и сам проект в целом из статьи ниже.

---

Юридическая база данных Creative Commons Legal Database это подборка судебных прецедентов и юридической науки, которая поможет нашим пользователям узнать больше о правовых вопросах, связанных с лицензиями Creative Commons и юридическими инструментами. Эта информация была предоставлена многими преданными членами Creative Commons Global Network и юридической командой Creative Commons. Она опубликована на общедоступном бета-сайте, и мы работали над выпуском новой версии, чтобы, наконец, закончить проект как официальный продукт Creative Commons.

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

Исследуйте новый сайт

Теперь вы можете получить доступ к обновленному сайту Creative Commons Legal Database и наслаждаться удобством работы с ним. Просмотрите ресурсы, которые призваны помочь вам понять применимость и прецеденты, установленные судами по всему миру в отношении лицензий Creative Commons, включая юридические исследования, обсуждающие лицензии Creative Commons и инструменты общественного достояния.

Домашняя страница Creative Commons Legal Database

Cписки судебных дел из Creative Commons Legal Database

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

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

В случае сомнений проверьте раздел "Часто задаваемые вопросы" или свяжитесь с нашими юристами.

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

Что дальше?

Всегда есть место для улучшения. Для этого проекта есть ряд аспектов, где мы все еще можем улучшить технологический уровень:

• Улучшить поиск в настоящее время функция поиска довольно ограничена по условиям, которые могут быть запрошены, а это значит, что если пользователи совершат ошибку (например, перепутают местами две буквы) то они, вероятно, не найдут того, что хотели. Кроме того, поиск можно улучшить, показав рекомендации, когда ничего не найдено.
• Сделать таблицы сортируемыми по столбцам дайте пользователю больше возможностей для изучения и сканирования ресурсов. Было бы неплохо иметь функции, обеспечивающие большую интерактивность с данными.

Если вас интересует процесс, который потребовался для переосмысления сайта, есть ряд сообщений в блоге Open Source blog, которые освещают это.

Как я могу внести свою лепту?

Правовая база данных Creative Commons это проект с открытым исходным кодом, поэтому вклад сообщества приветствуется. Вы можете найти код в репозитории на Гитхабе и сообщить об ошибках или предложить новые функции. Пожалуйста, прочтите руководство по отправке контрибьютов перед их отправкой. У нас также есть канал в Slack для обсуждения специфики проекта, вы можете присоединиться к #cc-dev-legal-database, если желаете, мы будем ждать ваших ценных комментариев. И напоследок, пожалуйста, следите за анонсом от юридической команды Creative Commons, который будет включать в себя призыв делать контрибьюты.

В этой статье расскажем как лицензируется Elastic Stack, какие бывают лицензии, что туда входит (ключевые возможности), немножечко сравним Elastic с OpenDistro от AWS и другими известными дистрибутивами.



Как видно на картинке выше, существует 5 типов, условно говоря, подписок, по которым можно пользоваться системой. Подробности по тому, что написано ниже, вы можете узнать на специальной странице Elastic. Всё написанное в этой статье применимо к Elastic Stack, размещаемому на собственной инфраструктуре (on-premise).

Open Source. Это версия Elastic Stack, которая находится в свободном доступе в репозитории Elastic на Github. В принципе, вы можете взять ее и сделать убийцу Arcsight, QRadar, Splunk и других прямых конкурентов Elastic. Платить за это ничего не нужно.

Basic. Этот тип лицензии включает в себя возможности предыдущей лицензии, но дополнен функционалом, который не имеет открытого кода, но, тем не менее, доступен на бесплатной основе. Это, например, SIEM, доступ к ролевой модели, некоторые виды визуализаций в Kibana, Index Lifecycle Management, некоторые встроенные интеграции и другие возможности.

На этом бесплатные лицензии закончились и пришло время разобраться с платными лицензиями. Elastic Stack лицензируется по количеству нод Elasticsearch. Рядом может стоять хоть миллион Kibana и Logstash (или Fluentd, если угодно), но лицензии будут считаться именно по хостам, на которых развернут Elasticsearch. В расчет лицензий также не входят ноды с ролями Ingest, Client/Coordinating. На попадающее в расчет количество нод напрямую влияет объем входящего трафика и требования к хранению данных. Напомним, что для обеспечения надежности работы кластера, в нем должно быть минимум 3 ноды. Мы проводим расчет сайзинга исходя из методики, которую описывали в одной из предыдущих статей. При покупке лицензий Elasticsearch доступен только формат подписки длительностью от 1 года с шагом в 1 год (2, 3 и так далее). Теперь вернемся к типам лицензий.

Gold. В лицензии Elasticsearch уровня Gold появляется поддержка авторизации через LDAP/AD, расширеное логирование для внутреннего аудита, расширяются возможности алертинга и техподдержка вендора в рабочие часы. Именно подписка уровня Gold очень похожа на AWS OpenDistro.

Platinum. Наиболее популярный тип подписки. кроме возможностей уровня Gold, тут появляется встроенное в Elastic машинное обучение, кросс-кластерная репликация, поддержка клиентов ODBC/JDBC, возможность гранулярного управления доступом до уровня документов, поддержка вендора 24/7/365 и некоторые другие возможности. Ещё в рамках этой подписки они могут выпускать Emergency patches.

Enterprise. Самый выскоий уровень подписки. Кроме всех возможностей уровня Platinum, сюда входят оркестратор Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, решение по безопасности для конечных устройств Endgame (со всеми его возможностями), поддержка вендором неограниченного количества проектов на базе Elastic и другие возможности. Обычно используется в крупных и очень крупных инсталляциях.

У Elastic появилось уже немало форков, самый известный из которых OpenDistro от AWS. Его ключевым преимуществом является поддержка некоторых возможностей оригинального Elastic, доступных на платных подписках. Основные это интеграция с LDAP/AD (а еще SAML, Kerberos и другими), встроенный алертинг (на бесплатном Elastic это реализуется через Elast Alert), логирование действий пользователей и поддержка JDBC-драйверов.

Упомянем также про HELK и Logz.io. Первый проект на Github, который обвешивает Elasticsearch дополнительным ПО для аналитики угроз (пишут, что пока это всё находится в альфе), а второй облачный сервис, основанный на Elastic и добавляющий некоторые приятные фичи. В комментариях можно поделиться другими форками, о которых вам известно.

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

А ещё можно почитать:

Сайзинг Elasticsearch

Разбираемся с Machine Learning в Elastic Stack (он же Elasticsearch, он же ELK)

Elastic под замком: включаем опции безопасности кластера Elasticsearch для доступа изнутри и снаружи

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows

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

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

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

Крупных инцидентов с оборудованием за время обслуживания не происходило до недавнего времени, когда потребовалось переустановить ОС на одном из компьютеров. ОС установили, ввели ESD ключ для Windows система активировалась. Установили Office 2016 Home and Business, ввели ESD ключ для Office и вот тут началось самое интересное. Мы увидели сообщение Ключ уже использован, выполните вход в учётную запись Microsoft. Ещё раз перепроверили все символы, убедились в том, что это постоянная лицензия, а не подписка. Решили войти в учётную запись MS. Перепробовав все возможные для этого действия адреса почтовых ящиков стало понятно, что учётной записи MS у организации нет.

Далее с помощью чата технической поддержки MS и специалиста по имени Jai мы решили выяснить, каким же образом был активирован Office в первый раз, если учётной записи у клиента нет. Мы предоставили ключ и возможные адреса e-mail, к которым мог быть привязан наш ключ. ВУАЛЯ! Стало понятно, что поставщик привязал проданный организации ключ к своему личному аккаунту MS. И чтобы воспользоваться Office снова, надо на целевом ПК просто войти в его учётную запись.



Мы связались с этим поставщиком, на что получили ожидаемый ответ, что если что-то хотите, можем за деньги приехать и сделать. А именно, войти в свою учётную запись. И это придётся делать каждый раз, когда нам потребуется переустановить Office с помощью ESD ключей, так как весь Office ESD был куплен у одного поставщика.

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

В чате ТП нам помочь не смогли, так как не обладают компетенциями в этом вопросе, и дали ссылку на созданный инцидент, предложив продолжить общение через e-mail.

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




Как вы понимаете, нас отправили обратно на страницу ТП, из которой нас ранее отправили на общение по e-mail.

Что мы имеем в сухом остатке

• Ключи ESD куплены, но воспользоваться ими нельзя.
• Поставщик предлагает за деньги активировать уже купленный Office, потому что сделать это без него специалисты компании не могут.
• Сам поставщик не имеет технической возможности отвязать от своей учётной записи ключи. Или он может просто не хотеть этого делать, даже если бы возможность была.
• Компания Microsoft тоже не имеет возможности перенести ключи из одной учётной записи в другую.

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

Но если действия поставщика ещё можно списать на какие-то человеческие факторы, то удручает тот факт, что Microsoft не только не может / не хочет применять какие-то меры по отношению к недобросовестным поставщикам, которые портят им репутацию, но и не может решить техническую проблему (перенос ключей) на своей стороне.

Будьте внимательны с ESD лицензиями и выбором поставщиков!

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

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

Любая помощь людям начинается с исследования сложившейся ситуации во-первых, сбор данных необходим для возможности дальнейшей автоматизации, а во-вторых, их анализ позволит нам узнать, что именно люди делают не так. В этой статье я опишу именно такое исследование: познакомлю вас с основными видами лицензий ПО (а также несколькими редкими, но примечательными), расскажу об анализе кода и поиске заимствований в большом объеме данных и дам советы о том, как правильно обращаться с лицензиями в коде и не допускать распространенных ошибок.

Введение в лицензирование кода

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

Мы с вами будем говорить только о лицензировании открытого (open-source) программного обеспечения. Во-первых, это связано с тем, что именно в такой парадигме мы можем легко найти много доступных данных, а во-вторых, сам термин открытое ПО способен ввести в заблуждение. Когда вы скачиваете и устанавливаете обычную проприетарную программу с сайта компании, вас просят согласиться с условиями лицензии. Разумеется, вы их обычно не читаете, но в целом понимаете, что это чья-то интеллектуальная собственность. В то же время, когда разработчики заходят в проект на GitHub и видят все исходные файлы, отношение к ним совсем другое: да, какая-то лицензия там есть, но она же открытая, и программное обеспечение это открытое, значит, можно просто брать и делать что хочешь, так? К сожалению, не все так просто.

Как же устроено лицензирование? Начнем с самого общего деления прав:



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

Так в чем же различие между разрешительными и копилефтными лицензиями? Как и все в нашей теме, этот вопрос достаточно специфический, и здесь есть исключения, но если упростить, то разрешительные лицензии не накладывают ограничений на лицензию измененного продукта. То есть можно взять такой продукт, изменить его и выложить в проект под другой лицензией даже проприетарной. Главным отличием от общественного достояния тут чаще всего является обязательство сохранять авторство и упоминание оригинального автора. Наиболее известными разрешительными лицензиями являются лицензии MIT, BSD и Apache. Многие исследования указывают MIT как наиболее распространенную лицензию открытого программного обеспечения вообще, а также отмечают значительный рост популярности лицензии Apache-2.0 с момента ее создания в 2004 году (например, исследование для Java).

Копилефтные лицензии чаще всего накладывают ограничения на распространение и модификацию побочных продуктов вы получаете продукт, имея определенные права, и обязаны запустить его дальше, предоставляя всем пользователям такие же права. Обычно это означает обязательство распространять программное обеспечение в рамках той же лицензии и предоставлять доступ к исходному коду. На основе такой философии Ричард Столлман создал первую и самую популярную копилефтную лицензию GNU General Public License (GPL). Именно она обеспечивает максимальную защиту свободы для будущих пользователей и разработчиков. Рекомендую почитать историю движения Ричарда Столлмана за свободное программное обеспечение, это очень интересно.

С копилефтными лицензиями есть одна сложность их традиционно делят на сильный и слабый копилефт. Сильный копилефт представляет собой ровно то, что описано выше, в то время как слабый копилефт предоставляет различные послабления и исключения для разработчиков. Наиболее известный пример такой лицензии GNU Lesser General Public License (LGPL): так же как и ее старшая версия, она разрешает изменять и распространять код только при условии сохранения данной лицензии, однако при динамическом линковании (использовании ее как библиотеки в приложении) это требование можно не выполнять. Иными словами, если вы хотите позаимствовать отсюда исходный код или что-то поменять соблюдайте копилефт, но если хотите просто использовать как динамически подключаемую библиотеку можете делать это где угодно.

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



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

Тут может возникнуть вопрос: а что, если у кода нет лицензии? Каким правилам следовать тогда? Такой код можно копировать? На самом деле это очень важный вопрос. Наверное, если код написан на заборе, то его можно считать общественным достоянием, а если он написан на бумаге в бутылке, которую прибило к необитаемому острову (без копирайта), то его можно просто брать и использовать. Когда же дело касается больших и устоявшихся платформ, таких как GitHub или StackOverflow, все не так просто, потому что, просто пользуясь ими, вы автоматически соглашаетесь с их условиями использования. Пока просто оставим об этом заметку в голове и вернемся к этому позже в конце концов, быть может, это редкость и кода без лицензии практически не бывает?

Постановка задачи и методология

Итак, теперь, когда мы знаем значение всех терминов, давайте точно сформулируем, что мы хотим узнать.

• Насколько распространено копирование кода в открытом программном обеспечении? Много ли среди открытых проектов клонов в коде?
• Под какими лицензиями существуют файлы? Какие лицензии наиболее распространены? Бывает ли в файле сразу несколько лицензий?
• Какие возможные заимствования, то есть переходы кода из одной лицензии в другую, встречаются чаще всего?
• Какие возможные нарушения, то есть переходы кода, запрещенные условиями оригинальной или принимающей лицензии, наиболее распространены?
• Каково возможное происхождение отдельных фрагментов кода? Какова вероятность, что данный фрагмент кода был скопирован с нарушением?

Чтобы провести такой анализ, нам необходимо:

1. Собрать датасет из большого количества открытых проектов.
2. Найти среди них клоны фрагментов кода.
3. Определить те клоны, которые действительно могут являться заимствованиями.
4. Для каждого фрагмента кода определить два параметра его лицензию и время его последней модификации, которое необходимо, чтобы узнать, какой фрагмент в паре клонов старше, а какой младше, и следовательно кто мог потенциально скопировать у кого.
5. Определить, какие возможные переходы между лицензиями являются разрешенными, а какие нет.
6. Проанализировать все полученные данные, чтобы ответить на вышепоставленные вопросы.

Теперь разберем каждый шаг подробнее.

Сбор данных

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

Для сбора данных нужно определиться с исследуемым языком программирования. Дело в том, что клоны ищутся в рамках одного языка программирования: говоря о нарушении лицензирования, сложнее оценить переписывание существующего алгоритма на другой язык. Такие сложные концепции защищаются патентами, в то время как в рамках нашего исследования мы говорим про более типичные копирование и модификацию. Мы выбрали язык Java, так как это один из самых широко используемых языков, который особенно популярен в коммерческой разработке ПО в этом случае потенциальные нарушения лицензирования особенно важны.

За основу мы взяли существующий Public Git Archive, в начале 2018 года собравший воедино все проекты на GitHub, у которых было более 50 звездочек. Мы отобрали все проекты, в которых есть хотя бы одна строчка на Java и скачали их с полной историей изменений. После фильтрации проектов, которые переехали или более недоступны, получилось 23 378 проектов, занимающих примерно 1,25 ТБ места на жестком диске.

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

Поиск клонов

Для поиска клонов, то есть похожих кусков кода, тоже необходимо принять некоторые решения. Во-первых, нужно определиться, насколько и в каком качестве нам интересен похожий код. Традиционно выделяют 4 типа клонов (от самых точных до наименее точных):

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

Нас интересует именно копирование и модификация, поэтому мы рассматриваем только клоны первых трех типов.

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

Исходя из выбранных решений, для поиска клонов мы использовали SourcererCC инструмент, который ищет клоны методом мешка слов: каждый метод представляется как частотный список токенов (ключевых слов, имен и литералов), после чего такие множества сравниваются, и если больше определенной доли токенов в двух методах совпадает (такая доля называется порогом схожести), то такая пара считается клоном. Несмотря на простоту такого метода (существуют гораздо более сложные методы, основанные на анализе синтаксических деревьев методов и даже их графов программной зависимости), его главным преимуществом является масштабируемость: при таком огромном объеме кода, как у нас, важно, чтобы поиск клонов осуществлялся очень быстро.

Мы использовали различные пороги схожести, чтобы найти разные клоны, а также отдельно провели поиск с порогом схожести 100%, в котором определялись только идентичные клоны. Кроме того, был установлен минимальный исследуемый размер метода, чтобы отбросить тривиальные и универсальные фрагменты кода, которые могут не является заимствованиями.

Такой поиск занял целых 66 суток непрерывных вычислений, было определено 38,6 миллиона методов, из которых только 11,7 миллиона проходили минимальный порог по размеру, а из них 7,6 миллиона приняли участие в клонировании. Всего обнаружилось 1,2 миллиарда пар клонов.

Время последней модификации

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

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



Предположим, мы нашли клон в виде пары фрагментов, каждый по 25 строчек. Более насыщенный цвет тут означает более позднее время модификации. Допустим, фрагмент слева был написан за раз в 2017 году, а во фрагменте справа 22 строчки были написаны в 2015, а три модифицированы в 2019. Выходит, фрагмент справа был модифицирован позднее, однако если бы мы хотели определить, кто у кого мог скопировать, логичнее было бы предположить обратное: левый фрагмент заимствовал правый, а правый позднее незначительно поменялся. Исходя из этого, мы определяли время последнего изменения фрагмента кода как наиболее часто встречающееся время последнего изменения его отдельных строк. Если вдруг таких времен было несколько, выбиралось более позднее.

Интересно, что наиболее старый фрагмент кода в нашем датасете был написан аж в апреле 1997 года, на самой заре создания Java, и у него нашелся клон, сделанный в 2019!

Определение лицензий

Вторым и наиболее важным этапом является определение лицензии для каждого фрагмента. Для этого мы использовали следующую схему. Для начала с помощью инструмента Ninka определялась лицензия, указанная непосредственно в заголовке файла. Если таковая есть, то она и считается лицензией каждого метода в нем (Ninka способна распознавать и несколько лицензий одновременно). Если же в файле ничего не указано, либо указано недостаточно информации (например, только копирайт), то использовалась лицензия всего проекта, к которому относится файл. Данные о ней содержались в оригинальном Public Git Archive, на основании которого мы собирали датасет, и определялись с помощью другого инструмента Go License Detector. Если же лицензии нет ни в файле, ни в проекте, то такие методы отмечались как GitHub, так как в таком случае они подчиняются условиям использования GitHub (именно оттуда были скачаны все наши данные).

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

Главная особенность данного графика состоит в сильнейшей неравномерности распределения лицензий. На графике можно заметить три области: две лицензии с более чем 100 тысячами файлов, еще десять с 10100 тысячами и длинный хвост из лицензий с менее чем 10 тысячами файлов.

Рассмотрим сначала наиболее популярные, для чего представим первые две области в линейной шкале:



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

Следом за ней находится пресловутое отсутствие лицензии, и нам все же придется разобрать его подробнее, раз уж данная ситуация настолько часто встречается даже среди средних и крупных репозиториев (более 50 звезд). Данное обстоятельство очень важно, поскольку просто загрузка кода на GitHub не делает его открытым и если что-то практическое и нужно запомнить из данной статьи, то это оно. Загружая код на GitHub, вы соглашаетесь с условиями использования, которые гласят, что ваш код можно будет просматривать и форкать. Однако за исключением этого, все права на код остаются у автора, поэтому распространение, модификация и даже использование требуют явного разрешения. Получается, мало того, что не весь открытый код является полностью свободным, даже не весь код на GitHub является в полном смысле открытым! И так как такого кода много (14% файлов, а среди менее популярных проектов, не вошедших в датасет, скорее всего, и того больше), это может являться причиной значительного количества нарушений.

В пятерке мы также видим уже упомянутые разрешительные лицензии MIT и BSD, а также копилефтную GPL-3.0-or-later. Лицензии из семейства GPL разнятся не только значительным количеством версий (полбеды), но еще и припиской or later, которая позволяет пользователю использовать условия данной лицензии или ее более поздних версий. Это наводит еще на один вопрос: среди этих 94 лицензий явно встречаются подобные семейства какие из них самые большие?

На третьем месте как раз GPL-лицензии их в списке 8 видов. Именно это семейство самое значимое, потому что вместе они покрывают 12,6% файлов, уступая только Apache-2.0 и отсутствию лицензии. На втором месте, неожиданно, BSD. Кроме традиционной версии с 3 параграфами и даже версий с 2 и 4 пунктами, существуют очень специфичные лицензии всего 11 штук. К таким, например, относится BSD 3-Clause No Nuclear License, которая представляет собой обычную BSD с 3 пунктами, к которой снизу приписано, что данное ПО не должно применяться для создания или эксплуатации ничего ядерного:

You acknowledge that this software is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility.

Самым разнообразным является семейство лицензий Creative Commons, о которых можно почитать тут. Их встретилось целых 13 и их тоже стоит хотя бы пробежать глазами по одной важной причине: весь код на StackOverflow лицензирован под СС-BY-SA.

Среди более редких лицензий есть некоторые примечательные, например, Do What The F*ck You Want To Public License (WTFPL), которая покрывает 529 файлов и позволяет делать с кодом именно то, что указано в названии. Есть еще, например, Beerware License, которая также разрешает делать что угодно и призывает купить автору пива при встрече. В нашем датасете мы также встретили вариацию этой лицензии, которую больше нигде не нашли Sushiware License. Она, соответственно, призывает купить автору суши.

Еще любопытна ситуация, когда в одном файле (именно в файле) встречается сразу несколько лицензий. В нашем датасете таких файлов всего 0,9%. 7,4 тысячи файлов покрываются сразу двумя лицензиями, и всего обнаружилось 74 разные пары таких лицензий. 419 файлов покрывается аж тремя лицензиями, и таких троек насчитывается 8. И, наконец, один файл в нашем датасете упоминает четыре разные лицензии в заголовке.

Возможные заимствования

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

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

Любопытно, что из оставшихся пар целых 11,7% составляют идентичные клоны с порогом схожести 100% возможно, интуитивно кажется, что абсолютно одинакового кода на GitHub должно быть меньше.

Все оставшиеся после данной фильтрации пары мы обрабатываем следующим образом:

1. Сравниваем время последней модификации двух методов в паре.
2. Если они совпадают с точностью до дня, игнорируем такую пару: нет смысла искать нарушения с такой точностью.
3. Если же они не совпадают, берем пару их лицензий от старшего к младшему и записываем. Например, если у блока из 2015 года лицензия MIT, а у блока из 2018 Apache-2.0, то записываем такую пару как потенциальное заимствование MIT Apache-2.0.

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



Здесь зависимость еще более экстремальная: возможное заимствование кода внутри Apache-2.0 составляет более половины всех пар клонов, а первые 10 пар лицензий покрывают уже более 80% клонов. Важно также отметить, что вторая и третья самая частые пары имеют дело с нелицензированными файлами также явное следствие их частоты. Для пяти наиболее популярных лицензий можно изобразить переходы в виде тепловой карты:

Возможные нарушения лицензирования

Следующий шаг в нашем исследовании определить пары клонов, являющиеся потенциальными нарушениями, то есть заимствованиями, которые нарушают условия оригинальной и принимающей лицензий. Для этого необходимо разметить вышеупомянутые пары лицензий как разрешенные либо запрещенные переходы. Так, например, наиболее популярный переход (Apache-2.0 Apache-2.0), разумеется, разрешен, а вот второй (GitHub Apache-2.0) запрещен. Но их очень и очень много, таких пар тысячи.

Чтобы с этим справиться, вспомним, что визуализированные первые 10 пар лицензий покрывают 80% всех пар клонов. Благодаря такой неравномерности, оказалось достаточно вручную разметить всего 176 пар лицензий, чтобы покрыть 99% пар клонов, что показалось нам вполне приемлемой точностью. Среди этих пар, мы считали запрещенными пары четырех типов:

1. Копирование из файлов без лицензии (GitHub). Как уже было сказано, такое копирование требует прямого разрешения от автора кода, и мы предполагаем, что в подавляющем большинстве случаев его нет.
2. Копирование в файлы без лицензии также запрещено, потому что это есть по сути стирание, убирание лицензий. Разрешительные лицензии вроде Apache-2.0 или BSD разрешают переиспользовать код в других лицензиях (в том числе проприетарных), однако даже они требуют, чтобы сохранялось упоминание оригинальной лицензии в файле.
3. Копирование из копилефтных лицензий в более слабые.
4. Специфические несовместимости между версиями лицензий (например, Apache-2.0 GPL-2.0).

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

В итоге после разметки оказалось, что 72,8% заимствований представляют собой разрешенные заимствования, а 27,2% запрещенные. На следующих графиках представлены наиболее нарушаемые и наиболее нарушающие лицензии.



Слева представлены наиболее нарушаемые лицензии, то есть источники наибольшего количества возможных нарушений. Среди них первое место занимают файлы без лицензий, что является важным практическим замечанием нужно особенно пристально следить за файлами без лицензий. Можно удивиться, что в этом списке делает разрешительная лицензия Apache-2.0. Однако, как видно из вышепредставленной тепловой карты, ~25 миллионов запрещенных заимствований из нее это заимствования в файл без лицензии, так что это следствие ее популярности.

Справа представлены лицензии, в которые копируют с нарушениями, и здесь больше всего представлены все те же Apache-2.0 и GitHub.

Происхождение отдельных методов

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

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

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



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

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

Остальные конфигурации не являются нарушениями:

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

Итак, как же распределены методы в нашем датасете?



Можно заметить, что примерно треть методов не имеет клонов вообще, и еще треть имеет клоны только в связанных проектах. С другой стороны, 5,4% методов представляют слабое нарушение, а 4% сильное нарушение. Хотя такие цифры и могут показаться не очень большими, это все еще сотни тысяч методов в более-менее крупных проектах.

TL;DR

Учитывая, что в этой статье много эмпирических цифр и графиков, повторим наши основные находки:

• Методы, у которых есть клоны, исчисляются миллионами, а пар между ними больше миллиарда.
• Всего в нашем датасете, состоящем из Java-проектов с более чем 50 звездами, найдено 94 вида лицензий, которые распределены очень неравномерно: наиболее часто встречаются Apache-2.0 и файлы без лицензии. Возможные переходы также встречаются чаще всего между Apache-2.0 и файлами без лицензии.
• Что касается запрещенных возможных переходов, то таких 27,2%, и наиболее часто нарушаются права авторов файлов без лицензии.
• Из самих методов всего 35,4% не имеют клонов вообще, у 5,4% часть старших клонов запрещают возможное заимствование, а у 4% все старшие клоны таковы.

А к чему все это?

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

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

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

1. Не стоит бояться юридического веса темы лицензирования и переживать из-за большого количества лицензий и их параметров. Для начала вполне достаточно понимать суть лицензий Apache-2.0, MIT, BSD-3-Clause, GPL и LGPL.
2. Даже для этих лицензий достаточно понимания одного главного параметра: является ли лицензия разрешительной или копилефтной. Так что если вы вдруг встретите какую-то незнакомую редкую лицензию, не обязательно читать все пять мониторов ее текста, для начала можно просто отыскать в интернете именно это ее свойство.
3. Наиболее пристального внимания требуют файлы на GitHub, для которых лицензия не задана. Такие файлы по умолчанию не являются открытыми и их заимствование требует разрешения автора. Вместе с тем отсутствие лицензии очень редко является намеренным выбором скорее, люди просто забывают об этом. В нашей лаборатории мы ввели следующую практику: когда кому-то надо позаимствовать код, не защищенный лицензией, мы просто пишем автору или создаем ишью, объясняя нашу заинтересованность, и просим добавить в проект лицензию. В подавляющем большинстве случаев разработчик добавляет лицензию, и сообщество открытого программного обеспечения становится чуточку лучше.

За понятными описаниями лицензий, а также за советами по выбору лицензии для своего нового проекта, можно обратиться к таким сервисам как tldrlegal или choosealicense.

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

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