В мире Python разработчиками принято использовать предельно либеральные лицензии, такие как BSD, MIT или собственную лицензию Python. Понятно почему они хмурятся, когда слышат про очередной Python-проект выходящий под лицензией GPL. Причинами, по которым Zed Shaw, автор HTTP-сервера Mongrel для платформы Ruby On Rails и SMTP-сервера Lamson для создания расширяемых почтовых систем на языке Python, был вынужден перейти на эту лицензию, он делится на страницах своего блога.

• Во-первых выбор лицензии – это всецело прерогатива автора. Он пишет код, несмотря на косые взгляды и критические замечания в свой адрес. Он, вместо того, что бы идти и расслабится с друзьями, тратит время на его отладку. Он пишет документацию, что бы остальные могли воспользоваться плодами его труда. Он даже может посвятить часть своего времени ответам на вопросы пользователей. Автор имеет полное право на выбор лицензии.
• Разработчик хочет, чтобы его узнавали по результатам его труда. Каждый выбирает сам причину, по которой он пишет opensource код. Для одного это просто желание помочь людям. Другой надеется таким образом найти работу. Третий мечтает об открытии собственного бизнеса, занимаясь поддержкой своей разработки. Проблема в том, что исчезающее малое число потребителей готовы признать, что они используют открытый код. Такие откровения не добавят вам уважения в глазах начальства, и уж конечно об этом не говорят инвесторам, стараясь создать впечатление талантливых самородков, работающих не разгибая спины. Именно так поступали с HTTP сервером Mongrel для Ruby, когда нечистоплотные разработчики вставляли ее код в свои приложения не удосуживаясь упомянуть автора. Самое смешное, что если автор пытался обратить их внимание на некорректное использование его кода, его обвиняли в некомпетентности.
• Компании-однодневки изменили отношение к opensource бизнесу. Их деловые позиции построены исключительно на эксплуатации открытого кода и не ставят целью усовершенствование продукта, а только извлечение максимальной прибыли. Конечно, сама структура венчурных отношений подразумевает быстрый возврат инвестиций и постоянно растущий доход, что стимулирует инвесторов выкладывать еще больше денег и заставляет акции расти в цене. Но здесь зачастую нарушается неписаное правило opensource, по которому неэтично наживаться на чужом труде, не давая ничего в замен. Поэтому, если такие компании ничего не производят, то и нет смысла им что-либо давать «за так».
• Программисты не должны заниматься плагиатом. С некоторых пор сложилась такая тенденция, что люди берут открытое ПО, решают с его помощью свои задачи и затем присваивают себе всю славу за достигнутый успех. Эти люди растут в глазах своего начальства, получают прибавки к зарплате, повышения по службе, не удостаивая автора даже чести быть мимоходом упомянутым. Такие люди никогда не скажут «Этот замечательный кусок кода написал Zed Shaw. Давайте наймем его в качестве консультанта». Именно для искоренения таких случаев и существует GPL, предписывающая сохранять авторство кода неизменным, и заставляющая людей быть честными.
• Хорошая работа подразумевает достойную оплату. Это прекрасно, когда человек интересуется чьей-либо работой, готов помогать и принимать участие в дальнейшем развитии проекта. Для такого сотрудничества GPL не устанавливает никаких преград. Другое дело, когда речь заходит о бизнесе, и здесь условия могут варьироваться. Короче, открытые технологии к открытым, а бизнес к бизнесу.
• В завершении, GPL создает ощущение значимости проекта. Любая вещь, полученная человеком «за так» оценивается им, как малозначимая и стоящая меньше копейки. GPL, накладывая определенные ограничения на распространение продукта, заставляет людей читать и разбираться в способах возможного использования соответствующего ПО. Труд разработчика должен быть замечен и уважаем. GPL же препятствуют ушлым антрепренерам наживаться на открытых проектах и называть создателей неудачниками, показывая на них пальцем из окна своих дорогих автомобилей.