Что вообще значит свободный софт?

Прости, но я не буду слушать лекцию на 30 минут)

И вообще пойду уже поработаю, пока торвн меня не выбесил повторно)

Openstack разворачивается на утюге с помощью коллекции баш-скриптов.

Openshift разворачивается в виртуалке через minishift

Тем не менее основанный на OpenStack сервис по предоставлению публичного облака, или managed kubernetes от Амазона не являются по существу ни свободными, ни открытыми.

У абби есть юрлицо в США и Европе, да и просто код подведут при желании.

А какоё твоё видение путей эволюции по этому поводу?

Амазон поставляет не OpenStack, а услугу. Услуга и не будет свободной. С услугой уже сложнее всё. Если делать и услуги свободными, то мы получим настоящий коммунизм/социализм. Но общество к этому не готово.

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

А когда есть свобода замены, то открытая альтернатива выиграет сама по себе, без необходимости её форсить

Я могу понять, что неохота переходить дорогу корпорации в РФ, потому что они могут придумать разные способы давления.

Но рассуждая чисто в юридической плоскости я не вижу как бы абби хоть в США, хоть в РФ хоть сколько-то законным образом могли бы помешать писать и выкладывать современный код OCR.

В штатах патент на алгоритм возможен, если мне память не изменяет

В РФ нет

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

А это, кстати, очень даже дельная мысль.

У США очень длинные руки.

Т.е. запретить шифрование? Я правильно понял? Так как нормальные сервера между собой данные шифруют от третьих лиц.

В штатах патент на алгоритм возможен, если мне память не изменяет

Даже в США на чисто алгоритм - нет, там все тоже в итоге подводится именно под конечное устройство.

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

Более того, частное изготовление для себя в некоммерческих целях вообще не преследуется.

Поэтому даже в США возможно писать программы, реализующие запатентованные вещи (мультимедиа как наиболее популярный случай), но готовые бинарники приходится распространять из разных сторонних юрисдикций.

И собственно одна из причин почему я считаю GitLab проблемным сервисом, это то что несмотря на формальную открытость они пилят lock-in платформу для разработки.

Там тяжело работать с другими CI-системами, или с другими багтрекерами, или с другими системами управления проектов.

Я не могу получить от GitLab только git-хостинг. Залезешь для хостинга, а получишь привязку всего навсегда.

Ну чтобы на таком уровне действовать у абби точно руки не выросли.

На таком не выросли, но поднасрать если захочешь поехать в другую юрисдикцию, где патент на алгоритм работает смогут.

Идея звучит заманчиво, но как ее реализовать? Ведь вся суть облачных сервисов - в удаленности, устройство может находиться в другом городе/стране, я лично не вижу способа контролировать его на расстоянии так же, как это делает находящийся рядом

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

Нет, удаленность существовала задолго до облачности.

Облачность - это динамика и перенос некоторого слоя конфигурации приложения с уровня сервера на уровень распределенной инфраструктуры.

То есть допустим тебе надо было настроить DNS, ты идёшь и ставишь пакет bind на свой сервер. Сервер может находиться где угодно, в ДЦ. Но ты ставишь пакет на свой сервер.

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

И тут как раз вот вопрос: а что именно так плохо в этом сценарии? Какие свойства развертывания систем мы потеряли перейдя на облачные абстракции. Для начала бы их надо сформулировать и перечислить, и уже после этого можно будет думать о том как их вернуть.

Кто бы её Лёне Поттеру рассказал!

В первую очередь, свойство прозрачности,как ты сама заметила

получаешь только абстракцию, которую ты не можешь проследить вглубь

Но так как это является прям следствием перехода в облако, я абсолютно не вижу, как можно все вернуть. Тут на двух стульях усидеть не получиться, или тратишь время, делая все сам, или доверяешь облаку, не тратишь время, но при этом и уверенности в том, что оно точно делает, нету

отрицание.... Дальше будет гнев...

Тезис - «миллионы глаз проверяют» вылетает в трубу, это если мы о свободном (понимайте свободное как хотите) ПО говорим. Иными словами SaaS это выглядит удобно, выглядит ли это безопасно - вопрос спорный

Но так как это является прям следствием перехода в облако, я абсолютно не вижу, как можно все вернуть.

У нас есть Infra as a Code, и CI/CD. Это относительно новые но достаточно мощные инструменты. Ansible вон взлетел с такой скоростью, что сам от этого в ужасе и никак себя обратно не соберет.

И например та же опенстековская инфра, она непростая, но она прозрачная в том плане что все изменения в ней проходят через code-review, коммит в репу с конфигами или в скрипты для развертывания. И потом этот коммит выкатывается на инфру.

