Уже не для многих является секретом тот факт, что Linux — это очень стабильная и безопасная операционная система. Подтверждение тому переход многих компаний и структур на эту «ось». Как пример могу привести Приват Банк, Fiat, Google, Panasonic, Virgin America, Amazon, Министерство обороны США, Deutsche Bahn, Hundai, BMW, Volvo, PayPal, Singapore Airlines и многие другие. Данный список слишком большой, чтобы его продолжать. Но разговор не о том. С ростом данной системы на нее начали обращать внимание взломщики и хакеры, ища  уязвимости системы. Самыми опасными являются руткиты, меньшую опасность представляют вирусы и трояны. В данной статье я опишу некоторые инструменты для поиска rootkit.

Утилита chkrootkit

Chkrootkit это набор инструментов, которые призваны для поиска руткитов в системе. Она может находить почти все существующие современные руткиты. Система сканирования Chkrotkit постоянно улучшалась, в результате чего увеличивалась скорость сканирования, что очень полезно во время глубоких проверок системы на наличие известных руткитов. Утилита может находить больше 60 устаревших и современных rootkit, умеет определять сетевые интерфейсы в promiscous-режиме (это «неразборчивый» режим, в котором сетевая плата может принимать абсолютно все пакеты, не смотря на то, для кого они были адресованы.), умеет очень эффективно находить измененные файлы lastlog и wtmp (это файлы, сообщающие сисадминам о вторжениях в систему). Chkrootkit — это консольная утилита с понятными параметрами, которая создает подробные результаты исследования системы.

Чтобы установить chkrootkit в систему. нужно выполнить следующую команду в Терминале:

sudo apt-get install chkrootkit

Для запуска утилиты нужно выполнить команду:

sudo chkrootkit

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

Параметры:

-h        Справочная информация о программе
-V        Версия программы
-l        Все поддерживаемые типы проверок
-d        Подробная информация (режим отладки)
-q        Минимальный вывод информации (будет выводится информация только о подозрительных файлах)
-x        Режим эксперта (вывод всех действий программы)
-r        Указать директорию, которая будет использоваться в качестве корневой

Для сохранения подозрительных файлов в текстовый файл нужно выполнить команду:

sudo chkrootkit -q > chkrootkit.txt

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

Утилита rkhunter

Простая, но эффективная консольная программа для обнаружения rootkits и malware в системе. Утилита также проверяет и выявляет изменения в установленных приложениях, в системных файлах запуска, а также производит разные проверки для утилит и программ, «слушающих» на сетевых интерфейсах сервера. Другими словами — это анти шпион для Linux.

Установим программу командой в Терминале:

sudo apt-get install rkhunter

Теперь обновим базы сигнатур:

sudo rkhunter --update

Теперь можно запустить сканирование:

sudo rkhunter --check

Наберитесь терпения и ждите окончания проверки. Во время сканирования несколько раз вас попросят нажать клавишу Enter. Также можно добавить утилиту в cron и к примеру производить сканирование системы каждый день в 23-00. Добавим задание в crontab. Как добавлять задания в crontab я уже писал в одной из своих статей.

0 23 * * * sudo rkhunter —update; sudo rkhunter —check

Rkhunter, как и chkrootkit, не удаляет найденные угрозы, а просто выдает отчет о сканировании.
В заключении хочу сказать, что мы имеем два неплохих инструмента для безопасности своей системы. Linux не Linux, но как говориться — лучше перебдеть, чем недобдеть. Всем удачи!

Филиал Fujitsu — PFU — анонсировал драйверы сканеров Fujitsu SP (SP-1120, SP-1125, SP-1130) под операционные системы на базе Linux. К сожалению, даже в 2016 году, бинарные драйверы — это всё, что мы имеем, касательно принтеров и сканеров.

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

В качестве централизованного сбора логов используется rsyslog, а для структурирования и визуализации elasticsearch + kibana. Все бы ничего, но когда количество подключенных машин разрастается, то данных настолько много, что уходит (уходило) большое количество времени на их обработку и анализ. Наряду с другими интересными штуками всегда хотелось организовать свой центр безопасности. Этакая мультимониторная статистика с картами, графиками и прочим.

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

