LINUX.ORG.RU

О лицензиях и авторстве кода

 , , , ,


0

2

Поднасобиралось тут вопросов. Итак:

  1. Вы пишете патч, его используют, но автор, получается, не вы. Обидно? Например, в [1] опубликован патч, в ответ - тишина. Спустя почти 4 месяца без спасибо - баг исправлен. В [2] видно, что автор - главный программер проекта (который при этом ещё и один из самых первых и известных разработчиков ядра). А предложенное улучшение вообще проигнорировано.
  2. Есть диагонально противоположный случай. Например, если вы хотите комитнуть в какой-нибудь проект гугла, то необходимо «подписать» с ними соглашение. Т.е. даже если вы хотите исправить опечатку, гугл признаёт и заботится о вашем праве на авторство, но и хочет обезопасить себя. Есть и другие проекты, которые требуют подобного. А теперь представьте, вы находите проблему с безопасностью в одном из таких проектов, пишете патч и... устанавливаете на него лицензию, которая свободная, но конфликтует с каким-нибудь пунктом лицензии проекта, и этот патч не имеют право принять. Но! Этот патч исправляет очень острую проблему, которую нельзя вот так теперь оставить. С другой стороны, вы являетесь автором, и никто не имеет права взять ваш кусочек кода и сказать, что это «тривиальный» фикс (хотя его обнаружить было далеко не тривиально), и мы имеем право и так его закомитить.
  3. А есть и вариант между ними. Вы написали патч, но один к одному его не могут принять. Помимо варианта, когда вас будут доставать до тех пор, пока вы сами его не приведёте в идеальный вид, и его можно будет закомитить (но только когда никому не особо важно быстрее получить эти изменения), есть два других варианта. Первый: комитер берёт и сам меняет патч, ставит себя в авторы, а вас где-то в комит-комментарии, что, мол, основано на таком-то патче. Вариант второй: создаётся ветка, ваш патч комитится, а потом второй патч облагораживает его, ветку «атомарно» сливают куда надо (т.е. ваш «сырой» патч ничего не может испортить). В итоге - вы автор оригинально патча, а комитер - автор изменений. Всё ясно и понятно. Есть какие-то оправдания первого варианта? И как агитировать на применение исключительно второго варианта?
  4. Частенько в открытых проектах можно видеть образцы кода, примеры, которые тем не менее защищены GPL/LGPL,.. Эммм... Какая тут логика? Ведь это код, который будет в любом проекте, который будет использовать данную библиотеку. Одно дело защищать код библиотеки, но что за бред защищать такой код? И действительно вообще в данном случае лицензионное ограничение?
  5. Бывает, встречаю статьи о том, как сделать что-то нехитрое, использовать какую-то либу. И... автор указывает, что его примеры лизензируются под GPL. Ну, 100%, что точно такой же код существует в куче проектов, использующих эти либы. И лицензии там 100% самые разные. Кто прав? И если авторы подобных статей не правы, кого вообще в подобных случаях оповещать о нарушении? Вот если кто-то нарушает GPL, то куда писать все знают. А если кто-то не в праве в конкретном случае использовать GPL, то тогда куда?
  6. Патентование алгоритмов - это зло. А что если GPL наложена на код, который можно назвать вариантом псевдокода алгоритма, который совпадает с C? [3] Мне кажется, что такая практика - это тоже зло. И, похоже, со мной согласны: вот, например, проект [4] использовал одну из «GPL»-функций. А у проекта лицензия BSD [5]. Упс.

Ух, пока всё. Внимание, ПРОСЬБА: конструктивные ответы и критика по пунктам. Особенно интересен опыт пишущих патчи и использующих чужой код в реальных (внутрефирменных тоже) проектах.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646629

[2] https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?id=4a4a44d7b14be190...

[3] http://www.strudel.org.uk/itoa/

[4] https://github.com/OculusVR/RakNet/blob/master/Source/Itoa.cpp

[5] https://github.com/OculusVR/RakNet/blob/master/LICENSE

★★★★★

Есть какие-то оправдания первого варианта?

Многие люди почему-то не заботятся о том, чтобы привести стиль кода в соответствие. Или делают исправление, которое меняет поведение так, что ломается другой use-case. Или предлагают «патчи», которые заново сделать проще, чем проверить. Или предлагают откровенно глючный код. Или решение делается немного не так, как сделал бы основной автор (так как автору на код смотреть придётся гораздо дольше, чем контрибьютеру, код должен выглядеть приятно. Автору).

И как агитировать на применение исключительно второго варианта?