Что если ты бы пользовался сервисом в котором ты мог бы участвовать на таком уровне?

Читал тут давеча доку на ostree.

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

И вот допустим вносим мы Infra as a Code как критерий открытости и прозрачности. Все девопсы сразу автоматически оказываются на нашей стороне.

И разговор с тем же Амазоном можно уже строить не по принципу: ааа, вы зарабатываете больше денег чем я, как вам не стыдно!!!

А по принципу: знаете ли, ваш сервис кажется мне подозрительным. Может у вас там и автоматизации-то никакой нет, а вы перекладываете сервера из одной кучки в другую силами складских рабочих? А придерживаетесь ли вы вообще современных практик работы с большими инфраструктурами? И что у вас там с безопасностью supply chain? Нам отсюда не видно.

Ну и в таком случае Амазону может стать проще открыть доступ и конфиги чем публиковать каждую неделю маркетинговые материалы про то какие они безопасные и надежные.

Что вкладывается в это понятие?

Так мы упрёмся в извечный спор открытый/свободный/бесплатный.

Только лицензия?

Просто лицензия всё упрощает.

Правильно ли называть свободным всё что выпущено под одобренными FOSS-лицензиями?

Пусть сначала покажет свой сертификат одобрителя.

Достаточно ли одной только лицензии для того чтобы софт считался свободным, этичным, и т.п.? Должна ли это быть copyleft-лицензия?

Не, точно не copyleft. Отчуждение прав только в общественное достояние.

Как вписать сюда встраиваемые устройства, приватность, облака и микросервисы?

Смешивай как хочешь – свободный софт. Нет – закрепощённый софт.

Свободный - со свободной copyleft лицензией.

Этичным быть не обязан, это отдельное понятие.

Свободный софт - да, только лицензиями, это понятие ими и было создано.

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

Приватность - тема отдельная. Облаками не обеспечивается ни коим образом. Всё - на честном слове.

Если облака под AGPL - открыть исходники сервиса. Исходники инфраструктуры, использующейся сервисом, а также конкретные конфиги (если не содержат скрипты, влияющие на логику) - открывать не обязательно, и даже не стоит, в случае секретов.

Свободный софт в наиболее полной форме уже описан. Дальше можно расширять понятиями «Свободное железо» и «Свободная инфраструктура».

Херня. Если программа имеет исходники, позволяющие запустить её в полном объёме (и соответствующую лицензию, ограничивающую сужение свободы дальнейшим пользователям) - она свободная. Если вокруг одни аутисты - это проблемы аутистов.

Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying.

Это требование закрывает твой софт? Если софт - кусок дерьма, но при этом выполняет условия лицензии - он свободный.

Свободный софт - понятие, введенное с разработкой GNU GPL лицензии. Юлить не надо.

Исправит. Потому что тот, кому не пофигу, сможет собрать, модифицировать и запустить проект на своей инфраструктуре.

То, что он не сможет сделать это эффективно (из-за недостатка знаний) - никого не волнует. Разработка инфраструктуры - работа. А за работу надо платить.

Сможет разработать свою высокоэффективную инфраструктуру - сможет подвинуть монополию.

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

И это твои фантазии :)

Corresponding Source conveyed, and Installation Information provided

Это требование закрывает твой софт?

Очевидно нет.

Начать с того что сейчас нет понятия installation, есть понятие deployment

сейчас нет понятия installation, есть понятие deployment

Ну, это не мне надо доказывать, а американскому суду. Если суд постановит - что это разные вещи - лицензию обновят. Для такой вот юридической защиты FSF и существует.

Дальше можно расширять понятиями «Свободное железо» и «Свободная инфраструктура».

свободное государство

Так, вот утопию нам тут только не надо.

свободное государство

Поделил на нуль.

Подмена понятий. GPL - про свободу пользователя, а не право присваивать себе чужое. Это как раз обязанности разработчиков, мейнтейнеров, дистрибьюторов и всех остальных технарей «что делать, чтобы пользователь сохранил свободу». Проприетарное ПО часто монетизируется на ограничении свободы пользователя.

И это логично - у реально нужного ПО на одного разработчика тысячи и более пользователей + разработчики сами выступают в роли пользователей (но не наоборот).

Я сам об этом мечтаю не первый год, но революция всё откладывается.

Это могло бы перевернуть чуть ли не половину мировой экономики с ног на голову. Стихийное начало массового производства чего-либо без компаний-корпораций, группой энтузиастов с маленькими вложениями от каждого участника…