Так как у нас уже есть развернутый elastic с kibana, то будем на его базе и городить нашу систему.

Итак, у нас уже есть установленный докер и docker-compose, значит будем поднимать сервисы на нем.

elastic:

elasticsearch:
  build: elasticsearch:2.3.4
  container_name: elastic
  command: elasticsearch -Des.network.host=0.0.0.0
  net: host
  ports:
    - "9200:9200"
    - "9300:9300"
  volumes:
    - "/srv/docker/elastic/etc:/usr/share/elasticsearch/config"
    - "/srv/docker/elastic/db:/usr/share/elasticsearch/data"
    - "/etc/localtime:/etc/localtime:ro"
  restart: always
  environment:
    - ES_HEAP_SIZE=2g

/srv/docker/elastic/elasticsearch.yml:

cluster.name: Prod
node.name: "central-syslog"
http.port: 9200
network.host: _non_loopback_
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: [
 ]
transport.publish_host: 0.0.0.0
#transport.publish_port: 9300
http.cors.enabled : true
http.cors.allow-origin : "*"
http.cors.allow-methods : OPTIONS, HEAD, GET, POST, PUT, DELETE
http.cors.allow-headers : X-Requested-With,X-Auth-Token,Content-Type, Content-Length
script.engine.groovy.inline.aggs: on

/srv/docker/elastic/logging.yml:

logger:
  action: DEBUG
  com.amazonaws: WARN
appender:
  console:
    type: console
    layout:
      type: consolePattern
      conversionPattern: "[%d{ISO8601}][%-5p][%-25c] %m%n"

kibana:

kibana:
  image: kibana
  restart: always
  container_name: kibana
  environment:
    SERVICE_NAME: 'kibana'
    ELASTICSEARCH_URL:  "http://x.x.x.x:9200"
  ports:
    - "4009:5601"
  volumes:
    - "/etc/localtime:/etc/localtime:ro"

logstash:

logstash:
 image: logstash:latest
 restart: always
 container_name: logstash
 hostname: logstash
 ports:
  - "1025:1025"
  - "1026:1026"
 volumes:
  - "/srv/docker/logstash/logstash.conf:/etc/logstash.conf:ro"
  - "/srv/docker/logstash/ssh-map.json:/etc/ssh-map.json:ro"
 command: "logstash -f /etc/logstash.conf"

Итак. Мы запустили эластик и кибану, но осталось подготовить логстеш к обработке логов от внешних серверов. Я реализовал вот такую схему:

rsyslog → logstash → elastic → kibana.

Можно было бы использовать встроенный в rsyslog коннектор напрямую в эластик, но нам нужны данные по полям и с geoip для статистики.

На серверах, подключаемых к мониторингу вносим в конфиг rsyslog (обычно это /etc/rsyslog.d/50-default.conf) вот такую запись:

auth,authpriv.*                 @@x.x.x.x:1026

Этой записью мы отправляем все события об авторизации на наш удаленный сервер (logstash).

Далее, полученные логстешем логи нам нужно обработать и оформить. Для этого создаем маппинг полей, чтобы на выходе нам было удобно работать (/srv/docker/logstash/ssh-map.json):

{
        "template": "logstash-*",
        "mappings": {
                "ssh": {
                        "properties": {
                                "@timestamp": {
                                        "type": "date",
                                        "format": "strict_date_optional_time||epoch_millis"
                                },
                                "@version": {
                                        "type": "string"
                                },
                                "username": {
                                        "type": "string"
                                },
                                "src_ip": {
                                        "type": "string"
                                },
                                "port": {
                                        "type": "long"
                                },
                        }
                }
        }
}

В ходе создания маппинга столкнулся с одним багом логстеша, а именно присвоению полю значения geo_point (при создании своего индекса выставляется значение у geoip.location — float), по которому в дальнейшем будет строиться heatmap на карте. Баг этот зарегистрирован и в качестве workaround мне пришлось использовать шаблон стандартных индексов logstash-*.

