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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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