Тут надо среди контрибьютеров разъяснительную работу производить. Но всё больше и больше я убеждаюсь в том, что многие люди просто не в состоянии понять, что же в их патчах не так.

i-rinat ★★★★★ ()
Последнее исправление: i-rinat (всего исправлений: 1)

В [2] видно, что автор - главный программер проекта

Так, может, Тс'о сам такой же патч написал? Там ведь не такое уж исправление, что два человека не могли его независимо друг от друга придумать.

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

Это, действительно, проблема. В некоторых местах её решают требованием подписать соглашение до того, как начнёшь отправлять патчи, — мейнтейнер нарочно не читает патчи от неподписавших. В других местах находят кого-нибудь, кто не читал этот патч, говорят ему, что надо сделать, и он сам пишет код (получается clean room). В третьих не парятся. Что же до обнаружения уязвимости, то ведь знание о наличии уязвимости не является объектом авторского права.

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

Так в итоге-то в истории проекта что? Два разных коммита или один? Если два разных, то кто-нибудь может откатиться на твою оригинальную версию, а она работать не будет. Это препятствует обнаружению багов бинарным поиском и в проектах, где принята «прямая и ясная история изменений», не поощряется.

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

proud_anon ★★★★★ ()
Последнее исправление: proud_anon (всего исправлений: 2)

С другой стороны, вы являетесь автором, и никто не имеет права взять ваш кусочек кода и сказать, что это «тривиальный» фикс

Любой имеет право исправить ошибку и получить в итоге точно такой же тривиальный патч, в общем в этом примерно и заключается понятие тривиальности которе делает твои авторские притязания на колесо ничтожными. Другое дело если закодил новую фичу с каким-то весомым объёмом кода создав тем самым новую, авторскую, сущность.

Вариант второй: создаётся ветка, ваш патч комитится, а потом второй патч облагораживает его, ветку «атомарно» сливают куда надо ... как агитировать на применение исключительно второго варианта?

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

Частенько в открытых проектах можно видеть образцы кода, примеры, которые тем не менее защищены GPL/LGPL,.. Эммм... Какая тут логика?

Под какой лицензией должен быть пример если библиотека, например, выпущена под copyleft лицензией?

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

А они то тут при чём? Внутри компаний вообще очень сильно не любят авторство на что либо, потому всеми правдами и неправдами заставляют сотрудников отказываться от авторства хотя это и запрещено в некоторых странах (в РФ, например). А на чужой код им вообще начхать пока он используется исключительно внтури.

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

mashina ★★★★★ ()

Первый пункт. Ты исправил опечатку. Да, молодец. Только она не столь существенная, второе, рано или поздно её б исправили другие. А может автор знал, но ленился. У меня был случай, где автор не верил, что в коде баг (находилось тривиально). Спустя два года он выпустил патченную версию. В своём варианте, но не суть.

По второму пункту и вообще что касается безопасности. Чтобы твоё имя прописалось в анналах истории делай все через CVE (рассылку, надеюсь знаешь). Далее, вне зависимости от лицензионных споров, ты будешь известен :)

gh0stwizard ★★★★★ ()

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

Если пойдти буквоедствовать дальше, то как это сочетается с разным подходом к работе систем контроля версий? Например, какие-то системы хранят патчи, а другие — снимки кодовой базы. То есть, в первом случае следует соблюдать лицензии всех патчей, во втором — формально на компьютере хранится изменённая копия исходного ПО, которая в случае copyleft уже автомагически лицензирована.

ilammy ★★★ ()
Ответ на: комментарий от ilammy

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

То есть «проблема» первых трёх пунктов сводится к тому, что патчи сначала публикуются под «никакой» лицензией, а потом на них предъявляются какие-то права и требования по тому, как следует использовать «ваш» код. Решается чётким указанием лицензии на ваши патчи. Хотя обычно да, с вас требуют подписания соглашения, где прописано, под какой лицензией вы передаёте свои патчи.

Пункты 4 и 5 в случае GPL бессмысленны, так как производные работы должны быть лицензированы тоже под GPL. Вот в случае LGPL ситуация действительно забавная.

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

ilammy ★★★ ()
Ответ на: комментарий от ilammy

Хотя если подумать, то патчи — это не производные работы.

Но ведь патч это не сферический кусок кода в вакууме, патч это «произведение созданное на основе другого произведения». ИМХО, как следствие патч должен быть под той же лицензией, что и оригинальное произедение (кроме случаев, когда лицензия допускает смену лицензии).

RiseOfDeath ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.