Различия между лицензиями на бесплатное ПО

К лицензиям подобного типа относятся GNU General Public License (GNU GPL), Berkeley software license (BSD), лицензия Apache, а теперь еще Netscape Public License и Mozilla Public License.

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

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

Лицензия Berkeley (BSD) существует дольше других указанных в этом списке. Как и лицензия Apache, она требует одобрения производных продуктов в Калифорнийском университете Беркли и должна быть включена в любой производный текст или исполняемый модуль. Из-за большого числа владельцев исходных текстов, включенных в состав Unix, эта лицензия недостаточно юридически выверена, в силу чего не может быть отнесена к классу Copyleft.

Лицензия Netscape Public License (NPL) весьма напоминает GPL. Все исходные тексты, распространяемые под грифом NPL, могут свободно использоваться в других программных проектах. В этом случае разработчикам нужно учитывать, что им придется распространять исходные тексты всех модулей, созданных Netscape, а также любого нового кода, который изменяет или использует код Netscape. Если программа предназначена для "внутреннего" применения, исходные тексты должны быть предоставлены специалистам той компании, где с ней работают.

Но наиболее интересный раздел NPL - это условие, которое позволяет Netscape использовать любые дополнения к открытому для широкой публики тексту в других своих продуктах (семействе серверов, к примеру) без компенсации или разрешения автора изменений и вне зависимости от того, подпадает ли этот код под действие лицензий с другими условиями, нежели NPL. На самом деле это условие позволяет Netscape использовать в своих коммерческих продуктах достижения всех специалистов, работающих с бесплатным программным обеспечением, в обмен на средства, вложенные компанией в разработку своего браузера Navigator. Прежде чем включить это условие в свою лицензию, Netscape провела консультации с пользователями, организовав на своем Web-узле дискуссию. Кроме того, Netscape внесла в свою лицензию поправки, предусматривающие применение другого варианта лицензии на бесплатное ПО,
Mozilla Public License.

Лицензия MPL практически аналогична NPL, за тем исключением, что Netscape не получает никаких особых прав на частное использование кода, написанного по условиям MPL. Netscape пытается очень четко сформулировать условия применения каждой лицензии. Во-первых, все исходные тексты Navigator попадают под действие лицензии NPL, предусматривающей, что любые изменения, сделанные в исходном тексте, могут быть включены в состав серверных продуктов Netscape и при этом компания не обязана указывать источник этих изменений. Однако на все новые файлы с исходным текстом, добавленные в проект Navigator и не содержащие оригинальный код Netscape, могут
распространяться условия лицензии MPL. Таким образом, для использования этих изменений Netscape обязуется, в соответствии с условиями MPL, бесплатно распространять также и те продукты, в которые эти изменения включены, что невозможно из-за существующих лицензионных соглашений с другими компаниями.

Customers rock!

Зачем нужен enum из двух объектов, если есть булевский тип?

На своем проекте заметил странное явление, в коде встречалось несколько перечислений примерно такого вида:

enum MyEnum
{
Value1,
NotValue1
}

Я думаю идея понятна. Есть два взаимоисключающих значения. Для этих значений заводится перечисление. Возникает закономерный вопрос: "Зачем?". Кроме лишнего кода этот шедевр больше ничего не привносит в проект. Каждый раз, когда нужно проверить какое-то условие, приходится код примерно такого вида:

if (myValue == MyEnum.Value1)

И так постоянно. Налицо дублирование кода, хоть и в мелких маштабах. От того, что это дублирование мелкое, легче не становится.

Мое мнение, что данное перечисление лучше (и логичнее) было бы заменить на булевое значение. Например сделать что-то наподибие такого:

bool IsValue1

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

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

Привязка к производителю

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

Грибное управление

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

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

Моральный риск

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

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

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

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

Прячьте приведение типов внутрь метода!

В коде была найдена довольно неприятная проблема. Вот пример проблемного кода

GetSelectedObject() as Order

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

Order GetSelectedOrder()
{
return (Order)GetSelectedObject();
}

Метод получение выделенного ордера использовать повсеместно. Если тип объекта поменяется сразу возникает исключение и исправлять придется в одном месте.

Примечания:

Оператор AS является довольно опасным. Т.к. может прятать настоящие ошибки и порождать совсем другие. Чаще всего NullReferenceException в других местах приложения, где их быть не должно. Я уже вижу возражения, что он быстрее чем оператор приведения типа (Cast). Так вот, хочу вас расстроить, последние версии .NET Framework хорошо улучшили скорость работы оператора приведения типов. Особого выигрыша от использования операбота AS вы не почувствуете.

Дальнейшим развитием идееи может служить добавление строго типизированного метода добавление элементров в коллекцию:

AddOrder(Order order)
{
AddObject(order)
}

При таком подходе будет трудно добавить объект неправильного типа в коллекцию.