Здесь либо «человеческая жадность всё погубит» либо компетентный фантаст так распишет, что люди будут готовы на революцию во имя нового «изма» (типа орудия труда в руках народа - это отсутствие заводов, вместо них универсальный мультистанок в каждый дом - такая же необходимость, как и личная кровать. И всё ради материальных благ и невиданной роскоши всем очень дёшево). Причём с оппозицией в виде условной «Поднебесной», которая якобы скорее запустит всё своё ЯО, чем допустит эту революцию. Но фантазировать сценарии третьей мировой - дело безблагодатное.

По-сути нужно лишь внедрить в головы инженеров и в код свободных CAD’ов парадигму «используй чужие наработки в инженерии также легко, как и чужие библиотеки и фреймворки в коде». Причём в случае реализации этого CAD’ы станут сложнее не более, чем на 50% (для мировой революции это пустяк).

Проще говоря, «бедняки нового мира будут богаче и могущественнее многих королей прошлого».

Что-то меня понесло… Не даёт мне покоя идея производить сложные вещи нажатием пары кнопок.

Собственно не моя идея, но есть о чём подумать

https://youtu.be/CH4vgihEg6M?t=786

Суть в том что копирование облачного сервиса имеет мало смысла. Сервисы уникальны по своей природе. Но можно открыть сервис так чтобы его можно было править прямо на месте.

И тогда для него возможна совместная разработка. А там где возможна совместная разработка, возможно и совместное управление.

Это наверное ближе к Open Source чем к Free Software, но для начала пойдет. А дальше можно развивать.

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

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

То есть например захотел ты баннер подвинуть на три пикселя влево в дашборде своего облака, направил merge commit, получил результат тестов, ревью, замерджили и выкатили.

Без ожиданий следующего релиза. Без процедуры апгрейда сервиса на новую версию. Выкатка непосредственно в прод.

Хорошо, но как это поможет простым пользователям, не разработчикам, лучше контролировать облака?

Суть в том что копирование облачного сервиса имеет мало смысла. Сервисы уникальны по своей природе.

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

Представь себе условный github/gitlab, но в котором бизнес-логика приложения не прибита к конкретной машине, облаку или компании, а находится в виртуализованном слое. Не в таком закрытом виртуализированном слое, как дают облака типа амазона, а в полноценном, для выноса куда угодно.

Возьмём аналогию из ZeroNet и IPFS.

До появления этих инструментов понятия «хостинг сайта» и «контроль сайта» не были разделены. Там, где сайт хостится, в том же месте он управляется. Ты на машине хостера - просто гость, заходящий по паролю, а хостер и есть настоящий хозяин, кто имеет возможность сделать с сайтом что угодно, не считаясь с твоей волей.

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

Перенесём эту аналогию на сервисы. Представь, что этот «гитхаб» больше не привязан ни к учётным записям, контроллируемым GitHub Inc., ни к конкретным серверам, ни даже к конкретному коду реализации. Это полностью «приложение», работающее с «данными». Где исполняется «приложение»? В виртуализированной сетевой среде. Где располагаются данные? Там же. Как осуществляется контроль конфигурации приложения? Простым деплоем новой версии. Кто имеет техническую возможность это делать? Только и исключительно пользователь. Где физически всё это происходит? На любом количестве машин по желанию пользователя.

Нам от облаков типа software as a service нужно двигаться теперь в обратном направлении service as an application, и при этом этот application будет уже не то старое «приложение ОС», которое требует установки, настройки, обслуживания по месту установки и т.п. (то, от чего и сбежали на облака), а просто деплой в предсказуемую универсальную сетевую среду исполнения.

Это должно быть решение на стыке техник DevOps и технологий федерализации, p2p и криптографии.

Чтобы получить наглядный пример, о чем я говорю, можешь посмотреть сервис GitCenter в ZeroNet. https://zeronet.now.im/1GitLiXB6t5r8vuU2zC6a8GYj9ME6HMQ4t/index/ (Лучше поставить ZeroNet локально, чтобы оценить все функции и иметь возможность делать git push/pull. Но интерфейс можно и через этот прокси глянуть. Правда, прокси дико тормозит.)

Иронически вопреки своему названию «Центр», это децентрализованный proof-of-concept аналога GitHub. Вот как он устроен:

• Кто контроллирует репозитории, размещаемые пользователем? Сам пользователь.
• Кто хостит репозитории? Любое количество заинтересованных лиц.
• Кто контроллирует приложение, через которое ты видишь UI сервиса и взаимодействуешьс ним? В данном случае — его разработчик (Иван… не знаю его фамилию), но это только потому, что ты смотришь на сервис через его копию. Если ты сделаешь свою копию, то её контроллируешь только ты.
• Кто исполняет код приложения? Любая машина по желанию.