Итак, маппинг у нас есть. Теперь нужно подготовить конфиг logstash, чтобы он фильтровал входящие данные и в нужном формате отдавал в эластик (/srv/docker/logstash/logstash.conf):

input {
   tcp {
        port => 1026
        type => "security"
   }
}

filter {
  grok {
    match => ["message", "Failed password for (invalid user |)%{USERNAME:username} from %{IP:src_ip} port %{BASE10NUM:port} ssh2"]
    add_tag => "ssh_brute_force_attack"
  }
  grok {
    match => ["message", "Accepted password for %{USERNAME:username} from %{IP:src_ip} port %{BASE10NUM:port} ssh2"]
    add_tag => "ssh_sucessful_login"
  }
  geoip {
    source => "src_ip"
  }
}
output {
   if "ssh_brute_force_attack" in [tags] {
         elasticsearch {
                hosts => ["x.x.x.x:9200"]
                index => "logstash-%{+YYYY.MM.dd}"
                manage_template => true
                template_name => "ssh"
                template => "/etc/ssh-map.json"
                template_overwrite => true
         } 
   }
}

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

Итак. Логи ссш попадают в логстеш, он их обрабатывает и отправляет в индексы эластика. Осталось только настроить визуализацию:

— Открываем веб интерфейс по адресу x.x.x.x:4009/
— Переходим в Settings и добавляем работу с нашими индексами (logstash-*)

Далее нам нужно в kibana создать поисковые запросы, визуализацию и дашборд.

Во вкладке Discover после добавления индексов в kibana мы видим наши записи — все настроили верно.

В левой колонке мы видим список полей для фильтрации, с ними и будем работать.

Первым фильтром пойдет список атакуемых серверов:

— около поля host нажимаем add
— сохраняем поиск как ssh-brute-servers-under-attack (имя вариативно)

Вторым фильтром будет список атакующих стран:

— около поля geoip.country_name нажимаем add
— сохраняем как ssh-brute-countries (имя вариативно)

Третьим фильтром будет общее количество атак:

— переходим на вкладку Discovery
— сохраняем как ssh-brute-all

Итак, на финальном экране у нас будет отображаться четыре разных параметра:

1. Суммарное количество атак
2. Атакующие страны
3. Атакуемые серверы
4. Карта с указателями на атакующие хосты

Суммарное количество атак:

— переходим на вкладку Visualize
— выбираем тип визуализации Metric
— From saved search — ssh-brute-all
— Открываем Metric и меняем значение поля на — Суммарное количество атак
— Сохраняем визуализацию

Атакующие страны:

— переходим на вкладку Visualize
— выбираем тип визуализации Data table
— From saved search — ssh-brute-countries
— Открываем Metric и меняем значение поля на — Количество атак
— Теперь нам нужно соотнести поля и посчитать в таблице «уники». Нажимаем split rows
— Aggregation — terms
— Field — geoip.country_name.raw
— Custom label — Страна

Если все ввели верно, то загорится зеленая кнопка play, после нажатия на которую увидим примерно такую картину:

image

— Сохраняем визуализацию

Атакуемые серверы:
— переходим на вкладку Visualize
— выбираем тип визуализации Data table
— From saved search — ssh-brute-servers-under-attack
— Открываем Metric и меняем значение поля на — Количество атак
— Теперь нам нужно соотнести поля и посчитать в таблице «уники». Нажимаем split rows
— Aggregation — terms
— Field — host.raw
— Custom label — Сервер

Если все ввели верно, то загорится зеленая кнопка play, после нажатия на которую увидим примерно такую картину:

image

— Сохраняем визуализацию

Карта с указателями на атакующие хосты (самое интересное)

— переходим на вкладку Visualize
— выбираем тип визуализации Tile map
— From new search — Select an index pattern — logstash-*
— Открываем Geo Coordinates. Если все шаги были верными, автоматически поле Field заполнится geoip.location
— Переходим в Options
— Меняем хостинг карт (так как у MapRequest изменились условия и нужно получать токен и дополнительно что-то делать). Ставим галку в — WMS compliant map server
— Приводим все поля к параметрам:

WMS Url — basemap.nationalmap.gov/arcgis/services/USGSTopo/MapServer/WMSServer
WMS layers* — 0
WMS version* — 1.3.0
WMS format* — image/png
WMS attribution — Maps provided by USGS
WMS styles* — пусто

В итоге у нас должна отобразиться карта атак:

image

— Сохраняем визуализацию

Теперь у нас всё есть для того, чтобы сделать свой дашборд.

Переходим на вкладку Dashboard, нажимаем на Add visualization (плюс в круге справа сверху) и добавляем свои сохраненные визуализации на экран и сохраняем экран. Поддерживается Drag'n'Drop. В итоге у меня получился вот такой экран:

image

Теперь для подключения новых хостов к системе достаточно будет указывать у них передачу логов авторизации на сервер logstash и при возникновении событий хосты и информация будут добавляться на экран и в эластик.

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

Универсальная последовательная шина (Universal Serial Bus) или же просто USB — это промышленный стандарт, разработанный в середине 1990 годов для того, чтобы стандартизировать подключение периферии к компьютеру. Он заменил большинство интерфейсов и теперь является самым распространенным типом разъемов для потребительских устройств.

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

Различные типы USB

У многих мог сейчас назреть вопрос: «Если USB должен быть универсальным, то почему он имеет большое количество типов?». Дело в том, что все эти типы USB разъемов выполняют различные функции. Это помогает обеспечить совместимость в случае выпуска устройства с улучшенными характеристиками. Давайте рассмотрим наиболее распространенные виды USB портов.

  • Type-A — большинство кабелей имеют на одном конце коннектор этого типа USB, туда же относятся и кабели современных клавиатур и мышей. Этим же типом USB комплектуются персональные компьютеры и зарядные устройства;
  • Type-B — это порт используется для подключения принтеров и других периферийных устройств к компьютеру. Но в настоящее время он не распространен так, как распространен USB Type-A;

  • Mini USB — это был стандартный разъем для мобильных устройств до появления Micro USB. Этот разъем меньше стандартного, что и можно понять по его названию. Этот тип разъемов тоже немного устарел и был заменен Micro USB, но это не означает, что такие виды USB нигде нельзя найти;
  • Micro USB — на данный момент является стандартом для портативных устройств. Его приняли все крупные производители мобильных устройств, за исключением Apple. Но Micro USB постепенно начинают заменять на USB Type-C. Кстати, существуют различные виды Micro USB разъемов, но об этом поговорим чуть позже;
  • Type-C — такой кабель может иметь на обоих концах один и тот же коннектор. Заявлена более высокая скорость передачи данных и более высокая мощность по сравнению с предыдущими стандартами USB. Такой разъем использовала компания Apple для Thunderbolt 3. О USB Type-C мы поговорим чуть позже;

  • Lightning — не относится к стандарту USB, но является фирменным интерфейсом для мобильной продукции Apple с сентября 2012 года. Устройства же до этого времени использовали менее компактный 30-pin проприетарный разъем.

USB 3.0

Новый стандарт обеспечивает более высокую скорость передачи данных и при этом имеет обратную совместимость со старым стандартом. По форме USB 3.0 и USB 2.0 Type-A одинаковы, просто новый стандарт окрашен в синий цвет, чтобы отличить USB 3.0 от 2.0.

Но увеличение скорости будет только в том случае, когда разъем, куда вставляется кабель или флеш-накопитель должен быть USB 3.0, и сам кабель или флеш-накопитель должен иметь коннектор USB 3.0.

Также кроме USB 3.0 Type-A существуют и другие типы разъемов USB 3.0. Type-B и его Micro версия имеют дополнительные контакты, чтобы обеспечить более высокую скорость передачи данных, что разрушает совместимость этих разъемов со старыми версиями, но старые USB 2.0 устройства можно подключить в новые USB 3.0 разъемы, но прироста скорости вы не получите.

