В статье приведен обзор процесса разработки программного обеспечения с открытым исходным кодом, осуществляемый в рамках организации Eclipse Foundation. С некоторых пор Суровый является коммитером проекта Eclipse Communication Framework, знает процесс изнутри, поэтому может рассказать не только о формальной стороне дела, но и поделиться личными впечатлениями.
Коммиттеры и контрибъютеры
Понятия "Коммиттер" и "Контрибъютер", а также взаимосвязь между ними описаны в документе под названием Committer Due Diligence Guidelines.
Контрибьютор - это человек или организация, которые вносят свой вклад в развитие того или иного проекта. Вклад может быть выражен исходным кодом, документацией в Eclipse WiKi или комментариями в Eclipse Bugzilla.
Коммиттер - это человек, который имеет доступ к содержимому сайта eclipse.org и, самое главное, к репозиторию исходных кодов проекта. Каждый проект, разрабатываемый под эгидой сообщества Eclipse, имеет свою команду коммиттеров. Никакой код не может попасть в репозиторий проекта минуя коммиттеров.
Взаимодействие контрибьютеров с коммитерами осуществляется только публично и только через официальный багтреккер - Eclipse Bugzilla. Контрибьютер регистрирует баг (баг в данном контексте обозначает задачу) и по возможности прикрепляет к нему набор патчей.
IP-процесс
Коммит присланных патчей и кода, разработанного непосредственно коммиттером, а также работа с кодом, разработанным третьей стороной (имеются ввиду библиотеки, не являющиеся проектами Eclipse), должны подчиняться правилам т.н. Eclipse Legal Process'а (иногда его еще называют IP-процесс), наглядно изложенным в постере.
Если коротко, то коммиттер имеет право непосредственно добавить в репозиторий только свой код под лицензией EPL, не содержащий криптографии, или код контрибьютора, написанный исключительно данным контрибьютером под той же лицензией, при этом размер
этого кода не может превышать 250 строк. В остальных случаях необходимо создать Contribution Questionnaire - тоже баг, но уже не в Eclipse Bugzilla, а в Eclipse IPZilla. Создать запись в IPZilla может только коммиттер, а работать над ним будут представители Eclipse Project Management Committee (PMC). Их задача - предотвратить все возможные имущественные споры относительно прав на код и другой контент, который планируется разместить на серверах Eclipse Foundation.
Интересный момент: если код был написан человеком до того, как он стал коммиттером - данный человек не имеет права добавить его в репозиторий минуя создание CQ. Т.е. решение о наделении коммиттерскими правами не имеет обратной силы: код был создан контрибьютером и коммититься должен как код контрибьютера.
При этом в репозиториях Eclipse-проектов может храниться код, распространяемый только по лицензиям из определенного набора. Вопросы по лицензированию кода можно отправлять на почтовый ящик.
Стоит учитывать, что процедура обработки CQ довольно длительна. Например четыре CQ, созданных для бандлов ECF, разработанных Суровым, обрабатывались два месяца (с конца июля по конец сентября), что конечно не может вызывать положительных эмоций. Вообще встречать поклонников IP-процесса мне еще не приходилось.
Использование сторонних библиотек
Вопрос использования каждой сторонней библиотеки, т.е. библиотеки, не являющейся проектом Eclipse в каждом проекте необходимо решать отдельно. Обсуждается данный вопрос с представителями PMC в рамках CQ-запроса (т.е. в рамках отдельного бага в IPZilla). Представители PMC проверяют является ли лицензия, под которой распространяется библиотека, допустимой для Eclipse Foundation, известны ли все коммиттеры и контрибьютеры библиотеки и т.д. Результатом обсуждения является либо разрешение использовать библиотеку, либо отказ в таком разрешении. При этом каждая новая версия библиотеки утверждается отдельно.
Большим подспорьем в данном случае является проект Eclipse Orbit - репозиторий бандлов, созданных из сторонних библиотек, уже утвержденных для использования в проектах Eclipse. Однако, чтобы использовать бандл из Orbit в своем проекте - необходимо создать CQ специального вида. Справедливости ради, стоит отметить, что такие CQ обрабатываются очень быстро.
Относительно лицензий на сторонние библиотеки действует то же ограничение, что и относительно лицензий на код. Единственное, можно использовать уже скомпилированные библиотеки, а список допустимых Eclipse Foundation лицензий на бинарный код несколько больше, чем список допустимых лицензий на исходники.
Как получить статус коммиттера
Процедура получения коммиттерских прав описана в документе. В общих чертах она выглядит следующим образом:
1. Один из коммиттеров проекта выдвигает кандидатуру нового коммиттера на голосование (будем называть того, кого выдвигают кандидатом, как правило это один из активных контрибьютеров). В предложении к голосованию объясняется причина выдвижения и описываются заслуги кандидата.
2. Коммиттеры проекта и только они участвуют в голосовании. Решать кому быть, а кому не быть коммиттером проекта могут только другие коммиттеры данного проекта. Подробно процедура голосования описана здесь: голосование длится не менее рабочей недели, чтобы голосование было признано успешным кандидату нужно набрать не менее трех голосов "за" и ни одного "против". Если в команде менее трех коммиттеров - все коммиттеры должны проголосовать "за".
3. Результаты голосования должны быть утверждены лидером проекта. В принципе, лидер проекта имеет право отказать кандидату, успешно прошедшему голосование, в коммиттерском статусе.
4. После утверждения кандидатуры лидером проекта кандидат должен выполнить т.н. paperwork - предоставить в Eclipse Management Organization (EMO) подписанное им соглашение - Individual Committer Agreemen и подписанное работодателем коммиттера Eclipse Committer Employer Consent Form. Случаи, когда коммиттер является сотрудником афилированной с Eclipse Foundation компании, частным предпринимателем, безработным или студентом несколько отличаются и подробно описаны в Eclipse WiKi. На заполнение бумаг кандидату дается 60 дней, отправить бумаги можно обычной почтой, по факсу или в виде отсканированного документа по электронной почте. Если кандидат не укладывается в 60 дней - результат голосования отменяется. Так как автор во время оформления коммиттерского статуса работал в Челябинске, а офис компании Naumen находится в Екатеринбурге, то получить нужные подписи под нужными бумагами быстро не удалось. К счастью, получилось уложиться в 60 дней.
5. Свежеиспеченный коммиттер получает атрибуты своего статуса - доступ на портал. Именно через портал создаются CQ-запросы, а также осуществляется управление проектом и коммиттерским аккаунтом. Помимо доступа к порталу коммиттер получает доступ к репозиторию исходных кодов. Сейчас проекты Eclipse Foundation используют для организации репозиториев CVS, SVN и Git. В последнее время наметилась тенденция миграции на Git, что связано с успехами плагина EGit.
Как потерять статус коммиттера
Если коммиттер ничего не заливает в репозитории в течении шести месяцев возникает вопрос о лишении его коммиттерского статуса. Лишить коммиттера статуса может так же лидер проекта.
IP Log
Для каждого проекта автоматически ведется журнал учета изменений интеллектуальной собственности (IP Log). Например, для ECF данный журнал расположен по адресу. Требования к IP Log описаны в Eclipse IP Policy. Согласно данным требованиям, IP Log содержит:
1. Лицензию, под которой распространяется проект
2. Код третьей стороны - таблицу, в которой собрана информация об используемых в проекте библиотеках, не являющихся проектами Eclipse. Для каждой библиотеке указывается ссылка на CQ, в котором велось ее обсуждение, название, версия и лицензия. В отдельных таблицах приведена информация о неиспользуемых и рассматриваемых библиотеках.
3. Список коммиттеров проекта. Для коммиттера указывается компания, в которой он работает. Отдельно приведен список неактивных коммиттеров и коммиттеров, которые никогда не были активными (т.е. так ничего и не закоммитивших).
4. Список контрибьютеров с указанием их вклада в сообщество. Каждый вклад характеризуется ссылкой на баг в Eclipse Bugzilla, размером и названием решенной задачи. Если комиттер при закрытии бага указывает флаг iplog, то все комментарии (содержащие и не содержащие патчи) попадут в IP Log проекта. Флаг iplog можно указывать не для бага целиком, а для конкретного патча. Учет вклада каждого контрибьютера в проект важен, т.к. на его основе коммитеры проекта могут принимать решение при голосовании по кандидатуре данного контрибьютера, если тот номинируется в коммиттеры.
5. Список зафиксированных исправлений. Если коммиттер не указал, что права на закомиченный им код принадлежат другому человеку - он имеет возможность исправить свою ошибку, однако факт исправления будет зафиксирован.
6. Список репозиториев, информация из которых используется для формирования IP Log'а. Обычно совпадает с репозиториями проекта.
За три недели до запланированной даты очередного релиза проекта необходимо отправить IP Log на рецензию в Eclipse legal. Анализ IP Log'a является составной частью т.н. Release Review.
Ссылки
В своей работе коммитеры руководствуются следующими документами и ресурсами:
- Eclipse.org Terms of Use
- Eclipse Foundation Software User Agreement
- Eclipse IP Policy
- Committer Due Diligence Guidelines
- Eclipse Legal Process Poster
- Eclipse Development Process
- Eclipse Development Resources
- IP Log
- Automatic IP Log
Понравилось сообщение - подпишитесь на блог
10 комментариев:
1. 250 строчек это число взято из какого илбо международного правового акта, по защите интелектуальной собственности? или из головы?
2. как определяется и какую отвественность несет комитер включая заведомо не его код (украденный) и как потом эта ситуация разрешается на правовом поле / в проекте, чем обеспечиваются гарантии чистоты кода в CQ ?
если не трундно можно ответить новым постом, а не тут, в коментах.
Как компания-работадатель относится к такой деятельности?
Или это по вечерам, выходным?
Когда появятся дети и свободное время закончится с Eclipse Foundation придется покончить? ;-)
@axet я все же отвечу здесь.
Я не знаю откуда взялось число в 250 строчек, некомпетентен в данном вопросе. Читал, что на уровне сложившихся правил ведения деловой деятельности (имеется ввиду не на уровне какого-то закона, а на уровне сложившейся практики) код считается украденым, если 40% совпадает или близко похоже на оригинал. Возможно, в Foundation считают, что 250 строчек это оптимально, чтобы не попасть под 40%.
Коммиттер подписывает соглашение, так же соглашение подписывает его работодатель. Если коммиттер украл чужой код и закоммител его как свой, то он будет отвечать за нарушение авторских прав (правда не знаю, кто будет с ним судиться: Foundation или истинный правообладатель). Если же коммитер просто закоммител чужой код под видом своего, чтобы не проходить IP процесс, то его лишат коммитерских прав.
При прохождении CQ члены PMC как правило верят на слово коммитеру.
@Andrew Fink
Вас интересует как мой работодатель относится к такой деятельности или вообще?
Любой коммиттер, работающий на дядю, должен предоставить соглашение, подписанное должностным лицом компании-работодателя, имеющим право подписи. Данное соглашение обозначает, что компания как минимум не против того, что ее сотрудник вносит вклад в Eclipse Foundation.
Будет ли работодатель оплачивать рабочее время сотрудника, которое он тратит на Foundation оговаривается уже внутри компании. Если сотрудник договорился, что работать над Eclipse-проектами он будет в свободное время, то его работодатель может написать об этом письмо в Foundation и сотрудник получит право указывать в поле Copyright себя, в противном случае, по-умолчанию, он должен указывать в этом поле название компании.
Я знаю российские фирмы, которые активно взаимодействуют с Eclipse Foundation и их разработчики полный рабочий день трудятся над проектами Eclipse. Компании зарабатывают на этом деньги.
Представлял себе, что процесс участия в жизни Eclipse Foundation не может быть простым по своей природе. Все же, это крупная структура, поэтому некоторый бюрократические проволочки необходимы.
Только, к сожалению, теперь создается впечатление, что большая часть бюрократии необходима для того, чтобы решить все вопросы лицензирования и не иметь потом головной боли. Это все понятно, в таком мире мы живем и IT не исключение. Хотелось бы, конечно, по-другому, но вот возможно ли? :)
Т.к. Eclipse Foundation активно взаимодействует с коммерческими организациями, то потребность в обеспечении лицензионной чистоты кода присутствует. Фактически Foundation перекладывает реализацию данной потребности с плеч своих юристов на разработчиков.
Другой путь есть - разрабатывать вне Eclipse Foundation, например используя Eclipse Labs или GitHub.
Разрабатывать в рамках Eclipse Labs можно. Только вот все это не будет являться частью Eclipse. Интересно, есть ли примеры успешного перехода проекта начатого в рамках Labs в Eclipse Foundation?
Вообще, поведение Foundation в этом вопросе (перекладывание на плечи разработчиков части юридических вопросов) целиком оправдано. Все же это организация, за которой стоит open-source коммьюнити, а не крупная коммерческая "машина" для продажи готовых продуктов. Наверное, было бы слишком ожидать от них полностью самостоятельного решения всех юридических (да и других) вопросов.
"...должны быть утверждены лиТером проекта"
Есть успешный пример перехода проекта с Google Code на eclipse.org - это проект EGit.
@Pavel Samolisov
Спасибо за ответ, значит все возможно.
Отправить комментарий
Любой Ваш комментарий важен для меня, однако, помните, что действует предмодерация. Давайте уважать друг друга!