То есть проследим цепочку. Чтобы у тебя был нужный тебе сервис:

• Нужен экземпляр сетевой среды. Это может быть экземпляр на твоей машине или на машине организации или у хостинг-провайдера или любой микс машин на ваше усмотрение.
• Нужен экземпляр приложения, которое будет работать в этой среде. Это может быть как экземпляр, контроллируемый сервисом типа GitHub, так и ваш собственный экземпляр.
• Нужны собственно данные, ради которых всё затевалось. Управление данными выполняется вашей организаций согласно принятым у вас подходам.

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

К сожалению, Иван что-то подзабил на развитие приложения, а у меня хронически нет времени даже чтобы бегло ознакомиться с его кодом. Сейчас это находится на уровне готовности для тестирования в личных целях «можно пушить в реп и общаться в issues». Со стороны p2p макет идеи показан. Тут нужно подключение движухи со стороны DevOps, чтобы они обдумали, как это хорошо вывести на уровень промышленного применения в свете существующих практик и инструментов.

Да, и весь вышеописанный стек — полностью опенсорс, начиная от ядра ОС и заканчивая функциями, рисующими кнопки в UI.

У США очень длинные руки.

На одной моей прошлой работе коллега оказался бывшим типа хакером. Сначала у него прямо из офиса ноутбук спёрли. А потом, когда он на Кипр отдыхать с подругой поехал, его по запросу США арестовали и завербовать пытались. Гендир из принципа впрягся за него немалым баблом и вытащил домой. Но парню в России дали условный срок в итоге, потому что он там реально кого-то поломал в прошлом.

История известная, гугли «Спасение рядового Зубахи».

Что вкладывается в это понятие? Только лицензия?

Как по мне, лицензия есть механизм обеспечения такой свободы. Я бы придерживался критерия четырех свобод, они универсальнее всего: свобода выполнения, свобода изучения и модификации, свобода распространения, свобода распространения модифицированных версий.

Любая лицензия, обеспечивающая все эти свободы — свободна. Остальные — нет.

При этом copyleft делает шаг далее и добавляет запрет на ограничение доступа к модифицированным версиям. Четыре свободы это не затрагивает никак (закрытые форки опубликованного под MIT/BSD кода для меня тупо не существуют, а то, что открыто единожды, таковым и остается).

Корпорациям, для которых СПО является прежде всего источником безвозмездного труда, конечно, выгоднее, если широкое общество поставит пермиссивные лицензии на пьедестал, а копилефт будет хаять всячески (от мнения о том, что свобода-де по копилефту ненастоящая, до мнения о том, что автор копилефтных лицензий вонюч и нерукоподаваем).

Если мне хватит жизни на то, чтобы сделать программу и библиотеку, достаточно полезную и популярную для многих, я обязательно опубликую ее под максимально колючим копилефтом типа AGPLv3, или еще под более строгим. Конечно же, с CLA. И оставлю возможность коммерческого лицензирования за очень много денег.

Облака с микросервисами — это прежде всего доступ к чужим компьютерам. Статус-кво не очень хорош, но он не затрагивает свободу софта, разве, конечно, речь не о приложении на JavaScript, загружаемом конечному пользователю. Потому что пользователями серверной части будут скорее ее владельцы, за исключением непосредственно обработчиков пользовательских запросов.

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

софт можно собрать и запустить разумными средствами а не скачав flatpak или 20 контейнеров с dockerhub и залив их на kubernetes

Ну, а кому и кобыла невеста. Ну то есть кому и флатпак — разумное средство.

софт можно опакетить в нормальную человеческую rpm

Я понимаю, что ты имеешь в виду, но человекам свойственно извратить все, и их .rpm будет просто инсталлятором какого-нибудь snap.

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

Обслуживает не код, обслуживают люди.

Забавно всё-таки насколько dev и ops восприятие различны.

Когда я говорю сервис нельзя скопировать я имею в виду прежде всего людей которые его держат. Ну и ресурсы которые он потребляет.

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

Сервис - это не код, это совокупность услуг по его поддержке.

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

То есть ты можешь поменять одного поставщика на другого. Но чем этот второй будет лучше первого?

Что если вместо неработающих на практике попыток делать всё самим мы сформулируем критерии к поставщикам услуг так чтобы они обеспечивали нужный пользователю уровень контроля?