По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Партнер данного материала Telegram-канал Админим с Буквой Тема статьи небольшая, но информация данная необходима для понимания ограничений на дисках в операционной системе Linux. В данной статье рассмотрим: Установка квоты Редактирование квоты Просмотр отчетов по квотам Квоты – это ограничения, налагаемые системным администратором на использование дискового пространства в операционных системах. Они позволяют гибко управлять ограниченным ресурсом для сервера свободным местом на жестком диске. Квоты можно устанавливать, как на отдельных пользователей, так и на группы пользователей. Для конфигурации и управления квотами используются следующие команды: quotaon – включение квоты quotaoff – выключение квоты edquota – редактирование квоты repquota - отчет по квотам У Windows Server, конечно намного богаче инструментарий по работе с квотами. Для этого выделена целый File Server Resource Manager, но в данной статье мы посмотрим, как это работает в Linux системах на примере Ubuntu Server. У меня есть смонтированый раздел /dev/sdc1 в папку /mnt/hard. Для того, чтобы работать с квотами, необходимо поставить пакет apt-get install quota. Для того, чтобы использовать квоты, нам необходимо добавить монтирование данного раздела в файл /etc/fstab. Добавляем следующую строчку: /dev/sdc1 /mnt/hard auto rw,user,auto,usrquota,grpquota 0 0 Где, раздел, куда монтируем, автоопределение файловой системы, раздел для записи, разрешаем монтирование пользователям, раздел будет монтироваться автоматически при старте системы и включаем пользовательскую квоту и групповую. Строка будет выглядеть как на картинке. Сохраняем и перезагружаем. Для начала выключаем все квоты, если они когда-нибудь ставились, для чистоты настройки quotaoff /mnt/hard. Следующая команда quotacheck – которая создаст квоту для пользователей и групп, у нее большой функционал, но мы ее используем именно в таком ключе. Квоту мы можем создать только полностью на примонтированный раздел – это связанно с файловой системой ext4. Существуют и другие файловые системы, в которых мы можем ставить квоты на папки и работать более гибко, например xfs. quotacheck –cug /mnt/hard. В данном случае мы квоту ставим полностью на раздел, который смонтирован в /mnt/hard. И как видим команда создала 2 файла aquota.group и aquota.user. Это файлы с настройками квот. Это двоичные файлы и при попытке их посмотреть, например, cat aquota.user мы увидим, нечто не читаемое. Для редактирования данных фалов настройки текстовый редактор не подойдет, и мы будем использовать отдельную команду edquota – u siadmin. Т.е команда -u указывает , что мы редактируем для пользователя и далее указывается непосредственно пользователь. Вот так выглядит редактирование. Мы видим, что здесь есть blocks – число 1К блоки, soft – мягкая квота, это квота, которую пользователь может превысить, но не более чем на неделю, hard – жесткая квота, это квота которую пользователь не сможет превысить вообще. Получается так, если пользователь siadmin поставит soft 10 и hard 30, и запишу файлик в 15КБ, то неделю моя квота терпит, а через неделю система скажет, что квота превышена и будет требовать очистки. Если создать сразу файл 40 КБ, то квота скажет, что нету места на жестком диске. Так же можно поставить квоту на inodes, т.е на уникальные идентификаторы файлов, каждому файлу присваивается уникальный идентификатор, следовательно, пользователь не может превысить их количество по квоте. Когда мы выполняем команду edquota, то для открытия открывается редактор, установленный по умолчанию. В данном случае редактор nano. Как было уже написано мягкая квота устанавливается на неделю и после чего начинает блокировать, если мы не уменьшили размер файлов или не уменьшили их количество, смотря какая квота была выставлена. Мы можем данный параметр изменить, выполнив sudo edquota –t. Думаю, открытый файл на редактирование, тут все интуитивно понятно. Меняем и сохраняем. Мы в файле /etc/fstab указали, что файловая система монтируется с применением квот, потом командой quotacheck создали квоты, а затем указали ограничения edquota. Но до сих пор квоты не включены, квоты не работают! Для того, чтобы квоты заработали используется команда sudo quotaon /mnt/hard. И как только мы эту команду дали, файлы созданные aquota.group и aquota.user будут отредактированы и квоты заработают. Чтобы посмотреть, как работают квоты, создадим файл текстовый. Но т.к монтировался раздел из под root, то необходимо сменить владельца папки /mnt/hard/. Это можно сделать командой chown siadmin:root /mnt/hard. И теперь спокойно можно создать файл touch test.txt. Теперь добавим в файл информацию несколько слов. edquota – u siadmin выполняем и видим, что число блоков изменилось. Добавим еще информации, еще раз поменяется количество блоков. Создадим еще один файл – изменится число inodes. Далее простым копирование увеличиваем количество файлов, пока не сработает квота. Соответственно мы одновременно можем использовать квоты и по размеру, и по inodes. Очень важный момент. Поднимаемся в корневую папку /. Команда sudo repqouta /mnt/hard покажет отчет по квотам. Есть еще интересная команда - man warnquota. Команда отправляет e-mail при превышении квоты. Но для этого необходимо настроить почтовый smtp сервер, который будет отправлять почту.
img
В семиуровневой модели OSI на различных уровнях имеются разные типы адресов. На канальном это MAC-адрес, а на сетевом это IP-адрес. И для того чтобы установить соответствие между этими адресами используется протокол Address Resolution Protocol – ARP. Именно о нем мы поговорим в этой статье. Адресация Адреса 2-го уровня используются для локальных передач между устройствами, которые связаны напрямую. Адреса 3-го уровня используются устройств, которые подключены косвенно в межсетевой среде. Каждая сеть использует адресацию для идентификации и группировки устройств, чтобы передачи прошла успешно. Протокол Ethernet использует MAC-адреса, которые привязаны к сетевой карте. Чтобы устройства могли общаться друг с другом, когда они не находятся в одной сети MAC-адрес должен быть сопоставлен с IP-адресом. Для этого сопоставления используются следующие протоколы: Address Resolution Protocol (ARP) Reverse ARP (RARP) Serial Line ARP (SLARP) Inverse ARP (InARP) Address Resolution Protocol Устройству 3го уровня необходим протокол ARP для сопоставления IP-адреса с MAC-адресом, для отправки IP пакетов. Прежде чем устройство отправит данные на другое устройство, оно заглянет в свой кеш ARP где хранятся все сопоставления IP и MAC адресов, чтобы узнать, есть ли MAC-адрес и соответствующий IP-адрес для устройства, которому идет отправка. Если записи нет, то устройство-источник отправляет широковещательное сообщение каждому устройству в сети чтобы узнать устройству с каким MAC-адресом принадлежит указанный IP-адрес. Все устройства сравнивают IP-адрес с их собственным и только устройство с соответствующим IP-адресом отвечает на отправляющее устройство пакетом, содержащим свой MAC-адрес. Исходное устройство добавляет MAC-адрес устройства назначения в свою таблицу ARP для дальнейшего использования, создает пакет с новыми данными и переходит к передаче. Проще всего работу ARP иллюстрирует эта картинка: Первый компьютер отправляет broadcast сообщение всем в широковещательном домене с запросом “У кого IP-адрес 10.10.10.2? Если у тебя, то сообщи свой MAC-адрес” и на что компьютер с этим адресом сообщает ему свой MAC. Когда устройство назначения находится в удаленной сети, устройства третьего уровня одно за другим, повторяют тот же процесс, за исключением того, что отправляющее устройство отправляет ARP-запрос для MAC-адреса шлюза по умолчанию. После того, как адрес будет получен и шлюз по умолчанию получит пакет, шлюз по умолчанию передает IP-адрес получателя по связанным с ним сетям. Устройство уровня 3 в сети где находится устройство назначения использует ARP для получения MAC-адреса устройства назначения и доставки пакета. Кэширование ARP Поскольку сопоставление IP-адресов с MAC-адресами происходит на каждом хопе в сети для каждой дейтаграммы, отправленной в другую сеть, производительность сети может быть снижена. Чтобы свести к минимуму трансляции и ограничить расточительное использование сетевых ресурсов, было реализовано кэширование протокола ARP. Кэширование ARP - это способ хранения IP-адресов и связанных c ними MAC-адресов данных в памяти в течение определенного периода времени, по мере изучения адресов. Это минимизирует использование ценных сетевых ресурсов для трансляции по одному и тому же адресу каждый раз, когда отправляются данные. Записи кэша должны поддерживаться, потому что информация может устаревать, поэтому очень важно, чтобы записи кэша устанавливались с истечением срока действия. Каждое устройство в сети обновляет свои таблицы по мере передачи адресов. Статические и динамические записи в кеше ARP Существуют записи статического ARP-кэша и записи динамического ARP-кэша. Статические записи настраиваются вручную и сохраняются в таблице кеша на постоянной основе. Статические записи лучше всего подходят для устройств, которым необходимо регулярно общаться с другими устройствами, обычно в одной и той же сети. Динамические записи хранятся в течение определенного периода времени, а затем удаляются. Для статической маршрутизации администратор должен вручную вводить IP-адреса, маски подсети, шлюзы и соответствующие MAC-адреса для каждого интерфейса каждого устройства в таблицу. Статическая маршрутизация обеспечивает больший контроль, но для поддержания таблицы требуется больше работы. Таблица должна обновляться каждый раз, когда маршруты добавляются или изменяются. Динамическая маршрутизация использует протоколы, которые позволяют устройствам в сети обмениваться информацией таблицы маршрутизации друг с другом. Таблица строится и изменяется автоматически. Никакие административные задачи не требуются, если не добавлен лимит времени, поэтому динамическая маршрутизация более эффективна, чем статическая маршрутизация. Устройства, которые не используют ARP Когда сеть делится на два сегмента, мост соединяет сегменты и фильтрует трафик на каждый сегмент на основе MAC-адресов. Мост создает свою собственную таблицу адресов, которая использует только MAC-адреса, в отличие от маршрутизатора, который имеет кэш ARP адресов, который содержит как IP-адреса, так и соответствующие MAC-адреса. Пассивные хабы - это устройства центрального соединения, которые физически соединяют другие устройства в сети. Они отправляют сообщения всем портам на устройства и работают на уровне 1, но не поддерживают таблицу адресов. Коммутаторы уровня 2 определяют, какой порт подключен к устройству, к которому адресовано сообщение, и отправлять сообщение только этому порту, в отличие от хаба, который отправляет сообщение всем его портам. Однако коммутаторы уровня 3 - это маршрутизаторы, которые создают кеш ARP (таблица). Inverse ARP Inverse ARP (InARP), который по умолчанию включен в сетях ATM, строит запись карты ATM и необходим для отправки одноадресных пакетов на сервер (или агент ретрансляции) на другом конце соединения. Обратный ARP поддерживается только для типа инкапсуляции aal5snap. Для многоточечных интерфейсов IP-адрес может быть получен с использованием других типов инкапсуляции, поскольку используются широковещательные пакеты. Reverse ARP Reverse ARP (RARP) - работает так же, как и протокол ARP, за исключением того, что пакет запроса RARP запрашивает IP-адрес вместо MAC-адреса. RARP часто используется бездисковыми рабочими станциями, потому что этот тип устройства не имеет способа хранить IP-адреса для использования при их загрузке. Единственный адрес, который известен - это MAC-адрес, поскольку он выжигается в сетевой карте. Для RARP требуется сервер RARP в том же сегменте сети, что и интерфейс устройства. Proxy ARP Прокси-ARP был реализован для включения устройств, которые разделены на физические сегменты сети, подключенные маршрутизатором в той же IP-сети или подсети для сопоставления адресов IP и MAC. Когда устройства не находятся в одной сети канала передачи данных (2-го уровня), но находятся в одной и той же IP-сети, они пытаются передавать данные друг другу, как если бы они находились в локальной сети. Однако маршрутизатор, который отделяет устройства, не будет отправлять широковещательное сообщение, поскольку маршрутизаторы не передают широковещательные сообщения аппаратного уровня. Поэтому адреса не могут быть сопоставлены. Прокси-сервер ARP включен по умолчанию, поэтому «прокси-маршрутизатор», который находится между локальными сетями, отвечает своим MAC-адресом, как если бы это был маршрутизатор, к которому адресована широковещательная передача. Когда отправляющее устройство получает MAC-адрес прокси-маршрутизатора, он отправляет данные на прокси-маршрутизатор, который по очереди отправляет данные на указанное устройство. Proxy ARP вызывается следующими условиями: IP-адрес назначения не находится в той же физической сети (LAN), на которой получен запрос. Сетевое устройство имеет один или несколько маршрутов к IP-адресу назначения. Все маршруты к IP-адресу назначения проходят через интерфейсы, отличные от тех, на которых получен запрос. Когда proxy ARP отключен, устройство отвечает на запросы ARP, полученные на его интерфейсе, только если IP-адрес назначения совпадает с его IP-адресом или если целевой IP-адрес в ARP-запросе имеет статически настроенный псевдоним ARP. Serial Line Address Resolution Protocol Serial Line ARP (SLARP) используется для последовательных интерфейсов, которые используют инкапсуляцию High Link Level Link Control (HDLC). В дополнение к TFTP-серверу может потребоваться сервер SLARP, промежуточное (промежуточное) устройство и другое устройство, предоставляющее услугу SLARP. Если интерфейс напрямую не подключен к серверу, промежуточное устройство требуется для пересылки запросов сопоставления адреса на сервер. В противном случае требуется напрямую подключенное устройство с сервисом SLARP.
img
Это подробное руководство предоставит вам информацию для эффективного сравнения лицензий Open Source, что должно помочь вам при выборе лицензии Open Source, подходящей для Вашего проекта. Итак, вы уже некоторое время работаете над крутым проектом – и вот вы готовы сделать важный шаг и превратить ваш закрытый код в открытый. Эта задача кажется несложной – просто почистить исходники и историю версий перед тем, как залить свой репозиторий на GitHub или Bitbucket... пока не всплывает вопрос о лицензии. Оказывается, выбор такой широкий. Какую лицензию выбрать? И нужна ли она вам вообще на самом деле? Можно коротко ответить на последний вопрос: да, вам действительно нужна лицензия. А на вопрос о том, какая лицензия вам нужна, мой ответ ещё короче: когда как. Но если вы серьёзно относитесь к своему проекту, вам, вероятно, потребуется немного больше деталей. Что ж, читайте дальше – и помните: вы вступаете на территорию бесконечных споров! Нужна ли мне лицензия? И что вообще такое лицензия? Лицензия – это официальное разрешение, предоставленное автором какой-либо работы («Лицензиаром») сторонним лицам («Лицензиатам») и регулирующее использование лицензиатом работы лицензиара. Она имеет форму договора, с которым должны согласиться обе стороны. В наше время - это согласие бывает неявным: подразумевается, что, просто используя какую-либо работу, вы соглашаетесь с условиями её лицензии на использование. Поясню: выпуская свою собственную работу, лицензиаром являетесь именно вы. А лицензиатом – любое лицо, использующее ваш код. Проще говоря, речь идёт о двух главных категориях: разработчиках и конечных пользователях. И для закрепления ещё некоторых терминов: модифицируя вашу работу, лицензиат создаёт то, что называется производной работой (производным произведением). Не все лицензии одинаково трактуют то, становится ли более масштабный по сравнению с вашей работой проект производным произведением, если она была использована в этом проекте. Как вы увидите ниже, некоторые лицензии отдельно прописывают такие случаи. Какова цель лицензии? В целом, лицензия – это способ договориться о правах и обязанностях сторон для лицензиара и лицензиата. Эти права и обязанности могут быть любыми – в рамках законодательства. К примеру, лицензиар может потребовать обязательного указания имени правообладателя при использовании работы лицензиатом. Или разрешить копирование своей работы, но запретить любую её модификацию. Или даже потребовать, чтобы производная работа выпускалась на тех же условиях, что и оригинальная. С другой стороны, лицензия защищает и лицензиата. Поскольку в ней явно прописаны условия использования работы, ему не угрожает то, что вы внезапно потребуете лицензионные отчисления или любые другие виды компенсации за использование своей работы. Это важно для распространения вашей работы. Итак, лицензия защитит вашу работу. Защитит лицензиата. Но помимо этого она защитит и вас – и я имею в виду вас лично. К примеру, ограничивая ответственность лицензиара за потенциальный вред, причиной которого стала его работа. А что, если я не буду использовать лицензию? При отсутствии лицензии, ассоциированной с работой, «по умолчанию» действуют авторские права в соответствии с юрисдикцией страны автора. Другими словами, никогда не считайте, что «отсутствие лицензии» подразумевает, что другие люди могут делать с вашей работой что угодно. Всё как раз наоборот: без определенной лицензии вы, автор, не отказываетесь ни от каких прав, предоставленных законом. Но всегда помните, что лицензия регулирует права и обязанности. Вы когда-нибудь задумывались, почему в тексте многих лицензий содержится написанное БУКВАМИ В ВЕРХНЕМ РЕГИСТРЕ предупреждение о гарантиях, предоставляемых вместе с продуктом – или, куда чаще, об отсутствии таковых? Это делается для того, чтобы защитить владельца работы от пользовательских ожиданий и того, что подразумевается какая-либо гарантия. Последнее, что вам нужно – это чтобы на ваш открытый код подали в суд! Могу ли я использовать кастомную (собственную) лицензию? Да, можете. Но, вероятно, не стоит этого делать. Являясь договором, лицензия не может иметь приоритет над территориальными законами. Отсюда возникает сложность соблюдения лицензионных прав в глобализированном мире. Скорее всего, будет проще (я имею в виду, менее сложно) защитить в суде «стандартную» лицензию. Собственно, такие дела уже защищались в некоторых юрисдикциях и на них можно ссылаться в качестве прецедента. Очевидно, что нельзя сказать то же про кастомную лицензию. К тому же, кастомные лицензии (прозванные «лицензиями для тщеславных») могут оказаться несовместимыми с другими лицензиями, результатом чего станет плохая совместимость вашей работы. Могу ли я использовать несколько лицензий? Да. Мульти-лицензирование – и в особенности двойное лицензирование – встречается нередко. Это особенно верно, если вы хотите создать бизнес на основе своего бесплатного произведения. В этом случае ваш проект, скорее всего, будет выпушен одновременно и под лицензией FOSS (Free And Open Source Software - Свободное и открытое программное обеспечение), и под коммерческой лицензией. Другое применение мульти-лицензирования – для улучшения совместимости, чтобы ваша работа была сочетаема с работами, опубликованными под другими условиями, или для удовлетворения иных потребностей и запросов пользователей. По этой причине некоторые проекты выпускаются под несколькими лицензиями FOSS. Но предупреждаю: не все лицензии совместимы между собой! Опять же, я рекомендую не переизобретать колесо и использовать лицензии, совместимость которых широко известна, если вы хотите пойти этим путём. Могу ли я поменять лицензию «позже»? Да. Держатель авторских прав отвечает за условия лицензирования. Довольно просто поменять лицензию, если вы – единственный автор. Но если, в качестве яркого примера, Линус Торвальдс захочет выпустить ядро Линукс под другой лицензией, ему, вероятно, сначала потребуется согласие нескольких тысяч других участников этого проекта. Это невозможно в действительности. Для проекта средней величины это реально. И на самом деле делалось, как вы увидите в некоторых примерах ниже. Какую лицензию Open Source мне следует использовать? Хорошо, допустим, мне удалось убедить вас в том, что вам нужна стандартная лицензия. Но какую выбрать? Окончательный выбор за вами. И в сети достаточно хороших компараторов, которые помогут вам в этом выборе. Вот некоторые их них: http://oss.ly/licdif https://choosealicense.com/ или https://choosealicense.com/appendix/ https://opensource.org/licenses https://tldrlegal.com/ Но как всегда в юридических вопросах, надежнее всего будет прочитать – и понять – официальный текст самих лицензий. Для этого может потребоваться помощь профессионального юриста. Рассмотрим некоторые общие сведения о наиболее распространённых лицензий, чтобы помочь вам сделать первые шаги в нужном направлении. Стандартная общественная лицензия GNU (GPL - GNU General Public License) GPL – одна из наиболее популярных лицензий Open Source. У неё есть несколько версий – но для нового проекта вам лучше рассматривать последнюю из них, на момент написания этой статьи ей является GPL 3. Поддерживая сильный копилефт, GPL, пожалуй, защищает больше всех остальных свободных лицензий. Что может быть, как плюсом, так и минусом, в зависимости от вашей точки зрения. Основной концепт GPL – что любые производные работы должны также выпускаться под этой лицензией. Copyleft - это практика предоставления людям права свободно распространять копии и измененные версии произведения с условием сохранения тех же прав в производных работах, созданных позже. Сильный копилефт; Лицензиаты могут модифицировать работу; Лицензиаты могут распространять исходный код вместе с производной работой; Производная работа должна выпускаться на тех же условиях. Популярные проекты GPL – лицензия, наилучшим образом подходящая для проектов Фонда свободного программного обеспечения (Free Software Foundation - FSF), в том числе за счёт инструментов GNU в основе любой системы Linux. Большие проекты – заведомо коммерческие – часто используют GPL вместе с одной или несколькими другими лицензиями. Inkscape (векторный графический редактор): GPLv2 Drupal (система управления веб-контентом): GPLv2 MariaDB (базы данных): GPL v2 MySQL (базы данных): GPL и коммерческая лицензия Qt (кроссплатформенный фреймворк для разработки приложений): LGPL, GPL и коммерческая лицензия— в зависимости от модулей и соглашения об уровне обслуживания (SLA). Меньшая стандартная общественная лицензия GNU (LGPL - GNU Lesser General Public License) GPL – лицензия, очень строгая к тому, чтобы каждая производная работа публиковалась на тех же условиях, что и исходная, и с открытым исходным кодом. Это особенно неудобно в случае с библиотеками, которые служат «кирпичами» для крупных программных продуктов: если библиотека выпущена под GPL, то любое использующее её приложение должно также выпускаться под GPL. Эту сложность адресует LGPL. В отношении библиотек Фонд свободного программного обеспечения (FSF) выделяет три случая: Ваша библиотека реализует стандарт, который конкурирует с несвободным стандартом. В таком случае широкое распространение вашей библиотеки поможет продвижению свободного ПО. В этой ситуации FSF рекомендует использование довольно либеральной (разрешительной) лицензии Apache (она описана в статье далее). Ваша библиотека реализует стандарт, уже реализованный другими библиотеками. В этом случае, полный отказ от копилефта никак не послужит продвижению свободного ПО. Для этого случая FSF рекомендует LGPL. Наконец, если ваша библиотека не конкурирует ни с какими другими библиотеками или стандартами, FSF рекомендует GPL. Рекомендации FSF имеют преимущественно этические и идеологические основания. В жизни у разработчиков могут быть иные заботы. Особенно если они планирует развивать дело на базе своей лицензированной работы. Ещё раз, возможно, в таком случае стоит присмотреться к двойному лицензированию. Слабый копилефт (из-за динамического связывания с библиотеками); Разрешено коммерческое использование работы; Лицензиаты могут модифицировать работу; Лицензиаты могут выпускать исходный код вместе с производной работой; Если вы модифицируете работу, её необходимо выпускать на тех же условиях; Если вы просто используете работу (в качестве библиотеки), нет необходимости выпускать производную работу на тех же условиях. Популярные проекты OpenOffice.org 3 (пакет офисных приложений): LGPLv3 — но Apache OpenOffice 4 перешёл на лицензию Apache 2.0. GTK+, the GIMP Toolkit (библиотека элементов графического интерфейса): LGPLv2.1 CUPS (кроссплатформенная система печати): GPL or LGPLv2, за исключением ОС Apple, — в зависимости от компонентов. WineHQ (слой совместимости с Windows): LGPLv2.1 GNU Aspell (проверка орфографии): LGPLv2.1 Eclipse Public License (EPL 1.0) С более слабым копилефтом, чем в LGPL, лицензия Eclipse больше подходит для бизнеса и допускает сублицензирование и создание программного обеспечения (ПО) на основе кода как под EPL, так и под другими лицензиями (даже проприетарными), с условием, что код под другой лицензией вынесен в отдельный модель программного продукта. Кроме того, EPL предоставляет дополнительную защиту соавторам кода под EPL в случае судебных исков/ущерба, вызванного коммерческой деятельностью, связанной с этой работой. Слабый копилефт (из-за связанных подключаемых в продукт модулей); Разрешено коммерческое использование работы; Лицензиаты могут модифицировать работу; Если вы модифицируете работу, её необходимо выпускать на тех же условиях; Если вы просто используете работу, нет необходимости выпускать производную работу на тех же условиях При коммерческом распространении продукта распространители обязаны защитить или выплатить компенсацию оригинальным авторам (под EPL) в случае судебных исков/ущерба в результате коммерческого использования продукта. Популярные проекты Очевидно, что EPL – наиболее подходящая лицензия для проектов Eclipse Foundation, в том числе Eclipse IDE. Но она прибрела некоторую популярность и за пределами этого – особенно в мире разработки на Java: Clojure (язык программирования) Graphviz (пакет утилит по визуализации графов) Jetty (сервер для приложений): двойная лицензия EPL1.0/Apache 2.0 с версии Jetty 7 JUnit (фреймворк для модульного тестирования ПО на Java) Mozilla Public License (MPL) MPL – лицензия, которая используется для ПО, созданного Mozilla Foundation. Но её применение этим не ограничено. MPL пытается достичь компромисса между строгими лицензиями (такими как GPL) и либеральными лицензиями (такими как лицензия MIT). «Лицензионной единицей» в MPL является исходный файл. Лицензиарам запрещено ограничивать права пользователей и доступ к любому файлу, на который распространяется MPL. Но один и тот же проект может содержать как файлы под MPL, так и файлы под проприетарной лицензией. Полученный в результате проект может быть опубликован под любой лицензией, при условии, что предоставляется доступ к файлам под MPL. Слабый копилефт (в связи с отдельными файлами); Разрешено коммерческое использование работы; Лицензиаты могут модифицировать работу; Лицензиаты должны упоминать соответствующее авторство работы; Лицензиаты могут распространять производную работу на других условиях; Лицензиаты не могут заново лицензировать исходный код под MPL; Лицензиаты обязаны выпускать исходный код под MPL вместе со своей производной работой. Популярные проекты Mozilla Firefox (веб-браузер), Mozilla Thunderbird (почтовый клиент): MPL LibreOffice (пакет офисных приложений): MPL 2.0 H2 Database Engine (база данных): MPL2.0 и Eclipse License 1.0 Cairo (2D графическая библиотека) MPL 1.1 или LGPLv2.1 Apache License 2.0 (ASL 2.0) С ASL мы попадаем в мир либеральных свободных лицензий. Но даже FSF в некоторых случаях рекомендует лицензию Apache. Лицензия Apache считается либеральной, поскольку не требует того, чтобы какие-либо производные работы выпускались на тех же условиях. Другими словами, это «не-копилефт» лицензия. ASL – единственная лицензия, которая используется для проектов Apache Software Foundation. Считающаяся удобной для бизнеса, она получила широкое распространение за пределами этой организации. Можно нередко увидеть проекты корпоративного уровня, выпущенные под этой лицензией. Не-копилефт; Разрешено коммерческое использование работы; Лицензиаты могут модифицировать работу; Лицензиаты должны упоминать соответствующее авторство работы; Лицензиаты могут распространять производную работу на других условиях; Лицензиаты не обязаны выпускать исходный код вместе со своей производной работой. Популярные проекты Android (операционная система): ASL 2.0 с некоторыми исключениями (особенно касательно ядра Linux) Apache httpd (веб-сервер): ASL 2.0 Apache Spark (кластерная вычислительная система): ASL 2.0 Spring Framework (фреймворк для создания корпоративных приложений на Java): ASL 2.0 MIT License Ещё одна очень популярная лицензия. Возможно, даже самая популярная. Устанавливая совсем немного ограничений на повторное использование, лицензия MIT может быть легко связана с другими лицензиями, будь то GPL или проприетарные лицензии. Не-копилефт; Разрешено коммерческое использование работы; Лицензиаты могут модифицировать работу; Лицензиаты должны упоминать соответствующее авторство работы; Лицензиаты могут распространять производную работу на других условиях; Лицензиаты не обязаны выпускать исходный код вместе со своей производной работой. Популярные проекты node.js (среда выполнения для JavaScript): MIT License jQuery (клиентская библиотека JavaScript): MIT License (до 2012, двойная лицензия MIT/GPL) Atom (текстовый редактор): MIT License AngularJS (JavaScript- фреймворк): MIT License SQLAlchemy (инструментарий SQL и объектно-реляционное отображение для Python): MIT License Лицензии BSD Лицензии BSD бывают трёх видов. Оригинальная лицензия «4-х пунктов», «пересмотренная» лицензия, состоящая из 3-х пунктов и «упрощённая» лицензия из 2-х пунктов. По духу все три очень близки к лицензии MIT. И действительно, между упрощенной лицензией BSD и лицензией MIT нет существенных различий. Лицензии BSD, состоящие из 3-х и 4-х пунктов, содержат больше требований в отношении повторного использования наименований и рекламы. Это полезно учесть, если вы хотите защитить название вашего продукта или марки. Не-копилефт; Разрешено коммерческое использование работы; Лицензиаты могут модифицировать работу; Лицензиаты должны упоминать соответствующее авторство работы; Лицензиаты могут распространять производную работу на других условиях; Лицензиаты не обязаны выпускать исходный код вместе со своей производной работой; Лицензиаты не могут использовать название продукта или торговую марку оригинального автора для продвижения своей производной работы (лицензии BSD из 3-х и 4-х пунктов); Лицензиаты обязаны упоминать оригинального автора работы во всех рекламных материалах, ссылающихся на функции или использование этой работы (лицензия BSD из 4-х пунктов). Популярные проекты Django (фреймворк для веб-приложений): лицензия BSD из 3-х пунктов Redis (хранилище данных): лицензия BSD из 3-х пунктов Ruby (язык программирования): лицензия BSD из 2-х пунктов и кастомная лицензия Nginx (веб-сервер): лицензия BSD из 2-х пунктов NetBSD (операционная система): лицензия BSD из 2-х пунктов — лицензия BSD «4-х пунктов» до 2008 В заключение о лицензиях Open Source Вы дочитали до этого места, поздравляю! Теперь вы понимаете, что лицензирование – это обширная и сложная тема. Но потратить время на то, чтобы выбрать подходящую лицензию для вашего проекта – стоит того, и лучше сделать этот выбор как можно раньше. Это убережёт вас от множества проблем в дальнейшем, и вы сможете направить ваше время и энергию на работу над проектом вместо того, чтобы тратить силы на разборки с авторским правом и юридической совместимостью лицензий. И помимо нескольких известных лицензий, о которых вкратце рассказано здесь, существует ещё множество других, используемых более или менее широко. Поэтому, не стесняйтесь писать в комментариях о том, какую лицензию вы предпочитаете и почему.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59