В свете недавнего раскола команды OpenOffice.org и основания Open Document Foundation Энди Апдегрув (Andy Updegrove), юридический консультант организации Linux Foundation, размышляет (http://www.consortiuminfo.org/standardsblog/article.php?stor...) об уязвимости разработчиков открытого ПО и способах защиты их прав. Основные мысли публикации таковы:
На фоне нескончаемых споров о будущем Java и OpenOffice удивительным является то, что разработчики вообще дали себя поймать в подобную ловушку. Причина этого: сообщество переоценило возможности лицензий по защите их прав, а также не стали прибегать к другим средствам, хотя и могли. Сегодня ограничительные лицензии предоставляют серьёзные возможности и права, но эти права ограничиваются возможностью их обладателей их предъявить. Возлагать все надежды только на одно средство закона несерьёзно, потому что враг обходит с флангов, и у врага более разнообразный арсенал вооружений.
Возможности разработчиков несравнимы с воз...URL: http://www.consortiuminfo.org/standardsblog/article.php?stor...
Новость: http://www.opennet.me/opennews/art.shtml?num=28520
А вам не кажется, что открыв код изначально закрытых StarOffice и Java, Sun/Oracle имеет полное моральное право стоять у руля этих открытых проектов. Почему они должны отдавать торговые марки и менять название, если код изначально был их. IMHO, в случае OpenOffice и Java сообщество должно подстраиваться, а не наоборот. Подобная защита нужна если проект был изначально открытым, но после того как стал популярным вылез какой-то паразит.
Нет, не кажется. Вы неправильно прочитали автора. Речь идет о действиях разработчиков, которые могут присоединиться к открываемому или создаваемому проекту, а могут не. И это рекомендация им, как не попасть в подобную ситуацию, которая сложилась вокруг жирного монстра Оракела и приобритенных ими проектов. Сообщество может выдвинуть ряд условий своего участия. Корпорация вольна выбирать, как ей все это организовывать, но если ей действительно нужно сообщество для разработки проекта - в таком случае им бы нужно идти на компромис etc..., короче то, о чем пишет автор.
А почему люди должны вкладываться в закрытые проекты корпораций за так? Вы согласны дарить код Ораклу?
Если програмер(или кто угодно) коммитит в открытый проект, он имеет право настаивать на том, что проект всегда останется открытым.
Желание корпораций контролировать конечно очевидно и по-человечески понятно, как и нежелание вбухивать бабло в проекты, кот орые они не контролируют. Но вся суть свободы в том, что тебя никто не контролирует, это так же очевидно. Поэтому если фирма создает FOSS проект, или открывает существующий проект, она должна смириться с тем, что теряет единоличный контроль. И это кстати тоже очевидно.
> А почему люди должны вкладываться в закрытые проекты корпораций за так?За зарплату.
А что так не в тему?
Сан и Оракл не выплачивали зарплату всем кто пилил, тестировал, разворачивал, или иным образом поддерживал и поддерживает ООо.
Считаете, Оркель должен был передать бренд ООо команде Гугель-Новель? Вот так, за здорово живешь?
Бренд _свободного_ проекта изначально не должен ни принадлежать ни передаваться никакой корпорации, а принадлежать независимому фонду.
Об этом должны представители сообщества беспокоиться, а не фирмы. И возмущаться Сан/Ораклом как-то не по адресу.
Они и беспокоятся. Читайте сабжевую заметку и не возмущайтесь.
А вы не пытайтесь как Шариков вселится в чужую квартиру.
> Я бы попросил объяснить что общего между чужой квартирой и свободным ПО
> и кому оно принадлежитРечь идет не о СПО, а об открытых проектах, и тут аналогия уместна
>Бренд _свободного_ проекта изначально не должен ни принадлежать ни передаваться никакой корпорации, а принадлежать независимому фонду.А оплачивать разработку проекта тоже должен независимый фонд?
Если корпорасты все оплачивают, то спрашивается зачем они открывают код и принимают коммиты? Зачем вообще с сообществом связываются, если могут сами все с нуля написать под любой проприетарной лицензией?
Чисто из альтруистических соображений наверно.
Если бы вы чуть расширили свой горизонт - поняли бы, что сейчас производством и разработкой заниматься не выгодно. Все деньги делаются в банках и на биржах. При этом главное - имидж, а не реальное. Поэтому все корпорации набирают побольше проектов, патентов и работают с общественностью. Такого жизнь - доведенная до абсурда виртуализация. Вы, как Философ должны знать термин "виртуализация общества". И наверно лучше сможете объяснить нам, не читающим книжек школьникам.
> Если корпорасты все оплачивают, то спрашивается зачем они открывают код и принимают
> коммиты?Ну решили сэкономить на разрабах, а взамен дали исходник. Такой вот бартер. Или товарищ вместе с исходниками захотел ещё команду оплачиваемых орклом программистов?
> Бренд _свободного_ проекта изначально не должен ни принадлежать ни передаваться никакой
> корпорации, а принадлежать независимому фонду.Ни кому он ничего не должен. Брэнд "линукс" FSF тоже не принадлежит. Вот только не пойму, что уцепились за этот бренд. Вроде представляют свободное ПО, а прям как жалкие копирасты, которых только продажи и интересуют.
За право называться "Linux" тоже могут потребовать роялити в принципе, или просто запретить использовать, да. В этом плане он ничем не свободнее Опенофиса. Но этого можно избежать если с самого начала все правилдьно сделать.
>Вот только не пойму, что уцепились за этот бренд. Вроде представляют свободное ПО, а прям как жалкие копирасты, которых только продажи и интересуют.А зачем к именно бренду прицепились я тоже не понял. Видимо молодой человек остальную часть статьи не осилил.
> Но этого можно избежать если с самого начала все правилдьно сделать.А зачем? Название как-то влияет на качество?
>А зачем к именно бренду прицепились я тоже не понял. Видимо молодой человек остальную часть статьи не осилил.
А вот не надо тут руками махать. Предыдущий оратор высказывался как раз про бренды.
>А почему люди должны вкладываться в закрытые проекты корпораций за так?Не должны. и под палкой никто не заставляет.
> А почему люди должны вкладываться в закрытые проекты корпораций за так? Вы
> согласны дарить код Ораклу?Тот кто согласен - подписывают соглашение с Oracle и передают ему имущественные права на код. Кто не согласен - присоединяются к Go-oo, Koffice, Abiword и прочим независимым проектам. Все честно. Но вот, когда некоторые подписав соглашение и зная на что шли начинают мутитить воду.... Из тех 33 человек, что демонстративно вышли из проекта, опенофису ни холодно ни жарко, там большинство локализацией занимались и переводами. Те десяток человек которые действительно пишут код, так и продолжают его писать....получая зарплату в Oracle.
Именно поэтому Oracle так отреагировала на ход с созданием Document Foundation, потому что там в основном болтуны, желающие порулить кораблем. Дай им в руки власть начнут принимать первый встречный код и превратят проект в свалку. У Oracle очень серьезные требования к коду, патчи ушедшие в Go-oo главным образом отвергли за качество, а не по причинам разногласий на почве авторских прав.
> Именно поэтому Oracle так отреагировала на ход с созданием Document Foundation, потому что там в основном болтуны, желающие порулить кораблем.чем докажешь сие, кроме ссылки на свою собственнкю анонимную аналитичность ?
> Дай им в руки власть начнут принимать первый встречный код и превратят проект в свалку.
Какие у вас доказательства кроме личной неприязни ?
> У Oracle очень серьезные требования к коду,
> отвергли за качество, а не по причинам разногласий на почве авторских прав.Требования к передачи авторских прав обязательны, поэтому разговор "за качество" смахивает на ложь, пока юридические требования не выполнены.
>> Именно поэтому Oracle так отреагировала на ход с созданием Document Foundation, потому что там в основном болтуны, желающие порулить кораблем.
> чем докажешь сие, кроме ссылки на свою собственнкю анонимную аналитичность ?Проверить может любой желающий, берем список людей с http://www.documentfoundation.org/foundation/ и смотрим их коммиты в http://hg.services.openoffice.org/
замученные то все какие
> У Oracle очень серьезные требования к кодуИменно поэтому у Oracle Application Server, например, такой шикарный уровень качества?
Что аж, как выражались здесь давно, "поздно делать аборты мамам разработчиков этого OAS".
>патчи ушедшие в Go-oo главным образом отвергли за качество, а не по причинам разногласий на почве авторских прав.ах, это многое объясняет. теперь понятно, почему, скажем, импорт метафайлов в Go-oo работает, а в Ooo - завешивает бинарь нафиг. Качество-с не то.
> ах, это многое объясняет. теперь понятно, почему, скажем, импорт метафайлов
> в Go-oo работает, а в Ooo - завешивает бинарь нафиг. Качество-с не то.У меня, кстати, обратные наблюдения. Импорт некоторых документов в формате MSWORD
с развесистыми метафайлами Ooo версии 3.2.1 прекрасно работает (хотя и чуть
подтормаживает), а хваленый Go-oo зависает намертво.
>В итоге, хоть сколько-нибудь эффективно разработчики могут защитить себя от фактического закрытия проекта или размножения подверсий только если с самого начала не станут подвергать свои проекты таким рискам.Все правильно: мозги надо заранее включать. А если не включили, не фиг жаловатся на дядю Ларри.
>Разработчики open-source должны настаивать на том, чтобы корпоративный спонсор >создал независимый юридический субъект...Привет QT ;)
Там невозможно было настаивать на независимом юр.лице . Библиотеки предоставлялись попользоваться. А людишки сами решили дорабатывать, хотя надо было форкнуть.
уязвимы, неуязвимы... убеждаюсь только в одном - столман дальновидный и умный человек. кстати если кто помнит: ядро линукса(еще в самом начале) как-то было передернуто(замена копирайта) другим разработчиком который хотел забрать его себе. решилось все тем, что зарегистрировали в экстренном темпе линукс(тм) на имя линуса(в just for fan об этом подробно). я к чему это собственно. линус никогда в "политику" не лез и лицензиями в начале не заморачивался. но вот когда писец подобрался незаметно сразу вспомнил и гпл и столмана и о том что существуют юристы.иногда лучше не доводить до состояния "поздно пить боржоми":)
> столман дальновидный и умный человек.Ага, не с проста для коммита в проекты FSF надо отказываться от своих прав. Прям как в опенофисе когда-то.
> Ага, не с проста для коммита в проекты FSF надо отказываться от своих прав. Прям как в опенофисе когда-то.Как бы репутация FSF и Столлмана лично позволяет им выдвигать такие требования, а авторам с ними соглашаться. Если ты хочешь обеспечить свободу своего(!) ПО, и это тебе важней чем возможная продажа прав на него и т .п., но сам ты не юрист (то есть все равно кому-то довериться придется), то FSF лучший вариант. Их щепетильность и радикализм в вопросах свободы ПО плюс юридическая грамотность в вопросах лицензирования дает определенную уверенность (не 100%, конечно, но очень близко к этому). Повторюсь, это только если автору гарантии свободы его ПО (и его пользователей) важнее всего.
>Как бы репутация FSF и Столлмана лично позволяет им выдвигать такие требования, а авторам с ними соглашаться.И продолжать дарить им бесплатный код.
>Если ты хочешь обеспечить свободу своего(!) ПО, и это тебе важней чем возможная продажа прав на него и т .п., но сам ты не юрист (то есть все равно кому-то довериться придется), то FSF лучший вариант.Ещё лучше, в случае нарушения лицензии твоего ПО, все отсуженные денежки текут прямиком в FSF. Видимо, это очень удобно, помогать им зарабатывать.
>Повторюсь, это только если автору гарантии свободы его ПО (и его пользователей) важнее всего.Ну да, сначала говорят о свободе, а потом выпускают несовместимые между собой лицензии. Ну очень свободно.
>>Как бы репутация FSF и Столлмана лично позволяет им выдвигать такие требования, а авторам с ними соглашаться.
> И продолжать дарить им бесплатный код.Я говорю про свободный код. Речь не идет о купле-продаже чего бы то ни было. Термины "дарить" и "бесплатный" здесь неуместны (если уж говорить с "вашей колокольни", то они мне свой дарят, даже если я им ничего не даю взамен, и мне они на моем коде зарабатывать не запрещают). В общем, мы, по ходу, о разных вещах говорим.
>>Если ты хочешь обеспечить свободу своего(!) ПО, и это тебе важней чем возможная продажа прав на него и т .п., но сам ты не юрист (то есть все равно кому-то довериться придется), то FSF лучший вариант.
> Ещё лучше, в случае нарушения лицензии твоего ПО, все отсуженные денежки текут
> прямиком в FSF. Видимо, это очень удобно, помогать им зарабатывать.Я говорю исключительно про свободы и их гарантии и, в случае судебного разбирательства об их нарушении, важно только то, что FSF сможет обязать нарушителя эти свободы обеспечивать. Если хочется срубить бабла на судах против нарушителей, EULA+бабки адвокатам - лучший выбор (на свободы лучше сразу "забить"). Я говорю совсем про другие случаи.
> Ну да, сначала говорят о свободе, а потом выпускают несовместимые между собой
> лицензии. Ну очень свободно.Вы точно про FSF сейчас говорите? Может все-таки про зоопарк свободных лицензий вообще?
> В общем, мы, по ходу, о разных вещах говорим.Ничего подобного. Свобода - понятие универсальное и оно не обязывает отказываться от своих прав.
> Я говорю исключительно про свободы и их гарантии и, в случае судебного разбирательства об их нарушении, важно только то, что FSF сможет обязать нарушителя эти свободы обеспечивать.
Опять подмена понятий. При коммите в gcc и glib автор должен отказаться от своих прав. Так что FSF отстаивает _свои_ права, а не автора. И компенсацию в случае нарушений получает FSF. С таким же успехом можно отдать свой код мелкософту, а потом кричать, что дескать они отстаивают мои права.
>Вы точно про FSF сейчас говорите? Может все-таки про зоопарк свободных лицензий вообще?Точно. Можно посмотреть тут http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
Особенно феерично наблюдать, как с либами под LGPLv3 нельзя линковать GPLv2 only, но можно пропиетарные проекты. Вот так вот FSF о нас заботится.
>ак с либами под LGPLv3 нельзя линковать GPLv2 only, но можно пропиетарные проекА разве в ГПЛ2 не меньше ограничений? Это 3 версия запрещает тивоизацию и еще что-то. Почему нельзя линковать?
> Почему нельзя линковать?Потому что в FSF так решили.
> Ничего подобного. Свобода - понятие универсальное и оно не обязывает отказываться от
> своих прав.
> Опять подмена понятий. При коммите в gcc и glib автор должен отказаться
> от своих прав. Так что FSF отстаивает _свои_ права, а не
> автора. И компенсацию в случае нарушений получает FSF.Авторские права остаются в полной мере. Почитайте про отказ от каких прав идет речь. По сути, идет защита прав и свобод даваемых другим людям от любых посягательств и от меня в том числе (в случае, если я, например, в будущем передумаю и захочу эти свободы ограничивать). Если я делаю именно свободное ПО, почему мои права и свободы должны быть "правее" и "свободнее" чем у других? Если моя цель получать компенсации, то я не буду передавать ничего в FSF (правда мои шансы на успешное отстаивание свободы моего ПО резко падают в этом случае). Свободное != халявное. FSF берется отстаивать свободу моего ПО не требуя от меня никаких денег, почему они должны это делать бесплатно? При этом, они должны быть уверены, что им не придется бороться в этом вопросе против меня (тут, как у автора, у меня могут быть преимущества в суде), поэтому вполне логичное требование, чтоб я отказался от некоторых юридических прав. В конце концов, если я создал свободную программу, но не передал ее FSF, она от этого менее свободной не станет (правда, может стать в будущем).
> С таким же
> успехом можно отдать свой код мелкософту, а потом кричать, что дескать
> они отстаивают мои права.Кричать-то можно, вот только к свободе это не имеет никакого отношения. Мелкософт-то может и будет отстаивать какие-то права, но уж не свободы, которые я, как автор, хотел предоставить пользователям и другим разработчикам.
> Особенно феерично наблюдать, как с либами под LGPLv3 нельзя линковать GPLv2 only,
> но можно пропиетарные проекты. Вот так вот FSF о нас заботится.А FSF и не заботится о нас о всех. В данном случае он заботится о правах авторов либы и о конечных пользователях.
Линковать можно, нельзя результат публиковать под GPLv2.
>Авторские права остаются в полной мере.Какие именно? Сегодня я закоммитил в FSF, а завтра FSF засудит меня за то, что я захотел продать тот же самый код под другой лицензией.
> я, как автор, хотел предоставить пользователям и другим разработчикам.О каком авторе идёт речь? Предоставляет FSF и меняет лицензии на своё усмотрение.
>Линковать можно, нельзя результат публиковать под GPLv2.Деление на ноль.
>>Авторские права остаются в полной мере.
> Какие именно?Никто не оспаривает, что автор кода я, никто не приписывает себе авторства моего кода, никто не приписывает мое авторство чужому коду, никто не требует от меня гарантий и возмещений в случае причинения и так далее.
> Сегодня я закоммитил в FSF, а завтра FSF засудит меня
> за то, что я захотел продать тот же самый код под
> другой лицензией.FSF непременно засудит меня если я начну говорить, например, что запрещаю публиковать мои изменения, так как я сменил лицензию на свой код или если подам в суд на кого-нибудь, кто использовал в своих работах и (о ужас!) посмел доработать или срубить бабла на моем коде, а со мной не поделился.
>> я, как автор, хотел предоставить пользователям и другим разработчикам.
> О каком авторе идёт речь? Предоставляет FSF и меняет лицензии на своё
> усмотрение.Если то, что хочет предоставить автор отличается от того, что предоставляет FSF, то ни о GPL, ни о передаче каких-либо прав речи идти не может.
Да, чисто теоретически FSF имеет право сменить лицензию на переданный код. Я поэтому и говорил про "не на 100%" в начале. 100-процентного в мире вообще мало, тут каждый сам для себя вероятности считает.>>Линковать можно, нельзя результат публиковать под GPLv2.
> Деление на ноль.Я не имею права считать свои права "лучше" чем права других разработчиков (когда мы говорим о свободном ПО). Если они хотели избежать, например, тивоизации и выбрали v3, то я своими действиями не имею права послать их подальше.
>Никто не оспаривает, что автор кода я, никто не приписывает себе авторства моего кода, никто не приписывает мое авторство чужому коду, никто не требует от меня гарантий и возмещений в случае причинения и так далее.Т.е. право отказаться от своих прав? Так это и без FSF можно сделать.
>FSF непременно засудит меня если я начну говорить, например, что запрещаю публиковать мои изменения, так как я сменил лицензию на свой код или если подам в суд на кого-нибудьГлупость. Лицензии обратного хода не имеют. То что описано, сделать невозможно.
>Eсли то, что хочет предоставить автор отличается от того, что предоставляет FSF, то ни о GPL, ни о передаче каких-либо прав речи идти не может.Т.е. FSF диктует. Где свобода?
>Я не имею права считать свои права "лучше" чем права других разработчиковНет, выпустив либу под LGPLv3 ты уже автоматом считаешь, что права свободных разработчиков хуже, чем у проприетарщиков.
http://en.wikipedia.org/wiki/OpenAL - последнее предложение в тексте History. Это просто вандализм, или есть официальные ссылки подтверждения? Если нет ссылок - пожалуйста, прицепите к этому предложению знак вопроса.
А чего вы там не написали, в обсуждениях?
> http://en.wikipedia.org/wiki/OpenAL - последнее предложение в тексте History. Это просто
> вандализм, или есть официальные ссылки подтверждения? Если нет ссылок - пожалуйста,
> прицепите к этому предложению знак вопроса.А вот и вандал нашелся: http://en.wikipedia.org/wiki/Special:Contributions/79.97.144...
Что-то у вандала подозрительный перекос в том что он там наредактировал в вике. Пруф к своим утверждениям чувак не потрудился указать вообще.
Я что-то не в курсе, про какие права идёт речь? 95% кода написано на деньги санок, который и выкупил оракел. Кроме того, бывшие разработчики и не только разработчики имеет полный доступ к исходникам проекта под GPL. Что им надо ещё? Чтобы оракл продолжал пилить их проект за свои деньги? Не зажрались ли товарищи?
к сожалению здесь пространство влияния более абстрактных материй
-
стратегическое мышление не приходит к человеку сразу, и приходит совсем не ко всем. поэтому подстелить солому заранее под открытыми проектами - это надо об этом подумать заранее, а заранее в таких масштабах среднестатистический разработчик открытых решений думать не приучен
-
Это ИМХО, не холивара для ... но это подтверждается тем, что фонд столмана и мозила пожалуй наиболее известные и, где то единственные, представители предлагаемого варианта. Потому что продумать стратегически до фактической реализации пороху и мотивации обычно не хватает ... это ведь не в проприетарной модели защищать свои вклады, это покодить для души
А мне кажется ещё рано что-либо говорить про Оракл. Действия против гугля полностью повторяют иск Сана к мелкософту за выпуск "своей" "правильной" явы. С другой стороны, есть проекты которые после перехода под крыло Оракла продолжают своё развитие ударными темпами, при чём диких воплей разработчиков не слышно - взять тот же BDB.А разработчики могут просто кипишевать. Менеджмент опенсорса в Сан был мягко говоря неважным, та же история с нововведениями в ОпенОффис могла их очень сильно стимулировать. А поскольку в больших корпорациях даже революции происходят по полтора года они могли просто не дождаться результата.
> А разработчики могут просто кипишевать. Менеджмент опенсорса в Сан был мягко говоря
> неважным,А с покупкой ораклем видимо настал совсем трындец...
Идея выглядит здраво, но я боюсь никто на это из корпораций не пойдёт. Разве что только после массовых протестов увольнений т.п.
Для разработчика лучше всего придерживаться такой политики лицензирования программных продуктов, когда ни одна ключевая технология в его стеке разработки не имеет vendor loсk-in и свободно заменяема другой, аналогичной исходной по возможностям.Тогда и не будет нытья по поводу напрасно вложенных средств и людских ресурсов в закрытую (теперь уже неразвиваемую открытую) разработку из-за внезапно закрытого кем-то ключевого компонента системы.
а много ли совместимых реализаций существует для одного языка? для С/С++ есть несколько не до конца совместимых - ядро Linux пока собирается только одним gcc. Тот же PHP по сути одним проектом пилится. То же самое и с большинством языков. Java имеет несколько проверенных на совместимость реализаций (Sun/Oracle JDK, OpenJDK, IcedTea) и несколько не проверенных (Apache Harmony, gcj) наверное только количество С/С++ компиляторов может догнать количество JDK-шек.так что вендор-лок-ин будет практически для любого языка. Примерно тоже самое для СУБД - поддерживаемый всеми SQL имеет довольно низкий уровень возможностей. Приктически сразу приходится применять специфичный SQL-диалект. Хранимки и триггеры вообще не совместимы в большинстве СУБД. исключение разве что T-SQL который есть в MS SQL, Sybase ASA (WatcomSQL если слышали о Watcom вообще), Sybase ASE, Sybase IQ. Все остальные СУБД штампуют свои языки и не парятся о совметсимости.
Нужно думать во что вкладываешься.
>...ядро Linux пока собирается только одним gcc.Это как раз то, каким может быть выход по мнению Энди Апдегрува. Свободная лицензия в сочетании с независимым юридическим субъектом FSF. В данном случае вендор-лок-ин не происходит.
Вопрос, поднятый вами насчет других языков весьма, имхо, неоднозначен. С одной стороны, язык это описание некоего синтаксиса/семантики в виде спецификации (возможно имеющего статус стандарта). Конкретная реализация компилятора (или СУБД в случае с SQL) должна в какой-то мере этим спецификациям следовать, причем, возможна и не полная реализация стандарта и наличие дополнительных (далеко не всегда совместимых) расширений. И это было всегда нормально (по крайней мере применительно к языкам, чьи спецификации имели статус стандартов). Если, например, какой-нибудь С-компилятор, не полностью соответствует ISO/IEC 9899:1999 (С99), то он от этого не перестает быть С-компилятором. SQLite не полностью поддерживает SQL-92, от этого она не перестает быть реляционной СУБД.
Если спецификации не являются стандартом, да еще и права на них принадлежат.... , то мы получаем, то, что творится вокруг Java последнее время... Вот это и есть настоящий vendor lockin, причем, проявившийся во всей красе. И платное оно там, или бесплатное роли никакой не играет. В случае vendor lockin применительно к языку, даже если в реализации будет 100%-соответствие спецификациям (ни в плюс ни в минус ни на миллиметр), то это ничего не значит - нет высочайшего благословения вендора - есть проблемы и всем плевать на какое-то там соответствие (всегда же можно сказать, что ваша реализация "не следует духу языка" или вообще патентом помахать).
>[оверквотинг удален]
> Если спецификации не являются стандартом, да еще и права на них принадлежат....
> , то мы получаем, то, что творится вокруг Java последнее время...
> Вот это и есть настоящий vendor lockin, причем, проявившийся во всей
> красе. И платное оно там, или бесплатное роли никакой не играет.
> В случае vendor lockin применительно к языку, даже если в реализации
> будет 100%-соответствие спецификациям (ни в плюс ни в минус ни на
> миллиметр), то это ничего не значит - нет высочайшего благословения вендора
> - есть проблемы и всем плевать на какое-то там соответствие (всегда
> же можно сказать, что ваша реализация "не следует духу языка" или
> вообще патентом помахать).Читаю wiki что есть vendor lock, чтобы не спорить о разных терминах. Ага "lock in" - "зависимость потребителя от продуктов и сервисов одного поставщика, невозможность сменить поставщика из‑за высоких затрат на переход".
так вот неполная поддержка стандарта - это пол беды, но вот "Конкретная реализация компилятора (или СУБД в случае с SQL) должна в какой-то мере этим спецификациям следовать, причем ... и наличие дополнительных (далеко не всегда совместимых) расширений". так вот не совместимые расширения и есть lock in. Иначе придется признать что IE не делал lock in на себя, а всего лишь доработал HTML своими дополнительными (далеко не всегда совместимыми) расширениями.
То же самое с СУБД если в компании стоит MS SQL, то на Oracle его менять не будут. Просто потому что дорого и дешевле научится готовить MS SQL. И наоборот. Потому СУБД-хи это яркий пример vendor lock.
Значит на С стандарты слабее, чем на java. если VM не полностью поддерживает спецификацию java, то она не станет JDK пока не реализует полную поддержку. Кстати все спеки на java и другие JCR (аналог RFC для java) общедоступны. по сути java это практически полностью заспецифицированная платформа. Дело то в другом...
> так вот не совместимые расширения и есть lock in...Не могу не согласиться, что они могут стать lock in. А могут стать частью следующего стандарта (как, например, это было с некоторыми расширениями С).
> То же самое с СУБД если в компании стоит MS SQL, то
> на Oracle его менять не будут. Просто потому что дорого и
> дешевле научится готовить MS SQL. И наоборот. Потому СУБД-хи это яркий
> пример vendor lock.Частично согласен, но тут еще очень большое значение имеет стоимость и лицензионная политика этих СУБД. Тут "дорого" начинается задолго до несовместимости расширений, но и их, конечно, касается.
> если VM не полностью
> поддерживает спецификацию java, то она не станет JDK пока не реализует
> полную поддержку. Кстати все спеки на java и другие JCR (аналог
> RFC для java) общедоступны. по сути java это практически полностью заспецифицированная
> платформа. Дело то в другом...Так и я говорю, что дело вовсе не в полноте спецификаций и их доступности. Полная поддержка спецификаций является необходимым, но недостаточным условием "правоверности" конкретной реализации для Java (и даже само слово Java видимо не всегда можно применять). В случае с С-компилятором полноты реализации стандарта достоточно.
> Частично согласен, но тут еще очень большое значение имеет стоимость и лицензионная политика этих СУБД. Тут "дорого" начинается задолго до несовместимости расширений, но и их, конечно, касается.стоимость лицензии на СУБД это меньшее в стоимости коммерческого проекта для бизнеса. ЗП работников за год (хотя бы) намного превышает стоимость и СУБД и ОС под нее. А при учете того, что java выбирается не для сайтиков, а для проектов которые развиваются десятилетиями стоимость СУБД вообще грошевая.
> Так и я говорю, что дело вовсе не в полноте спецификаций и их доступности. Полная поддержка спецификаций является необходимым, но недостаточным условием "правоверности" конкретной реализации для Java (и даже само слово Java видимо не всегда можно применять). В случае с С-компилятором полноты реализации стандарта достоточно.
У С нет одной компании занимающейся стандартизацией компиляторов. Потому любой Вася Пупкин может написать нечто близкое по синтаксису и ВАУ... новый С компилятор. В Java необходимым и ДОСТАТОЧНЫМ условием является совместимость. Только проверка совместимости стоит денег ибо дорого прогонять на всех заявленных платформах все тесты. Полная прогонка собственных автоматизированных тестов Apache Harmony составляла порядка ДВУХ недель. Думаю что сертификационные тесты еще дольше.
Да не, фантастика какая-то детсадовская предлагается. Всё коммунизм изобретают... Офисные пакеты, базы данных, системы разработки ПО и платформы (и многое другое) -- это *бизнес*, а не скромные потребности домохозяйки. А где бизнес, там и все связанные с ним понятия владения, управления и прочая. Отними эти возможности у спонсоров и рынок инвестиций вежливо захлопнет перед тобой все двери.
> Да не, фантастика какая-то детсадовская предлагается. Всё коммунизм изобретают... Офисные
> пакеты, базы данных, системы разработки ПО и платформы (и многое другое)
> -- это *бизнес*, а не скромные потребности домохозяйки. А где бизнес,
> там и все связанные с ним понятия владения, управления и прочая.
> Отними эти возможности у спонсоров и рынок инвестиций вежливо захлопнет перед
> тобой все двери.вот правильно всё говорите, но есть ещё горизонт
-
природа человеческая этот тупой *бизнес* как потолочное понятие не приемлет. поэтому и появляются свободные разработки, которые в "психологический коридор понятий" бизнеса не вписываются, и люди себя чувствуют гораздо приятнее, чем в бизнесе. Значит чо ? Ущербная эта ваша модель бизнеса, или более широко - породившая эту модель иудо-христианская культура, неадекватная людским потребностям ... потому и коммунизм изобретают ... Вот люди и ищут чего далее, за давно объяснённой официальной правдой. А рынок инвестиций, который на вас вежливо положит - может это не истина в последней инстанции ?
да повод задуматься
ошибки совершённые с java будут совершаться и в будущем
например с qtа с java создать независимую юр компанию было реально ибо много компаний завязаны на java и они бы поделились баблом ibm sap vmware redhat oracle google
>и они бы поделились бабломОни точно обязаны это делать?
а им выгоднее vendor lock ?
google уже обломался
ждём когда oracle подставит подножку sap ibm и тд ...
> а им выгоднее vendor lock ?Что за чушь. Исходники под GPL. Бери и пили.
Что за чушь !
Разберитесь с вопросом , потом приходите.
>Разберитесь с вопросом , потом приходите.На вопрос я ответил. Незачем его повторно задавать.
> да повод задуматься
> ошибки совершённые с java будут совершаться и в будущем например с qt
> а с java создать независимую юр компанию было реально ибо много компаний
> завязаны на java и они бы поделились баблом ibm sap vmware
> redhat oracle googleсоздать независимую практически не реально. любая технология, которую сильно развивают содержит инновации, а на них выдаются патенты. держатель патентов и рулит развитием.
кстати для сведения - независимая юр компания и была сделана для java и IBM вместе с Intel скинулись чтобы сделать независимую java. Это и было толчком к открытию Java от Sun - OpenJDK. Apache / Apache Harmony ;)
> создать независимую практически не реально. любая технология, которую сильно развивают содержит инновации, а на них выдаются патенты. держатель патентов и рулит развитием.Главное слово "патенты". Авторское право это конечно святое и его нельзя трогать. Но патентное право нужно уничтожать каленым железом. Патентное право главный тормоз развитие инновационных технологий. Я просто вижу вой тысяч юристов-копирастов о правах простых изобретателях. Но это полный бред - любое новое изобретение создается не с нуля, любое изобретение базируется на знаниях созданных ранее. Иначе бы мы до сих жили бы в пещерном веке и изобретали колесо. Фактически программирование тесно связана с математикой, вот и нужно добиваться того, чтобы патенты на программные ПО были приравнены к математическим изысканиям, которые запрещено патентовать. Вот тогда закончится период патентных троллей и корпорации займутся реальной работой по совершенствованию кода и технологии. Конкурентными компаниями станут наконец самые инновационные компании, а не те у которых больше патентов. А самые иновационые идеи возникают как раз в опенсорсе, но без должного финансирования они слабо развиваются.Крупные проекты на одном энтузиазме не поднимешь.
Так что предложенная мера это костыли. Бороться нужно с первопричиной - патентное право должно быть уничтожено!
>Авторское право это конечно святое и его нельзя трогать.С чего бы?
Корпорациям нужно имя, Java, OpenOffice, что там внутри - пофигу.
По этому Названия, логитипы, символы, слоганы итп, должны так же GPLиться.
Это невозможно. История с Фирефокс и Дебианом этому подтверждение. Давать косоруким возможность выступать под той же маркой - форменное самоубийство.
> должны так же GPLиться.Должны кому?
> Корпорациям нужно имя, Java, OpenOffice, что там внутри - пофигу.
> По этому Названия, логитипы, символы, слоганы итп, должны так же GPLиться.Тянет на парною. Корпорациям нужны стабильные платформы для разработки софта с многолетним жизненным циклом. Какой язык может похвастаться обратной совместимостью лет на 10-ть? OpenOffice часто не нужен, а вот java применяется именно потому что очень долго поддерживается. И писать/поддерживать будут программисты именно они выбирают платформу.
Так что слоганы / символы / логотипы - пофигу. главное КАК работает.
Если бы так оно и было - сейчас всё было бы на лиспе и смалтоллке ... ан нет :(
> Если бы так оно и было - сейчас всё было бы на лиспе и смалтоллке ... ан нет :(лисп и смаллток довольно сложны в изучении, а это значит нужно больше учить людей, а это увеличивает стоимость проектов. дешевле сделать на менее мощном, но более дешевом языке. К примеру С/C++ или Java ;)
Ну а я о чём? О том что когда ты ляпнул "главное КАК работает" - ужасно далеко ты был от народа :)
> Так что слоганы / символы / логотипы - пофигу. главное КАК работает.Tc-c-c-c, тока iДжобсу не говори.
>> Так что слоганы / символы / логотипы - пофигу. главное КАК работает.
> Tc-c-c-c, тока iДжобсу не говори.вы наверное не пользовались iPhone? iPhone очень удобен для записной книжки номеров + звонилка + СМС-ки + эстетически красиво.
PS пользователь G1 ;)
GSM c картами и BookReader у них тоже хороши, чего уж ...PS: Ни-ни-ни - Я пользователь корпоративной блэкберри :)
>>> Так что слоганы / символы / логотипы - пофигу. главное КАК работает.
>> Tc-c-c-c, тока iДжобсу не говори.
> вы наверное не пользовались iPhone?Я вообще не знаю накой хрен мне телефон.
Надо дрессировать людей, а то блин свободу почуяли,
в пробке застряла,
"- алё дорогой я стою",
"- а мня ипёт, стой где хошь, а во время будь!"
иль машина сломалась, по среди леса...
Так ёпть, ТО надо во время делать и следить за состоянием,
с утра штукатурку наложить не забывают, а то что колесо может отвалиться пох...Такое ощущение, что с появлением мобил и коммуникаторов,
у людей функция планировщика задач вымерла. Помимо напоминания о событии,
надо планировать временное и пространственное окружения для свершения сего.
То есть чтоб быть после работы в театре, не надо уезжать за 2 часа в Рязань,
и оттуда орать,
"- Ой стою на Каширке, не успею... :("
"- Твою ;%:№:"@$%@$#%&E^%*$##^%лять"
И всё-таки непонятно, чего такого страшного делает Oracle по сравнению с другими и вообще "по Гамбургскому счёту"?Рулит проектом единолично? В данном конкретном случае это практически синоним меритократии - кто больше вложил, тот больше и влияет.
Заставляет кодеров отказываться от претензий к коду в пользу Oracle? Это общеизвестная практика защиты продукта, как единого целого. Без организации сбора подписей у всех, кто написал хоть букву в проект.
Отвергает одни патчи и принимает другие? Ну в этом и есть смысл управления проектом. Линус также делает, причём фактически вообще единолично.
И в чём беда в текущей ситуации? Ещё один форк? Ну и что? Тем более, что де-факто это просто переименованный Go-OO. Чем-то лучше, чем-то хуже. Как и любой форк. Их и ранее было немало. Более того, SUN/Oracle приветствуют создание национальных сборок, которые содержат специфичные патчи, нужные только в локальных сообществах. Например, OpenOffice.org Pro - именно такая сборка.А есть и полноценные форки. Тот же Lotus Symphony. И что? "Пусть расцветают все цветы".
Лицензия на код остаётся LGPL, так что обмен идеями между проектами никто не запрещает.
Где воровство кода, где нарушение прав разработчика? Бери свой код (и чужой заодно) и делай с ним, что считаешь нужным. Почему каждому разработчику обязаны предоставлять право голоса (управленческие рычаги) в совете директоров проекта? Этого нет нигде.
Фонды - это представительный орган для множества спонсоров, голос отдельного разработчика и там будет слабо слышен, будь он хоть трижды гениальным и работоспособным, как робот. А если и будет, то это будет и юридически оформлено. И создаются фонды вокруг таких проектов, которые не в силах (не считает целесообразным) тянуть отдельная компания, обменивая часть своих управляющих функций на бОльшую концентрацию ресурсов вокруг проекта. Oracle считает, что её ресурсов хватит. SUN тоже так считала, но просчиталась. Поживём - увидим.
В форках и бранчах, как таковых, нет ничего криминального. Вершина бранчевания - git. Каждый обладает своим бранчем и даже любым количеством бранчей. Синхронизация - вопрос доверия. Бранч ядра от Линуса - на данный момент самый доверенный, но это временный феномен. Смена лидера может повлечь гораздо более явную сегментацию, чем теперь. Да и теперь сегментация очень значительная: версии от RedHat, Novell и т.п. очень сильно отличаются от ванильного ядра. И ничего - пока все живы.
Есть мотивы для кооперации, есть мотивы для сегментации. Результирующая этих мотивов и создаёт реальный ландшафт разработки ПО.
> Но форк проекта влечёт за собой огромные усилия, неуверенность, отсрочки и риск (всё, с чем сейчас приходится сталкиваться контрибуторам OpenOffice.org).Опана! Этак договорятся и до того, что и исходники не всегда нужны ;)