закрытый исходный код что это
Программное обеспечение с закрытым исходным кодом (closed source software, проприетарное ПО)
Программное обеспечение с закрытым исходным кодом (closed source software, проприетарное ПО) — это ПО, все права на использование, изменение и копирование которого принадлежат его автору. В общем случае к программам с закрытым исходным кодом относят все разработки, не удовлетворяющие требованиям к свободному ПО.
Ограничения ПО с закрытым кодом
Авторы проприетарных программных продуктов контролируют доступ к исходному коду своих программ. Обычно такие разработки поставляются исключительно в виде исполняемых двоичных файлов и скомпилированных библиотек.
Как правило, лицензионное соглашение программы с закрытым кодом содержит положения, запрещающие ее декомпиляцию, а также любое изменение исходного кода.
Недоступность исходного кода — распространенное, но не обязательное свойство проприетарного программного обеспечения. В ряде случаев код может быть полностью или частично доступен, но его использование без разрешения автора будет неправомерным.
Владелец проприетарного ПО может:
Законодательство большинства стран предполагает проприетарность программного обеспечения по умолчанию. Создавая программу, ее автор автоматически получает полные права на ее распространение, модификацию и использование. При этом полный или частичный отказ от таких прав, напротив, должен быть подтвержден документально.
В противовес этому во многих случаях открытое ПО, в том числе и распространенные библиотеки, выпускаются по лицензии, которая обязывает делать любые продукты, использующие компоненты этого ПО, также открытыми. Это, например, не позволяет создавать ПО с закрытым кодом на базе Linux.
Публикации на схожие темы
Свободное железо — не панацея
TrueCrypt: необъяснимое исчезновение
Удаленные знакомства: кому мы доверяем свои данные
Уязвимость нулевого дня в диспетчере окон рабочего стола (CVE-2021-28310)
Дорога к «интернету вещей»: преимущества и риски смарт-езды
Открытый или закрытый исходный код скрипта, в чем разница?
Доброго времени, мои уважаемые читатели! Сегодня я немного расскажу о разнице открытого и закрытого кода программного обеспечения(ПО) и как это может отражаться на работе предпринимателей, которые покупают ПО для организации своих бизнес процессов. Несмотря на то, что предприниматель редко задается таким вопросом, этот момент не стоит упускать из виду, т.к. он может оказаться ключевым при возникновении потребности внести изменения в работу программного обеспечения.
В качестве вступления приведу небольшой пример истории из жизни. Предприниматель Екатерина Сергеевна, приобрела программное обеспечения для создания на его безе интернет магазина, на момент покупки Екатерину Сергеевну устраивало практически все, что касалось функционала приобретаемого ПО. В течении нескольких дней был запущен сайт, затем на протяжении месяца сайт наполнялся полезными статьями, писался раздел справки и помощи, активно добавлялись товары. Параллельно с этим была развернута рекламная компания, по привлечению клиентов в интернет магазин. Спустя 6 месяцев, сайт начал приносить доход, и перед предпринимателем встал вопрос о его улучшении, внесении ряда правок, чтобы сделать работу сайта лучше и эффективнее. Екатерина Сергеевна, обратилась к разработчику ПО, собственно у кого оно и было куплено. Но, как оказалось разработчик в данный момент занят, и не может заняться её проектом. Тогда, Екатерина обратилась к стороннему программисту, найти которого не составило большого труда. Подготовила подробный список того, что хочет изменить в своем сайте, и договорилась с ним, о начале работ. Но каково было удивление Екатерины, услышать от программиста ответ: «Я не могу реализовать ваши пожелания, т.к. исходный код ПО закрыт, я не имею к нему доступа». Работа встала.
Я очень часто наблюдаю такие ситуации, когда программа требует внесения доработок, а сделать этого нельзя, из-за того, что исходный код закрыт. Само понятие «закрытый исходный код» носит двусмысленный характер, оно может означать что:
1) код закрыт(скомпилирован, зашифрован, обфусцирован) и его нельзя посмотреть, а следовательно нельзя внести правки, изменения, дополнения;
2) код закрыт согласно лицензионному соглашению, такой код нельзя модифицировать(запрещено правообладателем) даже в том случае, если технически это возможно.
На фоне вышесказанного, возникает вопрос: кто может вносить изменения в работу такого программного обеспечения? Ответ — только разработчик, и то если пожелает, или вы сможете с ним договориться.
В свою очередь, открытый исходный код, лишен всех этих недостатков. Он может быть просмотрен, изменен, доработан и так далее, как правило лицензия по которой распространяется такое программное обеспечении разрешает пользователю модифицировать его любым образом, и если носит какие-то ограничения, то они как правило связаны с распространением его(программного обеспечения) копий.
Возвращаясь к истории предпринимателя Екатерины Сергеевны, в её случае решить возникшую задачу так и не получилось. Спустя год работы её сайта, накопилось очень большое количество изменений, которые требовалось внести в скрипты. Во первых её бизнес вырос, количество клиентов перевалило за несколько тысяч, и встал вопрос о добавлении на сайт различных сервисов: «расчет стоимости доставки», «личный кабинет», «отложенные товары» и т.д. Разработчик так и не смог выделить время на то, что-бы поработать с Екатериной (впрочем его винить за это не стоит, он изначально не оказывал услуг по доработкам, плюс ко всему таких запросов ему поступает ежедневно по несколько штук и он физически не способен их все удовлетворить), а сторонние программисты просто бессильны в данной ситуации. В итоге Екатерина приняла решение, полностью переделать весь сайт и в качестве платформы использовать уже ПО с открытым исходным кодом, это был её основной критерий к покупаемому продукту. Какие издержки она при этом понесла: покупка нового ПО, расходы по переносу базы клиентов, товаров, прочих материалов, работа по сохранению адресов страниц(что-бы не выпасть из индекса ПС) для сохранения позиций в поисковых системах, плюс её сайт простаивал некое время, и она также упустила часть выгод от возможных продаж. Все это обошлось её в крупную денежную сумму, потраченное время и нервы.
Данная история, это случай из жизни, из моей практики. Екатерина обратилась ко мне и мы славно поработали, впрочем еще многое предстоит сделать, ведь в голову постоянно приходят новые идеи, которые способствуют росту её бизнеса.
Что лучше открытое или закрытое ПО?
Однозначного ответа на этот вопрос нет, в ряде случаев закрытое ПО не чем не хуже открытого. Оно выполняет поставленные задачи, обеспечивая пользователя хорошим функционалом, таких примеров много iOS, Windows, MS Office и т.д. Но если речь идет о бизнесе, который зависит от ПО, и который со временем будет расти требуя внедрения новых идей, выбор однозначно падает на программное обеспечение с открытым исходным кодом!
Закрытый код
Проприета́рное, частное или собственническое программное обеспечение (англ. proprietary software ) — программное обеспечение, являющееся частной собственностью авторов или правообладателей и не удовлетворяющее критериям свободы ПО (речь именно о свободе, а не просто открытости ПО) и, с позиции Фонда свободного ПО, при этом не являющееся полусвободным ПО. Правообладатель сохраняет за собой монополию на его использование, копирование и модификацию, полностью или в существенных моментах. Часто проприетарным называют любое несвободное ПО, включая полусвободное.
Не следует путать с проприетарным коммерческое программное обеспечение, которое может быть и свободным. [1]
Содержание
Термин «проприетарное программное обеспечение» используется Фондом свободного ПО для определения программного обеспечения, которое с позиции Фонда не является свободным или полусвободным. [2] Технически, слова «собственническое» и англ. proprietary обозначают программное обеспечение, которое имеет собственника, который осуществляет контроль над ПО. Таким образом, этот термин может быть использован ко всему программному обеспечению, которое не находится в общественном использовании. Однако слово «proprietary» иногда используется в рекламе как положительное владельцами монопольных прав на что-нибудь. Так и Фонд Свободного Программного Обеспечения использует термин для выделения того, что собственник является основным фактором, в контрасте со свободным ПО, где этим фактором является свобода компьютерных пользователей.
Полусвободное ПО
Несвободное ПО, которое разрешает практически неограниченное использование, распространение и изменение (в том числе с распространением изменённых версий) ПО в некоммерческих целях, Фонд СПО называет полусвободным. [2] Как и Open Source Initiative и [2]
Средства ограничений
Предотвращение использования, копирования или модификации могут быть достигнуты правовыми или техническими средствами.
Технические средства включают в себя выпуск только машинно-читаемых двоичных файлов, ограничение доступа к читаемому человеком исходному коду (закрытый исходный код), затруднение использования собственноручно сделанных копий. Доступ к закрытому коду обычно имеют сотрудники компании-разработчика, но могут применяться и более гибкие условия ограничения доступа, в которых предоставление исходного кода разрешено партнёрам компании, техническим аудиторам или другим лицам в соответствии с политикой компании.
Правовые средства могут включать в себя коммерческую тайну, авторское право и патенты.
Типичные ограничения проприетарного ПО
Существует большое количество различных бизнес-моделей, и компании, занимающиеся разработкой проприетарного программного обеспечения, составляют собственные лицензионные соглашения в соответствии с ними. Наиболее типичные ограничения проприетарного ПО приведены ниже.
Ограничение на коммерческое использование
Существует огромное количество программных продуктов, разрешающих техническую поддержку со стороны специалистов, у которых отсутствует необходимость дополнительных затрат на обучение.
Если это — единственное значительное ограничение данного ПО, Фонд СПО считает это ПО полусвободным.
Ограничение на распространение
Этот вид ограничений сопровождает обычно крупные программные проекты, когда правообладатель требует оплаты за каждую копию программы. Обычно с таким ограничением используются программные продукты, ориентированные на узкий «профессиональный» сегмент рынка или у программного обеспечения, требующегося большому числу пользователей. Примером может служить пакет программ Adobe CS3 или операционная система Microsoft Windows XP.
Ограничение на модификацию
Этот вид ограничения используется только в программных пакетах с закрытыми исходными кодами и может запрещать или ограничивать любую модификацию программного кода, дизассемблирование и декомпиляцию.
Проприетарные форматы
Примечания
См. также
Полезное
Смотреть что такое «Закрытый код» в других словарях:
Код да Винчи (фильм) — Код да Винчи The Da Vinci Code Жанр триллер … Википедия
Код Да Винчи (фильм) — Код да Винчи The Da Vinci Code Жанр триллер Режиссёр Рон Ховард Автор сценария Акива Голдсман … Википедия
Закрытый исходный код — В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете … Википедия
Код аутентичности — MAC (имитовставка, англ. message authentication code код аутентичности сообщения) средство обеспечения имитозащиты в протоколах аутентификации сообщений с доверяющими друг другу участниками специальный набор символов, который добавляется к… … Википедия
Код аутентичности сообщения — MAC (имитовставка, англ. message authentication code код аутентичности сообщения) средство обеспечения имитозащиты в протоколах аутентификации сообщений с доверяющими друг другу участниками специальный набор символов, который добавляется к… … Википедия
ПЕРСОНАЛЬНЫЙ ИДЕНТИФИКАЦИОННЫЙ НОМЕР, ПИН — (англ. Personal Identification Number, PIN) – передаваемый банком эмитентом держателю платежной карты идентификационный секретный код (пароль). Применяется при совершении операции с картой и служит подтверждением того, что операция выполняется… … Финансово-кредитный энциклопедический словарь
Список свободных игр — Основная статья: Свободные игры Это список игр, исходный код которых является свободным программным обеспечением. Он включает несколько типов свободных игр: изначально выпущенных как свободные (free software) и бывших платных, код для которых был … Википедия
Android — У этого термина существуют и другие значения, см. Андроид (значения). Android … Википедия
Windows «Vienna» — Windows 7 Вид рабочего стола Windows 7 RC build 7100 Разработчик Семейство ОС Windows NT Исходный код Закрытый код Первый выпуск 22 октября … Википедия
Можно ли закрыть обратно открытый исходный код?
Эта концепция кажется довольно простой для любого человека, некоторое время работавшего с открытым исходным кодом: проект, однажды выпущенный в виде открытого кода, остаётся открытым навсегда. Конечно, разработчик может решить, что будущие версии проекта будут закрытыми, и иногда такое случалось, но то, что уже выпущено на свободу, отозвать обратно не получится. У интернета нет кнопки «удалить»; опубликовав свой код, и дав миллионам людей потенциальную возможность скачать его, загнать джина обратно в бутылку не получится.
Но что насчёт уважительных причин? Что, если проект превратится во что-то, к чему вы больше не хотите иметь отношения? Возможно, вы отправляли свой код для проекта, имея представление о том, как его будут использовать, а потом правила поменялись. Или же вас забанили на этом проекте, и при этом у людей, поддерживающих его, нет проблем с тем, чтобы оставить ваш значительный вклад в виде кода, даже когда вас выкинули на обочину?
Из-за того, что некоторые люди считают вынужденным изменением в правилах поведения разработчиков Linux, у некоторых разработчиков наиболее исключительного проекта с открытым кодом в мире возникают вопросы. С такой ситуацией сообществу приходится сталкиваться редко, и такого ещё никогда не случалось с проектом подобного масштаба.
Действительно ли невозможно отозвать исходный код, отправленный в проект, выпущенный под такой свободной и открытой лицензией, как GPL? А если можно, то что тогда будет? Что случится, если окажется, что миллиарды устройств, исполняющие у себя ядро Linux, нарушают интеллектуальные права одного разработчика? Эти вопросы крайне важны для интернета и, вероятно, даже нашего образа жизни. Однако ответы на них найти не так легко, как вам могло бы показаться.
Копилефт и права на владение
GPL известна как лицензия с копилефтом, добавляющая прав конечным пользователям, которые без этого оказались бы ограничены законами об авторских правах. Она, к примеру, даёт пользователю права копировать работу и создавать её производные. Важный момент: такие копилефт-лицензии, как GPL, не заменяют копирайта – они его лишь дополняют. Права на оригинальный код остаются у его автора, и, в итоге, основного владельца.
Это порождает концепцию двойного лицензирования: единственный автор программы может выпустить её под несколькими лицензиями одновременно, причём обычно одна из них позволяет делать с программой больше остальных. К примеру, версия программы для Windows может иметь закрытый код, а для Linux – открытый, даже если сам код программ не отличается. Чаще это используется для того, чтобы под одной лицензией программу использовали в коммерческих целях, а под другой, более свободной – в личных.
У некоторых проектов с открытым кодом, обычно больших и имеющих поддержку корпораций, иногда встречается Contributor License Agreement. Этот документ описывает все необходимые дополнительные требования и правила по добавлению кода в проект, и обычно содержит пункт, объясняющий, что человек, вносящий код, передаёт право на него владельцу проекта. К примеру, вот часть такой лицензии от Google:
По правилам и условиям данного соглашения вы передаёте Google и получателям ПО, распространяемого компанией, бессрочные, всемирные, не эксклюзивные, бесплатные, не требующие отчислений, безотзывные права на воспроизведение, создание производных работ, публичную демонстрацию, публичное исполнение, повторное лицензирование и распространение вашего вклада и производных работ от него.
Стоит отметить, что Linux не использует такое соглашение, поэтому права на любой внесённый разработчиком код остаются за ним.
Репутационные потери
Так что если разработчик свободен в выборе лицензий для распространения своего кода вплоть до диаметрально противоположных (открытый и закрытый код), и общепризнано, что в отсутствии CLA у него остаётся неоспоримое право на написанный им код, то ситуация становится щекотливой. Разве из этого не следует, что у разработчика остаётся право отозвать своё обещание сделать код открытым, если возникнет ситуация, которая заставит его считать, что код уже не стоит открывать?
Эрик Рэймонд
Эрик Рэймонд, один из основателей инициативы открытого кода, Open Source Initiative, и автор трилогии «Собор и Базар», считает, что у них такое право есть. В записи в списке рассылки Linux Kernel Эрик, в частности, обращается к угрозе, сделанной некоторыми разработчиками, по поводу отзыва их исходного кода из ядра:
Для начала позвольте мне подтвердить, что это не пустая угроза. При основании Open Source Initiative я изучал связанные с этим законы. В США существует прецедентное право, подтверждающее, что репутационные потери, связанные с преобразованием прав участника проекта под GPL, могут рассматриваться в суде. Я не знаю о существовании прецедентного права вне США, но в странах, соблюдающих Бернскую конвенцию без поправок США на «моральные права» [после присоединения к Конвенции США заявили, что моральные права уже защищаются положениями о клевете и, соответственно, не требуют дополнительного регулирования / прим. перев.], эта статья конвенции, вероятно, ещё больше упрочит позицию противников в суде.
Секция 6 Бернской конвенции поясняет, что изначальный автор работы, даже передав свои права другому лицу или организации, может возражать против её использования, если ему кажется, что её используют «в ущерб его чести и репутации». Так что, в теории, недовольны разработчик должен лишь убедить судью, что руководители проекта навредили его репутации, допустим, публично забанив за нарушение правил поведения, в результате чего тот может обязать проект прекратить использовать их код вне зависимости от использовавшейся лицензии.
Критика
При этом действие лицензии, предоставленной вами третьим лицам, получившим от вас копии или права согласно этой лицензии, не будет прекращено, пока эти лица будут полностью соблюдать её условия.
Все права, предоставленные согласно Данной лицензии предоставляются на срок действия авторского права на Программу, и не могут быть отозваны при условии, что установленные условия соблюдены.
Некоторые считают, что это отличие может оказаться критически важным. Юридически «отзыв» обычно означает, что соглашение было отозвано тем, кто его предлагал (тут – изначальный разработчик), а «прекращение» просто означает конец действия соглашения. В результате остаётся пространство для интерпретаций, и в принципе, можно утверждать, что поскольку в GPLv2 не указано, что разработчик не может отзывать свои права, эта возможность сохраняется.
Неизученные территории
С учётом оценки Эрика Рэймонда, по которой разработчик может заявлять о том, что проект, в котором он участвует, порочит его репутацию, и того факта, что в текущей лицензии Linux разработчикам напрямую не запрещено отзывать свой вклад, ситуация становится туманной, и пока никто ни в чём не уверен. Мы находимся в неизведанной местности, и старые предположения могут не выдержать юридической экспертизы.
Также стоит упомянуть, что в игру может вступить такая юридическая концепция, как «эстоппель» – она, по сути, запрещает лицу забирать назад своё обещание, если другое лицо уже предприняло шаги на основании этого обещания. То есть, если вы сказали кому-то, что он может использовать ваш код, и он использовал его для создания успешного проекта, вы не можете передумать, поскольку тем самым нанесёте ему ущерб.
С практической точки зрения, даже если бы человек смог защитить свою точку зрения в суде, требуя удалить свою часть кода из Linux, это было бы физически невозможно сделать. И тогда вместо возможности удалить код из устройств, которые с этого момента нарушают авторские права, упомянутый разработчик, скорее всего, получит некоторое денежное вознаграждение. Что всё равно станет ужасным прецедентом для открытого сообщества: обиделся – получил компенсацию.
В итоге, разговоры об отзыве лицензий на открытый код ошибочны. Перефразируя Иена Малькольма, персонажа «Парка Юрского периода»: обиженные разработчики так заняты размышлениями о том, могут они это сделать или нет, что у них не остаётся времени подумать о том, должны ли они это делать вообще. После появления легального прецедента, по которому разработчик может отозвать свой код из открытого проекта, открытое сообщество будет разрушено. У открытого ПО ушли десятилетия на то, чтобы достичь сегодняшнего процветания, но поспешные действия нескольких несчастных разработчиков могут утащить его обратно в область идей, которые лишь хочется воплотить в жизнь.
Открытый исходный код — благо или троянский конь?
Сразу хочется сузить рамки — разговор идет о продаже программного продукта (php+MySQL).
Вопрос — (про)давать ли исходный код?
Аргументы в пользу закрытого кода.
— Подавляющему большинству клиентов нужно чтобы продукт работал и исходный код не нужен.
— При закрытом коде проще осуществлять тех. поддержку — клиент своими руками не залезет куда не надо и не породит новых уникальных ошибок, в которых хрен разберешься.
— Сложнее стырить исходный код. А точнее его можно получить, но вот что-то серьезное переделать в этом «исходнике» сложно — максимум сломать защиту, внести незначительные правки.
— Есть некоторая надежда разработчика, что закрытый код спасет от перепродажи его продукта лихими людьми.
— Есть легкая надежда, что купят продукт, потому как «сломать» не смогут, либо «ломанный» побоятся использовать.
— Народ (наш народ 🙂 ) привык что если код открыт, значит бесплатно!
Аргументы в пользу открытого кода.
— Иногда клиенту просто хочется иметь возможность взглянуть на код. То есть не обязательно даже его иметь, но чтобы возможность такая была. Это могут быть параноики безопасности в хорошем смысле или просто борцы за какие-то права.
— Клиент имеет возможность внести правки, причем весьма серьезные. Вплоть до потери совместимости с последующими версиями продукта (хотя вот это возможно уже в минус).
— Нет проблем с дешифратором закрытого кода. Не секрет, что такие проблемы встречаются (отсутствие Зенда и иже с ним, какие-то локальные глюки т.д.).
— Есть возможность построить сообщество разработчиков купивших скажем девелоперскую лицензию с доступом к открытому коду.
Добавлю немного конкретики.
Вопрос «открытого кода» интересует в связи с «внутрифирменной» дискуссией по поводу развития одного из наших продуктов (CNCat). Мы проходили разные стадии (открытый код, Зенд) и сейчас осуществляем обфрускейтивание (замену названий переменных на бессмысленные) и легкую шифрацию. Когда мы давали продукт в открытом коде и давали его бесплатно — много кто тырил код и на его основе делали свои продукты без всяких ссылок на нас. Что было немного обидно и сейчас не хочется на этом обжечься опять.
Однако правильное позиционирование открытого кода (АПИ, поддержка, контроль и т.д.) может дать нам приток сторонних разработчиков новых фич, мощную обратную связь, отладку — в общем новый импульс.
Дык хочется получить какие-то дополнительные аргументы или мысли по данному вопросу. Как бы Вы повели себя как клиент, как разработчик (конечно желательно чтобы Вы им являлись, чтоб не голословно)? Может есть какие в мире устоявшиеся теории и доказанные практикой подходы (типа фри версия закрыта, купленная открыта)?