Micro USB

Если у вас есть Android устройство, то вам нужно иметь Micro USB кабель. Даже самые ярые фанаты Apple не могут избежать этого типа разъемов в портативных аккумуляторах, колонках и другом.

Также имеются деления на типы разъемов Micro USB. В основном используется Micro USB Type-B, Type-A особо не распространен, да и я его в реальной жизни никогда не видел. То же самое относится и к Mini USB.

Если вы начнете покупать много гаджетов, вы скоро начнете использовать разные провода для разных устройств, все равно же нет разницы. Так что вам не придется докупать дополнительные провода, если вы их не теряете и не рвете.

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

Также определитесь с длиной кабеля. В поездке короткий кабель удобен, но дома с таким вы будете сидеть на полу возле розетки. Длинный же кабель будет запутываться и всячески мешать вам. Для портативного аккумулятора у меня кабель длиной в 35 сантиметров, а кабель для зарядки смартфона дома длиной в 1 метр.

USB On-The-Go

USB On-The-Go (USB OTG) — это относительно новый стандарт, позволяющий вставлять в портативные устройства флеш-накопители, предназначенные для других USB интерфейсов, кабели, чтобы заряжать что-либо от аккумулятора вашего портативного устройства и так далее. USB OTG поддерживает не только USB Type-A, но и другие виды USB портов.

А теперь представьте, что у вас есть внешний жесткий диск, смартфон и ноутбук. Какие действия вы выполните для того, чтобы переместить какой-либо файл с внешнего жесткого диска на ваш смартфон? Самый простой способ — это сначала переместить файл с внешнего жесткого диска на ноутбук, а с него на смартфон.

А теперь представьте, что вы имеете USB OTG переходник. Просто вставьте переходник в смартфон, а в него кабель от внешнего жесткого диска. Необходимость в ноутбуке отпадает. Удобно?

К сожалению, не все устройства поддерживают USB On-The-Go, так что перед покупкой переходника советую вам проверить ваше устройство на поддержку USB OTG.

Переходники для Lightning существуют и они даже с версии iOS 9 везде работают, но называть это OTG как-то не особо хочется.

USB Type-C

Этот новый стандарт имеет большой задел на будущее. Во-первых, он быстрый и может передавать большие токи, во-вторых, его можно вставить любой стороной и на обоих концах провода может быть один и тот же коннектор.

В 2015 году компания Apple потрясла весь мир, выпустив MacBook с одним USB Type-C разъемом. Это может быть началом тенденции.

Сейчас существует немало устройств с USB Type-C разъемом. Для подключения к компьютеру стоит использовать USB Type-C — USB Type-A кабель, если у вас нет такого же разъема в компьютере.

Покупать дешевые USB Type-C кабели не стоит, совсем не стоит. Очень просто убить ваше устройство. К тому же по такому кабелю проходят большие токи, так что некачественный кабель еще и приведет к пожару. Не жалейте денег на качественный кабель.

Источник: losst.ru

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

Мы склонны называть все продукты с открытым исходным кодом одним термином, считать их одной категорией. Так удобнее, но это всего лишь упрощение. Фундаментальная концепция открытого кода понятна всем, но права, обязанности и привилегии сторон интерпретируются по-разному. Это отражается на лицензиях свободного ПО. В этой статье мы рассмотрим основные виды свободных лицензий, а также насколько они популярны.

Виды свободных лицензий ПО

Одна из самых распространенных лицензий программного обеспечения — лицензия GNU GPL. Ее суть во взаимности. Лицензия требует, чтобы если код был изменен, то все изменения были обязательно опубликованы и доступны всем. Это называется копилефт. Но есть другие типы лицензии, которые строятся вокруг свободы для разработчика. Такие лицензии накладывают минимальные ограничения на пользователей и не требуют взаимности от разработчиков. Оба типа лицензий свободны, разница только в том, что именно остается свободным.

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

Если сравнить долю каждой из лицензий по рейтингу Black Duck в этом месяце, по сравнению с январем 2010, то различие вполне очевидно:

