8 января 2010

Как использовать принципы Open Source по максимуму или MIT vs GPL

Open source
Перевод
Автор оригинала: Yehuda Katz
На протяжении последних нескольких лет я работал над рядом проектов с открытым кодом (из которых наиболее выделяются Merb, Ruby On Rails и jQuery) и сформулировал некоторые мысли по поводу использования проектов с открытым кодом и практических последствий выбора лицензии.

Игровое поле


По существу есть только два типа лицензий, которые широко используется в OpenSource.
Тип, с которым я работал наиболее часто, — лицензии BSD или MIT. Данные лицензии позволяют неограниченное использование, модификацию, распространение и коммерциализацию исходного кода, с двумя оговорками. Во-первых, уведомление об авторском праве должно распространяться вместе с исходным кодом. Во-вторых, если вы используете мой код под лицензией MIT, то не можете подать в суд на меня за последствия от использования данных исходников.

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

Наиболее популярной CopyLeft-лицензией является GPL, которая используется для Linux, и также имеет вирусный характер. В том смысле, что если вы используете код, опубликованный под GPL, в вашем собственном коде, то вы обязаны также открыть ваш код (если вы распространяете его).

Менее вирусная версия GPL — LGPL — требует, чтобы любые изменения, вносимые в программное обеспечение были также опубликованы, но убирает требование публикации при простом использовании.

Из-за неопределенности в отношении вирусных характеристик GPL, юридические отделы в крупных корпорациях очень враждебно относятся к лицензии GPL. Программное обеспечение под лицензией LGPL с большей вероятностью получит одобрение корпоративных юристов, а MIT/BSD лицензии вообще являются их любимчиками (видимо потому, что они не накладывают каких-либо обязательств на корпорации).

Чего я хочу, когда я пишу Open Source.


Когда я работаю над серьезным Open Source проектом, как Ruby on Rails или jQuery, у меня возникают сравнительно простые желания.
  1. Я хочу, чтобы программное обеспечение, над которым я работаю, использовало как можно больше людей. Вероятно, это эгоистичное желание, но оно может быть расмотрено, как желание видеть в результате полезное программное обеспечение, которое действительно используют многие.
  2. Я хочу, чтобы сущесвтовало некоторое подмножество множества пользователей, которые будут присылать баг-репорты, а также проверять работоспособность кода в разнообразных ситуациях использования и рабочих окружениях для улучшения качества программного обеспечения в качестве результата. Это вкратце можно сформулировать как «Иметь достаточно глаз, чтобы все ошибки всплыли на поверхность».
  3. Я хочу, чтобы были люди, которые достаточно заинтересованы в совершенствовании программного обеспечения, чтобы представлять патчи. В частности, я хочу получать патчи от людей, которые обдумали проблему, нашли причину ошибки и пытаются её исправить, и хочу получать меньше патчей от людей, которые просто придумали очередной хак, чтобы просто заставить что-то работать. В сущности, высокое отношение сигнал/шум для патчей является более важным, чем большое количество патчей.
  4. Я хочу, чтобы были люди, которые заинтересованы в совершенствовании программного обеспечения долгосрочной перспективе. Чтобы проект получил долгосрочных участников (contributors) и в конечном итоге разработчиков (committers).

Из этих желаний, номера два и три имеют самый высокий приоритет. Я хочу подвергать код на столько сильному воздействию реального мира, насколько это возможно. И я хочу как можно больше высококачественных патчей, чтобы исправить выявленные ошибки. Хотя если бы мне пришлось выбирать между этими двумя пунктами, я бы выбрал номер два: «разоблачение» моего кода воздействием реального мира является лучшим способом для быстрого обнаружения ошибок и неправильных предположений в дизайне, который я знаю.

Выполнение этих требований


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

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

Если хотя бы 1% от всех пользователей кода под MIT-лицензией всегда будут сообщать о найденной ошибке, то это будет 1% от тысяч потенциальных пользователей, в отличии от 100% от нуля проприетарных пользователей в случае CopyLeft-лицензии. На практике эта цифра намного больше, чем 1%, так как проприетарные пользователи программного обеспечения делают баг-репорты так же, как OpenSource-пользователи.

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

Несомненным плюсом вовлечения проприетарных разработчиков в OpenSource-проект является то, что код дополнительно проверяется в проприетарных окружениях. Кроме того, они имеют доступ к закрытым сценариям использования, а также доступ на рынки с низким проникновением OpenSource.

Следующим крупным желанием является постоянный поток высококачественных патчей. Казалось бы это должно быть сильной стороной CopyLeft-лицензий, потому что все пользователи программного обеспечения вынуждены вносить свой вклад. Однако, поскольку проекты с CopyLeft лицензиями не используют в проприетарной среде в любом случае, то патчи для Open Source проектов из этих сред для проектов под более либеральными лицензиями гораздо более многочисленны. Опять же, даже если лишь несколько процентов от проприетарных пользователей внесёт вклад обратно в проект, это будет означать значительно больше взносов, чем 100% от нуля проприетарных пользователей.

Конечно, я могу говорить только про jQuery и Rails (и другие более мелкие проекты с открытым кодом, над которыми я работаю), но большое количество новых долгосрочных участников стали заниматься Open Source проектом во время работы над корпоративными проектами, где разрешительная лицензия была во главе угла при выборе программного обеспечения для внутреннего использования.

Низкий барьер для вступления помогает удовлетворить цели Open Source


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

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

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

Постскриптум: Linux


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

В случаях, подобных этому, я бы сказал, что лицензия CopyLeft достаточно близка к максимизации использования, которая является основным преимуществом от более либеральных лицензий. Однако, для меня не ясно, какие выгоды CopyLeft лицензия может обеспечить даже в этих (довольно редких) случаях.
Теги:Open SourceGPLMITBSD
Хабы: Open source
+45
5,5k 37
Комментарии 87
Лучшие публикации за сутки