Лицензирование – один из аспектов разработки программного обеспечения, о котором многие забывают. Лицензия на программное обеспечение определяет, как лицензиаты (конечные пользователи) могут использовать и распространять код. Это может существенно повлиять на то, как широко будет внедряться та или иная технология. Большинство современных программных продуктов продается под закрытой лицензией, которая позволяет создателю сохранить интеллектуальные права на программное обеспечение.
Однако есть альтернативная точка зрения, согласно которой лицензия – устаревающий и ненужный инструмент контроля программного обеспечения его создателями. Закрытая лицензия не позволяет копировать и изменять исходный код программного обеспечения, а это наталкивает на мысль, что создатели программного обеспечения подавляют потенциальный рост новых технологий. Эта позиция вдохновила на создание лицензий, которые предоставляют пользователям право изучать, изменять и распространять исходный код программного обеспечения на свое усмотрение. Программное обеспечение, лицензированное таким образом, обычно называется «свободным» (также «бесплатным») или «открытым».
Какой пример Америка показывает всему миру?
В широком смысле оба понятия обозначают одно и то же – программное обеспечение с небольшими ограничениями на то, как его можно использовать. С точки зрения их сторонников, как свободное, так и открытое программное обеспечение является более безопасным, эффективным и надежным, чем закрытые программы. Однако зачем нужно целых два термина для одного и того же понятия? Чтобы понять это, нужно знать историю развития и понимать нюансы этих отдельных, но тесно связанных терминов.
Немного истории
Идея о том, что пользователи программ должны иметь право просматривать, редактировать и делиться своим исходным кодом без юридических последствий, совсем не нова. До 1970-х годов программное обеспечение, как правило, распространялось вместе с его исходным кодом, потому что в большинстве ПО было аппаратно-ориентированным, и конечным пользователям приходилось модифицировать, чтобы запустить на конкретной машине или добавить специальные функции.
Большинство пользователей тогда делали это в строго академических или исследовательских условиях. Вычислительные ресурсы, как правило, были разделены, и изменение программного обеспечения для создания более эффективных рабочих процессов или более надежных решений было широко распространенной практикой. Например, проект Genie UC Berkeley разработал операционную систему Berkeley Timesharing System, взломав исходный код компьютера лаборатории SDS 930.
Поскольку программное обеспечение стало более сложным и дорогим в производстве, компании-разработчики программного обеспечения искали способы остановить неконтролируемый обмен исходным кодом, чтобы защитить свои доходы и лишить конкурентов доступа к их коду. Они начали вводить юридические ограничения на свою продукцию, а также распространять свою продукцию под закрытыми лицензиями. К концу 1970-х годов большинство компаний-разработчиков перестали поставлять ПО с исходным кодом. Это вызвало недовольство многих пользователей компьютеров и, в конечном итоге, стало основой Движения свободного программного обеспечения.
Примеры верификации программ в Политехе
Появление свободного программного обеспечения
Движение свободного программного обеспечения было детищем Ричарда Столлмана. Столлман начал изучать информатику в начале 1970-х годов, до появления закрытых лицензий на программное обеспечение. В начале 1980-х годов он работал научным сотрудником Лаборатории искусственного интеллекта Массачусетского технологического института. Будучи членом академического сообщества хакеров более десяти лет, он не мог не возмутиться из-за распространения закрытого программного обеспечения. Столлман стал рассматривать его как нарушение прав пользователей на инновации и совершенствование существующего программного обеспечения.
В 1983 году Столлман запустил проект GNU – попытку создать полноценную операционную систему, которая предоставила бы своим пользователям свободу просматривать, изменять и делиться исходным кодом. Столлман сформулировал мотивацию проекта в GNU Manifesto. В нем он заявляет о своей убежденности в том, что закрытое лицензирование блокирует разработку программ, пресекает инновации и наносит ущерб развитию технологий.
По словам Столлмана, это несправедливо по отношению к пользователям и разработчикам, которые в противном случае могли бы изменить код в соответствии со своими потребностями или добавить новые функции. Таким образом, проект GNU можно рассматривать как ответ на разработку закрытого ПО, а также как отсылку к предыдущей эпохе – эпохе свободно распространяемого исходного кода и совместной разработки программного обеспечения.
В 1985 году Столлман учредил Free Software Foundation (FSF), некоммерческую организацию, занимающуюся продвижением концепции бесплатного программного обеспечения для широкой общественности. Позже Столлман разработает GNU General Public License, лицензию на программное обеспечение, которая обеспечивает конечным пользователям права свободно запускать, просматривать и совместно использовать исходный код.
Согласно FSF, чтобы ПО могло считаться по-настоящему «свободным», его лицензия должна гарантировать своим пользователям четыре основные свободы:
- Свободу запуска программы для любых целей.
- Свободу изучать работу программы и изменять ее согласно собственным потребностям. Непременным условием для этого является доступ к исходному коду.
- Свободу делиться программным обеспечением с другими пользователями.
- Свободу распространять копии пользовательского исходного кода. Так вы можете дать сообществу возможность пользоваться новым кодом. Непременным условием для этого является доступ к исходному коду.
Любое программное обеспечение, которое не соответствует этим критериям, FSF рассматривает как «несвободное».
Развитие открытого ПО
Столлман выбрал термин «свободное программное обеспечение», чтобы отобразить идею о том, что пользователи могут свободно изменять и совместно использовать исходный код по своему усмотрению. На протяжении многих лет это создавало путаницу: многие пользователи считали, что свободное программное обеспечение – это любое ПО, которое можно получить за нулевую стоимость (что более точно обозначается как «бесплатное» или «условно-бесплатное»).
К концу 1990-х годов сторонники GNU и Linux стали беспокоиться, что неоднозначность слова «free» приведет к тому, что пользователи перестанут понимать философию свободного программного обеспечения и его преимущества по сравнению с закрытым кодом. Организация FSF стала известна своей жесткой этической позицией относительно закрытого программного обеспечения всех видов. Среди некоторых сторонников свободного программного обеспечения появилась обеспокоенность по поводу того, что этот подход был слишком недружественным в деловом смысле и в конечном итоге препятствовал распространению Движения свободного программного обеспечения.
Собор и базар
В 1997 году Эрик С. Рэймонд, на тот момент сторонник и разработчик свободного программного обеспечения, написал широко цитируемое эссе «Собор и базар» (The Cathedral and the Bazaar), в котором сравниваются две разные модели разработки, используемые в различных проектах свободного программного обеспечения. Соборной называется модель, в которой исходный код открывается с выходом нового релиза программы, а во время работы на кодом доступ к нему имеет только ограниченная группа разработчиков (примером такой модели является разработка GNU Emacs). Базарной называется модель, в которой код разрабатывается на виду у сообщества через Интернет (как, например, было в случае ядра Linux).
Главный аргумент эссе заключается в том, что базарная модель по своей сути более эффективна при поиске и устранении ошибок, поскольку просматривать и экспериментировать с исходным кодом может больше людей. Таким образом, Рэймонд утверждал, что базарная модель разработки дает более безопасное и надежное программное обеспечение.
Отчасти в ответ на идеи «Собора и базара» в начале 1998 года Netscape выпустила исходный код своего веб-браузера Communicator в качестве свободного программного обеспечения (исходный код Communicator позже станет основой Mozilla FireFox 1.0).
Вдохновившись коммерческим потенциалом, который видела Netscape в этом релизе кода, группа энтузиастов свободного программного обеспечения (включая Рэймонда, Линуса Торвальдса, Филиппа Циммермана) стала стремиться к ребрендингу Движения свободного программного обеспечения и смещению его внимания с этических и философских мотивов. Группа выбрала название «open source» («открытое ПО» или «ПО с открытым исходным кодом») для свободно распространяемого программного обеспечения в надежде на то, что она лучше отразится на стоимости совместной модели развития.
Вскоре после этого Рэймонд и Брюс Перенс основали Open Source Initiative (OSI), чтобы поощрить использование нового термина и распространение принципов открытого ПО. Организация OSI также разработала Open Source Definition – список из десяти принципов, которым должна соответствовать лицензия на программное обеспечение, чтобы оно могло считаться открытым:
- Свободное распространение: лицензия не должна налагать ограничений на продажу и распространение ПО.
- Доступный исходный код: даже если ПО не поставляется с исходным кодом, этот код должен быть легко доступным. Это должен быть редактируемый человеком исходный код, а не его промежуточные формы.
- Возможность модификации: простая возможность читать исходный код не позволяет экспериментировать с ним и выпускать модификации. Лицензия, претендующая на звание «открытой», должна поддерживать не только чтение, но и изменение кода, использование частей этого кода в других проектах и распространение полученных программ на условиях той же лицензии.
- Целостность авторского исходного кода: лицензия может налагать ограничения на распространение модифицированного исходного кода, только если она разрешает распространять патчи для модификации программы при сборке.
- Отсутствие дискриминации против людей и групп людей: лицензия не должна дискриминировать людей и группы людей.
- Отсутствие дискриминации по цели применения: лицензия не должна ограничивать использование программы в определенных областях деятельности.
- Распространение лицензии: права на открытую программу должны применяться ко всем пользователям, которым была перераспределена программа, без заключения дополнительных соглашений.
- Лицензия не должна быть привязана к конкретному продукту: права на программу не должны зависеть от того, является ли программа частью какого-то продукта.
- Лицензия не должна ограничивать другие программные продукты: лицензия не должна налагать ограничения на другие программы, которые распространяются вместе с лицензированным ПО (не считая банальной несовместимости).
- Лицензия должна быть технологически нейтральной: она не должна требовать что-либо от интерфейса или технологий, используемых в производной программе.
Разница между свободным и открытым программным обеспечением
Многие считают, что разница между «свободным» и «открытым» программным обеспечением незначительна и объясняется небольшой разницей в подходах или философии. Согласно Open Source Initiative, оба термина означают одно и то же, и их можно использовать взаимозаменяемо практически в любом контексте. Просто Open Source Initiative предпочитает термин «открытое ПО», потому что он дает более четкое описание программного обеспечения и представлений его создателей о том, как его использовать.
Однако сторонники «свободного программного обеспечения» считают, что «открытый код» не полностью передает важность движения и потенциальных долгосрочных социальных проблем, вызванных закрытым программным обеспечением. Free Software Foundation считает, что организация OSI слишком много внимания уделяет продвижению практических преимуществ закрытого программного обеспечения (включая его прибыльность и эффективность модели разработки на основе сообществ) и недостаточно обеспокоена этической стороной и ограничением прав пользователей.
Является ли та или иная программа свободной или открытой зависит от лицензии, по которой она распространяется и от того, одобрена ли эта лицензия Open Source Initiative, Free Software Foundation (или обеими организациями). В этом организации часто совпадают, но есть несколько исключений. Например, лицензия NASA Open Source Agreement одобрена OSI, но FSF считает ее слишком ограничительной. Таким образом, FSF отговаривает других от использования программного обеспечения, распространяемого по этой лицензии.
Как правило, если программное обеспечение можно охарактеризовать как свободное, оно, скорее всего, также будет и открытым.
Альтернативы
На протяжении многих лет предлагались и другие названия для такого программного обеспечения, чтобы положить конец этой дискуссии. Свободное программное обеспечение с открытым исходным кодом (часто сокращается как FOSS) является одной из наиболее широко используемых альтернатив и считается нейтральным вариантом. Термин «libre software» (libre – слово из романских языков, которое означает свободу) стал настолько популярным, что со временем появился акроним FLOSS (free/libre and open-source software).
Следует отметить, что и свободное и открытое программное обеспечение отличается от общедоступного программного обеспечения. Свободное программное обеспечение с открытым исходным кодом определяет права посредством лицензирования, в то время как общедоступное программное обеспечение не использует лицензий. Важным отличием как свободного, так и открытого программного обеспечения является то, что все производные программы также должны распространяться по лицензии FOSS. Общедоступное программное обеспечение не выдвигает такого требования.
Еще одна проблема общедоступного ПО связана с тем, что контент, не защищенный авторским правом, признают далеко не все страны. Ни FSF, ни OSI не рекомендуют разработчикам выпускать общедоступное программное обеспечение.
Заключение
Термины «свободное ПО» и «открытое ПО» взаимозаменяемы в большинстве контекстов; предпочтение одного из них, как правило, сводится к вопросу о семантике или философии. Однако для многих программистов, которые создают ПО и хотят изменить способ использования и взаимодействия с технологией, разница может быть важной. При выпуске нового программного обеспечения важно тщательно взвешивать плюсы и минусы различных лицензий, включая закрытые лицензии, и выбирать ту, которая наилучшим образом соответствует вашим индивидуальным потребностям.
Если вы хотите узнать больше, ознакомьтесь с этим списком лицензий Free Software Foundation , в котором содержится подробное описание свободных и несвободных лицензий. Кроме того, вас также может заинтересовать страница лицензий и стандартов Open Source Initiative.
Источник: www.8host.com
Свободно ли свободное ПО? Основная информация про опенсорс и полезные ссылки
Собрала ключевую информацию по свободным лицензиям в одном месте. Статья будет полезна вам в трех случаях: 1) вы пишете код для коммерческого использования или вы руководитель разработчиков; 2) вы заказываете разработку кода по договору и переживаете, что разработчик будет использовать опенсорс; 3) вы написали код и думаете, под какой лицензией разместить.
1081 просмотров
Оглавление
Вы можете читать статью не полностью, а выбрать нужное вам. Блоки написаны так, чтобы даже если вы начнете с середины, вы все поняли.
- Базовая информация об опен сорсе
- Вариант 1. Вы пишите код для коммерческого использования или вы руководитель разработчиков
- Вариант 2. Вы заказываете разработку кода по договору и переживаете, что разработчик будет использовать опен сорс
- Вариант 3. Вы написали код и думаете, под какой лицензией разместить
- Некоторые виды лицензий: либеральные и вирусные
- Ссылки на полезные статьи и ресурсы
Базовая информация об опен сорсе
В этой статье пойдет речь о программном обеспечении с открытым исходным кодом, распространяемом на условиях свободных лицензий. Я использую термины — открытое ПО, опен сорс, свободные лицензии.
Это исключение из правил. Во всех остальных случаях исходный код ПО не раскрывается, а для его использования необходимо заключить лицензионный договор с правообладателем. Как правило, такой договор является возмездным и предусматривает конкретные индивидуальные условия использования ПО. Зачастую такие лицензии не предполагают возможность модификации ПО без разрешения правообладателя.
Открытое ПО в этом плане и проще, и сложнее. Проще — потому что исходный код открыт для каждого, его можно относительно просто использовать и дорабатывать. Сложнее — потому что каждая лицензия имеет индивидуальные условия. Некоторые свободные лицензии “заражают” весь код, например, запрещают некоторые способы его использования. Подробнее об этом будет дальше.
Свободные лицензии предоставляются безвозмездно, но использование опен сорса все же может предполагать определенные расходы. Это может быть пожертвование разработчикам опен сорса, оплата технического сопровождения или адаптация опен сорса под задачи заказчика.
Я вынуждена пропустить аспекты истории и философии вопроса — иначе статья будет огромная. Но упомяну, что сертификацию свободных лицензий осуществляет OSI и не каждая лицензия может называться опен сорсом. Перечень актуальных лицензий размещен тут , а критерии — тут.
Есть разрешительные свободные лицензии (можно использовать в коммерческих продуктах), а есть копилефт. Его еще достаточно смешно называют “авторское лево”. Копилефт предполагает большую степень свободы. К сожалению, в ряде случаев это несовместимо с коммерческой разработкой, потому что предполагает раскрытие исходного кода.
Вы понимаете, что если код раскрыт для любого — то за лицензию платить никто не будет. Подробнее про логику движения можно почитать тут.
Это вообще законно?
Свободным лицензиям посвящена статья 1286.1 ГК РФ. В статье речь идет о заключении простой (неисключительной) лицензии путем присоединения. Все просто. Простая (неисключительная) лицензия предполагает возможность выдачи лицензии неограниченное число раз на один и тот же программный продукт.
Заключение договора путем присоединения означает, что вы полностью соглашаетесь с условиями лицензии и не можете в них вносить правки. Если вы скачиваете открытое ПО — вы заключаете лицензионный договор.
Обратите внимание, что такой договор обязателен к соблюдению. То есть за нарушение условий открытой лицензии может быть установлена ответственность. Теоретически правообладатель может обратиться в суд и потребовать взыскания убытков или запретить вам использовать программу. Правда, риски невелики с учетом количества потенциальных нарушителей.
А вот попытки продавать лицензии на открытое ПО с нарушением условий лицензии с большой вероятностью будут пресечены судом со взысканием убытков и расходов. В общем, свободные лицензии не похожи на обычный договор, но условия стоит соблюдать.
Если компания использует опен сорс в рамках лицензии — она действует в рамках закона. Ссылку на статью 1286.1. ГК РФ можно использовать в том числе при проверках правоохранительных органов.
Ниже я разберу три основных случая, когда вам может быть важно знать подробнее про свободные лицензии. Если какой-то случай не про вас — можно спокойно перелистывать дальше.
Вариант 1. Вы пишете код для коммерческого использования или вы руководитель разработчиков
- Вы разработчик фрилансер и разрабатываете ПО для заказчиков с фокусом на коммерческое использование (продажу лицензий);
- Вы разработчик в коммерческой компании;
- Вы руководитель разработчиков
Риски неправомерного использования опен сорса:
- Программу нельзя будет включить в реестр отечественного ПО, а от этого зависит льгота по НДС. Ставка НДС сейчас 20%, так что это может быть довольно существенно;
- Если в компанию зайдет новый инвестор или учредитель, он обратит внимание на проблемы с опен сорсом в программном обеспечении компании, что может повлиять на условия сделки
- Программу будет сложно коммерциализировать (выдавать лицензии или продать);
- Лицо, которое получило лицензию или купило программу, может потребовать возместить убытки. Это прямые расходы компании, судебные и репутационные издержки
- Если вы руководитель и не подумали об этом, у вас могут быть проблемы на работе включая финансовые санкции и увольнение.
- Стоит внимательно читать условия лицензии;
- Если вы руководитель — обсудите внедрение в компании регламента использования открытого ПО. Это локальный нормативный акт. В нем напишите, какие открытые лицензии в каких случаях разрешено использовать, дайте на подпись гендиру и ознакомьте всех разработчиков под подпись или иным образом;
- Если вы разработчик, вы можете задать руководителю вопрос о разрешенных для использования свободных лицензиях в вашей компании.
- Если вы фрилансер — один раз разберитесь и решите для себя, какие вы лицензии будете использовать. Если будут нужны новые — очень внимательно читайте условия
Вариант 2. Вы заказываете разработку кода по договору и переживаете, что разработчик будет использовать опен сорс
- У вас есть ПО и его нужно дописать силами сторонних разработчиков (не сотрудников вашей компании);
- Вы заказываете разработку ПО. Тип договора в данном случае не принципиален
Риски (магическим образом ровно те же, что и при недобросовестной разработке)
- Программу нельзя будет включить в реестр отечественного ПО, а от этого зависит льгота по НДС. Ставка НДС сейчас 20%, так что это может быть довольно существенно;
- Если в компанию зайдет новый инвестор или учредитель, он обратит внимание на проблемы с опен сорсом в программном обеспечении компании, что может повлиять на условия сделки
- Программу будет сложно коммерциализировать (выдавать лицензии или продать);
- Лицо, которое получило лицензию или купило программу, может потребовать возместить убытки. Это прямые расходы компании, судебные и репутационные издержки
- Если вы руководитель и не подумали об этом, у вас могут быть проблемы на работе включая финансовые санкции и увольнение.
Объективно заказчик далеко не всегда может проверить чистоту ПО. Экспертизы обычно не хватает, а аудит или специализированный софт для проверки — дополнительные расходы. Ключевая роль тут будет в условиях договора с исполнителем.
- Прописать конкретные разрешенные открытые лицензии;
- Наоборот, прописать запрещенные к использованию открытые лицензии;
- Указать, что исполнитель обязан указать все использованные свободные лицензии;
- Предусмотреть возмещение убытков и/или выплату штрафов исполнителем в случае нарушения таких условий.
Расскажите вашему юристу для чего вы будете использовать ПО и попросите прописать эти гарантии.
Вариант 3. Вы написали код и думаете, под какой лицензией разместить
Вы разработали офигенный код и хотите рассказать об этом миру. Например, хотите опубликовать его на GitHub.
В целом, у вас тут все хорошо. Вы автор, вы решаете, кто и что будет делать с этим кодом.
Но есть некоторые особенности. Подумайте, захотите ли вы когда-либо использовать этот код эксклюзивно. Например, на следующий день после публикации вам позвонит CEO корпорации Big Numbers и предложит на базе этого кода сделать продукт в его компании. Или, возможно, вы захотите продавать ПО в дальнейшем.
Еще хорошо бы, чтобы условия лицензии предусматривали ограничение ответственности. То есть, чтобы ПО предоставлялось as is (как есть) и разработчик не возмещал убытки в случае каких-то проблем совместимости. Такое условие содержится во многих permissive лицензиях (об этом чуть ниже).
- Сохранить подтверждения того, что автор именно вы;
- Выбрать удобную для вас лицензию. В качестве старта можно посмотреть либеральные лицензии из списка ниже;
- Учитывать, использовали ли вы сами свободную лицензию. Возможно, она вам диктует, на какой лицензии публиковать ваш код
Некоторые виды лицензий: либеральные и вирусные
Все свободные лицензии делятся на две группы:
- permissive (либеральные) — позволяют использовать свободное ПО для создания коммерческих программ с закрытым исходным кодом
- copyleft (вирусные) — если разработчик использует ПО, распространяемое на условиях такой лицензии, то созданное в результате ПО должно распространяться на условиях такой же лицензии
Ниже я привожу ссылки на наиболее распространенные свободные лицензии для примера. если будете их использовать, пожалуйста, не забудьте перейти во вкладку Fulltext и внимательно прочитать условия лицензии.
Либеральные лицензии
- MIT License (Expat)
- Apache License 2.0 (Apache-2.0)
- BSD 2-Clause License (FreeBSD/Simplified)
- BSD 3-Clause License (Revised)
Вирусные лицензии (копилефт)
- GNU General Public License v3 (GPL-3)
- Mozilla Public License 2.0 (MPL-2.0)
Разобрать все лицензии в одной статье не получится, но давайте разберемся, на что вообще смотреть и обращать внимание.
Например, нам понравилась лицензия MIT. Читаем (ресурсы, где можно прочитать условия свободных лицензий, укажу ниже):
Лицензия MIT
Это очень либеральная и простая лицензия. Она практически ничего от нас не требует.
- Сохранять уведомление об авторском праве в каждой копии программного обеспечения. Ну то есть делаем файл с названием license, копируем туда условия полностью, сохраняем в корневом каталоге ПО;
- Иметь в виду, что ПО предоставляется “как есть”, без гарантий (нормальная практика для либеральных лицензий)
Обратите внимание, что в википедии для этой лицензии указано “Копилефт — нет”. Важно иметь в виду, что для коммерческой разработки копилефт может не подойти.
Для контраста посмотрим копилефт лицензию GNU General Public License version 3. Сделать это одним скриншотом уже сложнее, лицензия более сложная. Весь текст можно посмотреть по ссылке, а я отражу основные условия, которые я бы отметила в первую очередь.
- Такая лицензия сфокусирована на свободе пользователей. Если вы используете GNU GPL в своем ПО, то вы “заражаете” весь код. “Заражаете” в том смысле, что вы должны будете раскрыть исходный код вашего ПО, что очевидным образом препятствует его коммерциализации.
- У вас появляются определенные обязанности. Например, сохранить все уведомления об отсутствии гарантий, включить в исходный текст уведомления о внесенных изменениях и ряд других
- Вы никак не сможете пресечь дальнейшую доработку и распространение уже вашего ПО, в котором вы использовали GNU GPL
У GNU есть своя философия, она заслуживает уважения. Но на практике очень важно сверять, насколько условия лицензии подходят вам. Причем, речь не про одну эту копилефт лицензию — в каждой свои условия. Просто стоит привыкнуть внимательно читать условия лицензии или выбирать только знакомые разрешительные лицензии.
Полезные ссылки
Ресурсы для выбора лицензии
Англоязычный ресурс. На одной странице основные лицензии и условия. Каждую можно кликнуть и прочитать подробнее. https://choosealicense.com/appendix/
Еще один англоязычный ресурс для выбора лицензии https://tldrlegal.com/
Информация о лицензиях на русском языке licensit
Статьи на языке разработчика
Статья https://habr.com/ru/post/243091/. Автор подробно разобрал условия отдельных лицензий. Статья написана в 2014 году, поэтому стоит перепроверять актуальность условий лицензий, но материал отличный
https://habr.com/ru/post/40293/ Автор разобрал условия некоторых лицензий
Статьи на юридическом языке
Статья Савельева А.И. Базовая информация о свободных лицензиях. Очень качественная статья, но может быть тяжеловато читать не юристу https://www.appp.ru/nopirate/corporate/part_3.php
Буду рада вашим вопросам и комментариям.
Расскажите регламентируется ли в вашей компании использование опен сорса? А фактически проверяете условия перед использованием?
Источник: vc.ru
Свободное программное обеспечение
В соответствии с современным законодательством большинства стран, программный продукт и его авторским правом, которое даёт авторам и правообладателю (чаще всего правообладателем является организация-наниматель автора авторских прав в современном обществе настолько велика, что даже изучение или попытки исправления ошибок программ путём свободными лицензиями . Несмотря на то, что по условиям свободных лицензий выданные пользователям разрешения правообладатель отозвать не может, свои права, гарантированные законодательством, авторы сохраняют.
Свободное ПО легко коммерциализируется — существует множество бизнес-моделей, где исключена необходимость оплаты копий программы. Например, высокую популярность имеет бизнес-модель, когда предприниматель может заработать за счёт предоставления услуг технической поддержки. Правообладателю свободного кода может быть интересен другой вариант — реализация программных продуктов на условиях коммерческой лицензии, в случае, если клиенту необходимо интегрировать свободный код в собственническое ПО , но он не желает раскрытия своих разработок.
Разработка ПО как научное исследование [ ]
Особенность 1970-е годы существовало огромное разнообразие различных архитектур вычислительных машин, различавшихся также производительностью и ценой. Естественно, для каждой архитектуры приходилось разрабатывать отдельный набор программного обеспечения. С середины 1970-х в большинстве американских университетов для академических разработок использовались компьютеры архитектуры Массачусетского технологического института (MIT) в конце 1970-х разработали для PDP-10 собственную операционную систему Введение ограничений для ПО [ ]
Чтобы защитить свои интересы, производители компьютеров и программного обеспечения используют лицензии — вид договора между обладателем авторских прав и пользователем (покупателем) программного обеспечения. Подобные договоры заключались и с университетами: например, университету передавались исходные тексты программ и право их изменять, но запрещалось распространять их за пределами университета. Подобные ограничения означали, что тексты соответствующих программ не могли открыто обсуждаться в сообществе, то есть не существовали для научной разработки. Были у компьютеров и программного обеспечения покупатели и вне академической среды — например, банки. Таким пользователям не столь важно получить исходные тексты программ, они заинтересованы в программном обеспечении как в законченном продукте и готовы платить деньги за надёжные и удобные программы.
Однако компьютеры развивались очень быстро, и бывшие вполне современными в 1970-е PDP-10 к началу 1980-х уже устарели и значительно отставали по производительности от более современных машин. Однако ни для одной из новых архитектур уже не было операционной системы и прочего программного обеспечения, разработанного исключительно в академической среде и по её правилам. Теперь университеты должны были покупать новые компьютеры с новым программным обеспечением и выполнять условия лицензии, ограничивающей их права на разработку и распространение ПО — иначе говоря, ограничивающей возможность научной модели разработки и распространения программного обеспечения.
В это время в лаборатории искусственного интеллекта MIT разрабатывались так называемые Файл:Rms ifi large.jpg
полусвободное (такое, которое отличается от свободного лишь запретом на коммерческое использование) и собственническое ( proprietary ) (которое не имеет всех четырёх свобод, даже если коммерческое использование разрешено).
В отличие от собственнического, полусвободное ПО упоминается редко. Иногда к несвободному ПО относят и всё « коммерческое ПО », считая свободное ПО видом бесплатного, однако это неверно: получать выгоду от программы можно не только продажей несвободных лицензий.
Определение свободного ПО [ ]
Основная статья: Определение свободного ПО
Для того чтобы сохранить модель научного сотрудничества между разработчиками, необходимо было обеспечить, чтобы исходные тексты программ, написанных разработчиками, оставались доступными для чтения и критики всему научному сообществу с сохранением авторства произведений. Для этого бесплатному программному обеспечению , которое распространяется без взимания платы за использование, но недоступно для изменения сообществом, потому что его исходные тексты не опубликованы. Такое бесплатное ПО вовсе не является свободным. Наоборот, свободное ПО вполне можно распространять (и распространяют), взимая при этом плату, однако соблюдая при этом критерии свободы: каждому пользователю предоставляется право получить исходные тексты программ без дополнительной платы (за исключением цены носителя), изменять их и распространять далее. Всякое программное обеспечение, пользователям которого не предоставляется такого права, является несвободным — независимо от любых других условий.
Открытый доступ к исходным текстам программ является ключевым признаком свободного ПО, поэтому предложенный несколько позднее [2]
Основная общественная лицензия GNU [ ]
Основная статья: GNU General Public License
Логотип GNU GPLv3
Декларировав критерии свободного ПО, члены Фонда свободного ПО стали распространять свои программы в соответствии с этими принципами, никак не оформляя это документально: иначе говоря, первоначально свободные программы распространялись вообще без лицензии. Однако произошедший с самим Ричардом Столлманом прецедент (см. ниже) убедил его в том, что документальное оформление необходимо для свободного ПО.
Ричард Столлман занимался разработкой текстового редактора Emacs на основе исходных текстов Джеймса Гослинга . Тогда Гослинг свободно раздавал свои исходные тексты всем заинтересованным. Однако в какой-то момент Гослинг продал права на распространение Emacs компании UniPress [3] , и эта компания попросила Столлмана прекратить распространение его версии Emacs, так как права принадлежат им. авторских прав) с пользователем, в котором автор, среди прочего, оговаривает права пользователя по отношению к программе. В отличие от типовой собственнической лицензии, лицензия Столлмана предоставляет пользователю права, являющиеся критериями свободной программы: получать исходные тексты программ, изменять их, распространять изменённые и неизменённые версии. Впоследствии лицензия Столлмана получила название GNU General Public License («Основная общественная лицензия GNU»), сокращённо GNU GPL или просто GPL.
В этой лицензии оговаривается также принципиальное для Столлмана защитное условие распространения свободного ПО: ни один пользователь, сделавший модифицированную версию свободной программы, не имеет права распространять её, не соблюдая всех принципов свободного ПО, то есть делать модификацию свободной программы несвободной. Чтобы подчеркнуть отличие такой лицензии, которая использует ЗоАП («copyright») для побуждения к сохранению свободы, от типовых собственнических лицензий, которые используют ЗоАП для ограничения свободы, был придуман термин « copyleft » (копилефт) — игра слов, построенная на значениях английских слов right и left. [4] Действие копилефта основано на том, что производные работы в большинстве случаев наследуют лицензии своих составляющих; если в программе используется небольшая часть стороннего кода под GPL, то вся программа и её производные должны распространяться под GPL, пока они являются производными этого кода. При этом в GPL есть раздел, позволяющий требовать сохранения в коде имён авторов, запрещать использование этих имён в рекламе, предупреждать о зарегистрированных товарных знаках и т. п., что позволяет комбинировать работы под GPL с работами под многими свободными некопилефтными лицензиями (например, некоторыми из Сообщество разработчиков и пользователей [ ]
Главное условие существования свободного ПО — все-таки не лицензия, а люди, которые готовы бесплатно делиться текстами своих программ и совершенствовать тексты чужих. Свободное ПО унаследовало модель открытой научной разработки, а вместе с ней — и академическую модель взаимодействия между учёными, вылившуюся в специфическую организацию сообщества разработчиков и пользователей.
Взаимопомощь [ ]
У любого пользователя программного обеспечения непременно возникают вопросы, когда он пытается применить его для решения своих задач. Пользователь несвободной (патентованной) программы платит за неё производителю, который иногда взамен предоставляет ему некоторые гарантии, одна из которых — отвечать на вопросы о работе программы. Специально для этого производитель организует службу поддержки, которая по телефону, электронной почте и другим средствам связи отвечает на вопросы пользователей.
В любой достаточно сложной программе непременно имеются ошибки и дефекты, количество которых обычно неизвестно. Многие крупные производители ПО создают и оплачивают работу отдела контроля качества (QA — Quality assurance ), который контролирует соответствие процесса разработки ПО определенным требованиям, выполнение которых позволяет снизить вероятность появления ошибок в ПО (например, требованиям стандарта DO-178B, который применяется при разработке ПО для авиационных систем). Тем не менее, в настоящее время отсутствуют методы, позволяющие полностью гарантировать отсутствие ошибок в достаточно сложном ПО (существуют формализованные критерии сложности ПО).
Пользователь закрытой частной программы, столкнувшись с ошибкой, не всегда может выявить её причину и исправить ошибки (поскольку ему недоступны ни исходные тексты программы, ни даже системы отслеживания ошибок (bug tracking system), самые известные из которых разработаны участниками больших проектов для себя, а благодаря свободным лицензиям используются повсеместно. Таковы GNUTS (разработанная в GNU), Bugzilla ( Samba ) или Интернете, на котором пользователь может заполнить форму сообщения об ошибке. Каждое сообщение имеет свой номер, по которому можно попасть на «персональную» страницу данной ошибки, где отражаются все происходящие по её поводу события, от первоначального сообщения (открытия) до исправления (закрытия). При каждом изменении в состоянии ошибки Bugzilla рассылает всем заинтересованным лицам (включая, естественно, сообщившего об ошибке и занимающихся данной программой разработчиков) письма по электронной почте. Поскольку Bugzilla позволяет оставлять комментарии и прикладывать файлы, она является полноценным средством для общения пользователя с разработчиком по поводу ошибки в программе.
Принципиальное преимущество пользователя свободной программы заключается в том, что у него, в отличие от пользователей несвободных программ, всегда есть возможность заглянуть в исходные тексты. Конечно, для многих пользователей исходные тексты не более понятны, чем машинный код. Однако при достаточном уровне познаний в программировании пользователь может сам установить причину ошибки в программе, а то и устранить её, исправив соответствующим образом исходный текст. А если пользователь заинтересован в развитии программы, то с его стороны будет разумно не только сообщить автору об ошибке, но и прислать ему свои исправления к исходному тексту программы: автору останется только применить эти исправления к тексту программы, если он найдёт их корректными и уместными. Пересылать автору исправленный текст программы целиком непрактично: он может быть очень большим (десятки тысяч строк), и автору будет нелегко разобраться, что же изменено (а вдруг изменения сделаны неграмотно?).
Чтобы облегчить и автоматизировать процесс внесения исправлений, 1984 году разработал утилиту «patch» («заплатка»), которая в формализованном (но хорошо понятном человеку) виде описывает операции редактирования, которые нужно произвести, чтобы получить новую версию текста. С появлением этой утилиты пользователь, обнаруживший и исправивший ошибку в программе, мог прислать автору небольшую заплатку, по которой автор мог понять, какие изменения предлагаются, и автоматически «приложить» их к своему исходному тексту. С появлением утилиты «patch» гораздо больше пользователей стало включаться в разработку программ с доступным исходным текстом, немалую роль и здесь сыграла сеть [6] . В конце концов, данный способ исправления стал общеупотребительным и применяющимся не только к исходному коду программы, но и непосредственно к скомпилированному исполнимому коду в случае закрытого ПО, а слово «патч» стало [7]
Если пользователю программы нехватает в ней какой-то функции, то при должной квалификации он вполне может запрограммировать её сам и включить в исходный текст программы, либо заплатить за это кому‐то ещё. Естественно, ему выгодно, чтобы его дополнение попало в «главный», авторский вариант программы (его называют «upstream») и появлялось во всех последующих версиях: можно точно так же оформить его в виде системы управления версиями . Функции системы контроля версий состоят в том, чтобы организовать доступ к исходным текстам программы для нескольких разработчиков и хранить историю всех изменений в исходных текстах, позволяя объединять и отменять изменения и пр. [8] Самая ранняя свободная система управления версиями — RCS — использовалась ещё на заре свободного ПО абонентами сети Usenet, затем на смену ей пришла более развитая [9]
Место свободных программ на сегодняшнем рынке ПО очень значительно, и многие коммерческие и государственные предприятия используют свободное ПО прямо или опосредованно. Собственно, опосредованно все пользователи Интернета задействуют, например, свободную программу Linux . Выгода использования свободного ПО очевидна: за него не приходится платить, а если приходится — оно стоит гораздо дешевле коммерческих Intel или Философия [ ]
В европейской культуре долго вырабатывались правила собственности по отношению к [10] как противоречащая природе вещей. Неудивительно, что возникает множество неурядиц, каждую из которых приходится решать искусственными, а зачастую и противоестественными методами.
Например, приходится симулировать «ущерб из-за неполучения блага», который «наносится» «хозяину» программы при её безущербном копировании или возврате денег при обнаружении ошибок и дефектов в программах. Обычно это — «упущенная выгода», то есть та прибыль, которую хозяин мог бы получить, но не получил из-за того, что продукт скопировали. Приходится изобретать хитроумную аппаратуру, мешающую копированию или причиняющую при этом ущерб. Приходится вводить в законодательство особую категорию прав — условно назовём её «патент» [11] — ограничивающую злоупотребления — и свободу — всего человечества в пользу хозяина патента. Причём далеко не всегда хозяин патента и автор изобретения — один и тот же человек (в таких случаях противоестественность данных мер лишь усугубляется).
Несвободные программы называют « proprietary ) или «собственническими». Иногда их неправильно называют, просто, « коммерческими », что неверно: получать выгоду от программы можно различными способами, и многие успешные свободные проекты это подтверждают.
Миграция на свободное ПО [ ]
Основная статья: Распространённость свободного и открытого ПО [ ]
СПО используется в Министерстве юстиции Бельгии, в котором уже половина компьютеров работает под управлением Linux , и полицией Франции, которая к 2014 году планирует полностью перейти на 2009 года . Администрация Амстердама также изучает возможность перевода своих 10 тысяч рабочих мест на открытое ПО. [12]
По состоянию на 2009 год, открытым системам уже принадлежит большая часть (более 60 %) рынка мобильных приложений. По прогнозу Juniper Research, к 2014 году количество [13]
Свободное и открытое программное обеспечение в России [ ]
Решениями Дмитрия Анатольевича Медведева , отечественное открытое программное обеспечение в 2008 году планировалось внедрить во всех школах Российской Федерации и во всех государственных и бюджетных организациях для обеспечения национальной безопасности в сфере ИТ.
Независимо от вышеупомянутых государственных решений, свободное программное обеспечение, в любом случае, может свободно устанавливаться и использоваться на любых компьютерах. Использование такого ПО свободно везде: в школах, офисах, вузах, на личных компьютерах и во всех организациях и учреждениях, в том числе, и на коммерческих и государственных, в России и в странах СНГ .
В учреждения Министерства Обороны России, а также в российских посольствах в других странах используется операционная система Открытое программное обеспечение в школах [ ]
Решением правительства Российской Федерации в марте 2008 года , все средние школы России должны были получить базовые пакеты лицензионного собственнического и открытого программного обеспечения для обучения компьютерной грамотности, основам информатики и новым информационным технологиям с операционными системами Linux .
В трёх регионах России в 2008 году развёрнуты эксперименты по внедрению и использованию в средних школах базовых пакетов программ для кабинетов информатики и вычислительной техники, и начата подготовка учителей и преподавателей информатики к работе с открытым программным обеспечением в среде Windows и Linux. [14]
В 2007 году выпущены первые учебники информатики для вузов и школ для обучения информатике в соответствии с государственными стандартами образования со свободным и Сдерживающие факторы распространения [ ]
Пользователи, которые бы иначе предпочли свободное ПО несвободному, продолжают использовать несвободное по следующим причинам:
- В странах, где квест), машинный перевод, распознавание речи с большим словарём и, в меньшей степени, цифровой зеркальный фотоаппарат с принадлежностями — [15]
- Отрасли, в которых существуют платные или собственнические стандарты де-факто , — например, Linux — только посредством freeware -программ (в частности, для Windows у пользователя и так есть выбор из замыкания на поставщике ).
Примечания [ ]
См. также [ ]
- Открытое программное обеспечение
- Проприетарное программное обеспечение
- Free Standards Group
- Открытое аппаратное обеспечение
- Ссылки [ ]
Шаблон:FOSS раздела Википедии на русском языке. Оригинальная статья находится по адресу: Свободное программное обеспечение. Список первоначальных авторов статьи можно посмотреть в истории правок. Эта статья так же, как и статья, размещённая в Википедии, доступна на условиях CC-BY-SA .
Источник: vlab.fandom.com