В этом рейтинге самой популярной остается GPLv2, но она потеряла больше половины своей популярности, от 46% до 19%. За этот же период разрешительная лицензия MIT выросла от доли 8% до 29%. Apache License 2.0 выросла с 5% до 15%.

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

Консолидация. Это топ 10 лицензий по популярности за 2010 и 2016 год, все, кроме трех из них, снизились в популярности. Больше всего снизилась лицензия GPL, а выросли Apache и MIT, это уже обсуждалось. Но примечательно, что достаточно популярная лицензия BSD, наоборот, снизилась. Та же тенденция у лицензии ISC. Сейчас только несколько лицензий являются самыми популярными и, возможно, скоро мы будем видеть консолидацию между несколькими лицензиями.

Бинарный выбор. Исторически так сложилось, что у вас есть три основных варианта выбора лицензии: копилефт, разрешающая и среднее положение. К средним лицензиям можно отнести  LGPLv2.1 (4), LGPLv3 (2), EPL (1), MPLv1.1 (<1), CDDL (<1) и CDDLv1.1 (<1) они имеют общую долю порядка 7-8%. Теперь все больше и больше выбор сводится к копилефт или разрешающим лицензиям.

Без лицензии. Сколько бы ни говорилось об открытых лицензиях, но до сих пор остаются репозитории открытых проектов с кодом, не использующим ни одну из лицензий. Со временем процент лицензированных репозиториев сокращается:

Есть много объяснений этому явлению, например,безразличие разработчиков. Но все открытые программы без лицензии — это не открытое программное обеспечение и это плохо.

Основные лицензии свободного ПО

А теперь давайте сделаем краткое описание для каждой лицензии из рейтинга чтобы вы могли ориентироваться что они из себя представляют:

GNU General Public License. Расшифровывается как универсальная общественная лицензия. Была разработана в 1988 году в рамках проекта GNU. Принцип действия лицензии, как уже говорилось, все изменения кода должны быть опубликованы. Программа не может быть включена в проприетарное ПО, но зато может свободно распространяться между пользователей, изучаться и улучшаться при условии публикации улучшений. За время развития было выпущено три версии — GPLv1, GPLv2 и GPLv3, в которых были немного ослаблены ограничения лицензии gpl к проприетарному ПО.

MIT License. Это лицензия, разработанная Массачусетским технологическим институтом (МТИ). Это разрешительная лицензия, а это значит, что несмотря на свободность распространения, ПО может использоваться в качестве части проприетарных программ.

Apache License 2.0. Это еще одна разрешительная лицензия. Кроме того, что разрешается полностью свободно распространять продукт, программы можно встраивать в проприетарное ПО. Но нельзя изменять название, а в файлах нужно прикладывать всю информацию об изменениях и лицензии.

Artistic License — свободная лицензия, разработанная The Perl Foundation. Это копилефт лицензия, она требует чтобы все изменения были опубликованы, а в файлах были описаны вносимые правки.

BSD Licese 2.0. Лицензия на программное обеспечение университета Беркли. Лицензия очень похожа на MIT, и программное обеспечение тоже можно встраивать в проприетарные проекты. Но здесь нельзя использовать оригинальное название свободного проекта.

Code Project Open 1.0.2 License. Это лицензия, опубликованная сообществом разработчиков The Code Project. Она разрешает использовать исходный код и сами программы в коммерческих целях, код можно изменять и включать в другие проекты.

Mozilla Public License (MPL) 1.1. Эта лицензия была разработана в компании Netscape и улучшена в Mozilla Foundation. Разрешается использование кода в закрытых проектах, но измененный код должен быть лицензирован в соответствии с MPL.

Microsoft Public Licese (MS-PL) — это свободная лицензия, которая предоставляет право на использование, распространение и изменение кода. Но при распространении нужно сохранить информацию об авторских правах.

Понятие об отличиях основных лицензий свободного ПО на одной схеме:

Выводы

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

Небольшое видео по теме свободных лицензий и лицензии GPL:

Источник: losst.ru