LINUX.ORG.RU

Ответ на: комментарий от anonymous

Наконец-то. Скоро поделка Mono превратится в шлак.

anonymous
()
Ответ на: комментарий от kda

> "By requiring derivative works to also be released as open source, the GPL discourages commercial forking -- a consequence that fits well with Sun's stated goal of preserving Java's cross-platform compatibility."

Applications that uses Java is not derivative work!

dimag
()
Ответ на: комментарий от dimag

> Applications that uses Java is not derivative work!

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

dmiceman ★★★★★
()
Ответ на: комментарий от dmiceman

Если лицензия GPL - автоматически любой сишный код, использующий jni становится gpl, в силу вирусности GPL. Считается ли использование стандартного J2SE API линковкой - я не знаю (подозреваю, что да) - но если это так, тогда любой жабский код, использующий этот API тоже становится GPL. Вирусы - страшная сила.

svu ★★★★★
()
Ответ на: комментарий от svu

> Считается ли использование стандартного J2SE API линковкой - я не знаю

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

но впрочем да, не копенгаген. и тем более не копенгаген в том насколько часто надо jni пользовать.

dmiceman ★★★★★
()
Ответ на: комментарий от mihalych

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

svu ★★★★★
()
Ответ на: комментарий от svu

Следущая LGPL == GPL v3 с исключениями. Пусть они хотя бы на GPL перейдут для начала, а потом могут и исключения добавлять. Хотя соблазнительно всех джавописателей (что пишут не для себя, а на распространение) заставить открыть со временем свой код. Хех, шучу (почти).

mihalych ★★★
()
Ответ на: комментарий от svu

>Ага. Вы действительно верите, что конторы, делающие заказные проекты под ключ, захотят массово gpl-ить свой код? Да они просто ни одного нового проекта на жабе не начнут - все дружно поползут под дотнет.

С чего бы? То что .NET "открыт" и стандартизирован, не мешает выпускать на нем закрытый коммерческий софт. Точно так же не мешает использовать GPLed Linux для запускания подобного коммерческого закрытого софта, написанного на сях. Точно так же не помешает использовать GPLed Java для ЗАПУСКАНИЯ закрытого коммерческого софта, написанного на Java.

>Наверное, поэтому: "By requiring derivative works to also be released as open source, the GPL discourages commercial forking -- a consequence that fits well with Sun's stated goal of preserving Java's cross-platform compatibility."

>Ага. Вы действительно верите, что конторы, делающие заказные проекты под ключ, захотят массово gpl-ить свой код? Да они просто ни одного нового проекта на жабе не начнут - все дружно поползут под дотнет.

А с чего им gpl-ить? Прога на Java _не включает в себя_ JDK, она ИСПОЛЬЗУЕТ JVM в рантайме

GPL просто не позволит коммерческим организациям типа Microsoft брать код JVM и клепать свои коммерческие форки, называемые Java и которые естественно Sunу придется сертифицировать

anonymous
()
Ответ на: комментарий от anonymous

Жжжошь! А много ты на своем Mono УЖЕ написал? Клоун. Покажи-ка код

anonymous
()
Ответ на: комментарий от anonymous

Еще раз. Ключевое слово - линкование.

svu ★★★★★
()

Ага, зашевелились. Их ответ на релиз .NET 3.0 А вообще, я заметил, что если вещь открывается под GPL - значит, хозяину она уже не нужна, а выбрасывать жалко. Пусть фанаты с ней повозятся.

anonymous
()
Ответ на: комментарий от anonymous

Если они с каждой версией .Net, в С# будут и дальше тащить всякое дерьмо из C++, то язык превратиться в помойку и тут уже ни чего не поможет, даже если это будет версия 5.0. Структуры, свойства, индексаторы, ПЕРЕГРУЗКА ОПЕРАТОРОВ, методы с переменным числом параметров, ДАЖЕ GOTO, зачем нужен еще один C++? Судя по всему microsoft считает что чем больше фич в языке тем лучше, по моему это как раз шаг назад.

UIN
()
Ответ на: комментарий от UIN

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

svu ★★★★★
()
Ответ на: комментарий от sedajko_stjumchik

> вот так корячились-корячились гнувцы, делали свой classpath, наполовину сделали, и в одночасье могут стать никому нужны..

Вот благодаря тому что они делают classpath Sun может и откроет код под GPL, чтобы в перспективе не потерять часть рынка.
И то сначала могут еще обещаниями два года кормить прежде чем открыть.

> новость без сомнения интересная, но я _очень_ боюсь фрагментации Java

сколько лет Sun пиарил эту "опасность" как актуальную, и на твой мозг они успешно повлияли. Бойся дальше :).
Почему никто не форкнул Линукс ?

> Ага. Вы действительно верите, что конторы, делающие заказные проекты под ключ, захотят массово gpl-ить свой код?

Не надо код gpl-ить, если Java будет DUAL-license. Вторую лицензию не судьба использовать ?


szh ★★★★
()
Ответ на: комментарий от r

> Дистростроителей вполне устроит Apache. Эта лицензия выиграл по голосованию.

По голосованию выиграла LGPL!
так как все кто проголосовал за GPL проголосовали бы за LGPL если бы выбирали между apache и LGPL.

На втором месте GPL (многие из проголосовавших за LGPL проголосовали бы за GPL если бы выбирали между apache и GPL )

Apache - на третьем месте.

szh ★★★★
()
Ответ на: комментарий от anonymous

> Ага, зашевелились. Их ответ на релиз .NET 3.0 А вообще, я заметил, что если вещь открывается под GPL - значит, хозяину она уже не нужна, а выбрасывать жалко. Пусть фанаты с ней повозятся.
> anonymous (*)

Что с анонимуса взять ? Узнай что открыл под GPL Redhat, сколько на этом заработал и удивись.

szh ★★★★
()

> Sun откроет исходный код Java под лицензией GPL

Даже не верится...

asaw ★★★★★
()
Ответ на: комментарий от anonymous

>А вообще, я заметил, что если вещь открывается под GPL - значит, хозяину она уже не нужна, а выбрасывать жалко. Пусть фанаты с ней повозятся.

Java уже n лет с открытыми исходниками. Успех Java подверждается стратегическим выбором Microsoft в создании своего клона aka .NET

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

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

Microsoft нужно ПОД ЛЮБЫМ предлогом продавать свое говно. Компиляторы, рантаймы, БД, серверные лицензии под все это дело, лицензии на клиентские подключения. А чтобы быдломанагерам все это впарить, надо доказать, что ФИЧИ .NET 5.0 позволят их мартышкам-разработчикам повысить производительность разработки ПО в 30...300 раз. За счет использования LINQ, фич из модных ныне лиспов и прочих ФП и т.д. А то, что ни одна из мартышек-разработчиков физически ниасилит фишки из этих самых ФЯП, скоко бы не пыталась и будет продолжать быдлокодить на .NET 3.0 в VB6 стиле, манагеры понять не успеют. А бабки уже тютю, успеют выложить. Да ищо и госбабки. См. например http://www.linux.org.ru/jump-message.jsp?msgid=1644892

anonymous
()
Ответ на: комментарий от anonymous

>Вот благодаря тому что они делают classpath Sun может и откроет код под GPL, чтобы в перспективе не потерять часть рынка. И то сначала могут еще обещаниями два года кормить прежде чем открыть.

Уж РЫНОК на classpath не захочет перейти. Ибо Sun в любой момент сможет ввести в Java фичу, ломающую совместимость classpath с javac

anonymous
()
Ответ на: комментарий от anonymous

>Microsoft нужно ПОД ЛЮБЫМ предлогом продавать свое говно. Компиляторы, рантаймы, БД, серверные лицензии под все это дело, лицензии на клиентские подключения. А чтобы быдломанагерам все это впарить, надо доказать, что ФИЧИ .NET 5.0 позволят их мартышкам-разработчикам повысить производительность разработки ПО в 30...300 раз.

Только не надо говорить, что JAVA - совершенство, а .NET - дерьмо, только потому, что второе принадлежит M$, ок?

anonymous
()
Ответ на: комментарий от anonymous

>Microsoft нужно ПОД ЛЮБЫМ предлогом продавать свое говно. Компиляторы, рантаймы, БД, серверные лицензии под все это дело, лицензии на клиентские подключения. А чтобы быдломанагерам все это впарить, надо доказать, что ФИЧИ .NET 5.0 позволят их мартышкам-разработчикам повысить производительность разработки ПО в 30...300 раз.

>Только не надо говорить, что JAVA - совершенство, а .NET - дерьмо, только потому, что второе принадлежит M$, ок?А никто этого не говрит. А никто этого неутверждает. Просто M$ работаю на рекламу и их главная задача продать подороже, а опен сорс работает на себя, программеры сами решают что и как делать не обращая внимание на рекламу и маркетологов. Один пример - на офф форумах M$ вы практически не увидите критики ПО от M$, при обильном поливании вокруг откровенной рекламы. На форумах жаба разработчиков яву ругают не меньше чем дот нет. Поэтому кажется что яву критикуют и свои и враги а дот нет только враги. Маркетинг и ничего больше по идеологии дот нет содран с жабы и это факт, просто навесили рюшек как это уммет делать M$. Реально лицензия GPL не позволит использовать код ява машины в комрческих приложениях, но при этом все программы написанные на яве не попадают ни под какие ограничения, ведь программы исполняются ява мшиной и никакой код не используется. Эта лицензия не позволит горе девелоперам созавать вирт машины на основе явы и использовать в комерческтх продуктах. Но при этом все ява программы не будут попадать под GPL. Они могут быть комерческими потому, что не используют код ява мышины, а JVM использует бай код ява программ для исполнения. А это насколько я понимаю под лицензию GPL не попадает. ))

anonymous
()
Ответ на: комментарий от anonymous

>А с чего им gpl-ить? Прога на Java _не включает в себя_ JDK, она ИСПОЛЬЗУЕТ JVM в рантайме

Не вежно. Чтобы прожка на джаве не была affected by GPL нужно чтобы сама JVM была признана системным компонентом.

r ★★★★★
()
Ответ на: комментарий от szh

>Apache - на третьем месте.

А если бы бабушке....

> (многие из проголосовавших за LGPL проголосовали бы за GPL если бы выбирали между apache и GPL )

Ничего подобного. Они скорее проголосовали бы за апач. Ценность LGPL в возможности линковаться с закрытым софтом. Никто не проголосовал бы за принципиально отличную в этом вопросе GPL, выбрали бы апач. Иначе смысла не было голосовать за LGPL по сравнению c GPL.

r ★★★★★
()
Ответ на: комментарий от r

> Чтобы прожка на джаве не была affected by GPL нужно чтобы сама JVM была признана системным компонентом.

С какой стати? Хоть трижды системная, но если библиотека под GPL, то и программа вызывающая её тоже обязана быть под GPL. Ты путаешь с обратным случаем; в GPL есть исключение на линковку с закрытой системной библиотекой. Вот такая GPL несправедливая к закрытому софту. :-)

mihalych ★★★
()
Ответ на: комментарий от r

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

Ты комментарии читал? Многие предпочли бы дуальную лицензию LGPL+GPL, никто из таких даже близко ASL или BSDL не рассматривал (это было бы нелогично).

mihalych ★★★
()
Ответ на: комментарий от mihalych

>Многие предпочли бы дуальную лицензию LGPL+GPL

Хочешь сказать из-за названия? Или что? Подумай над смыслом зачем им LGPL.

Если уж ты ударился в "что если" подумай что выбрали бы те кто голосовал за "неоткрывать". А их столько же сколько тех кто голосовал за GPL.

r ★★★★★
()
Ответ на: комментарий от r

Дуальная GPL + LGPL смысла не имеет ИМХО (впрочем, IANAL). Во всяком случае, пусть мне кто-нибудь плиз объяснит разницу между такой комбинацией и просто LGPL.

svu ★★★★★
()

> Дуальная GPL + LGPL смысла не имеет ИМХО (впрочем, IANAL). Во всяком случае, пусть мне кто-нибудь плиз объяснит разницу между такой комбинацией и просто LGPL.

Mozilla распространяет свои исходники под тройной лицензией - MPL/GPL/LGPL, так что, думается, сакральный смысл всё же есть.

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

Sikon ★★★
()
Ответ на: комментарий от anonymous

Под Java уже можно проектировать микросхемы: Библиотеки с архитектурой микропроцессоров открыты и доступны Программа для разработки микропроцессоров на Java: http://staticfreesoft.com/ http://ru.wikipedia.org/wiki/Electric

Также можно скачать готовый к употреблению Live-CD (готовый для создания интегральных схем) c русским руководством и учебником: ftp://unix.miet.ru/pub/Linux/Dyne/

ignat

anonymous
()
Ответ на: комментарий от svu

>Во всяком случае, пусть мне кто-нибудь плиз объяснит разницу между такой комбинацией и просто LGPL.

Никакой. LGPL лицензия applicable для перелицензирования в обычный GPL.

r ★★★★★
()
Ответ на: комментарий от Sikon

>Mozilla распространяет свои исходники под тройной лицензией - MPL/GPL/LGPL, так что, думается, сакральный смысл всё же есть.

В мозилле он скорее идеологический, потому что MPL и LGPL одного поля виноградины.

r ★★★★★
()
Ответ на: комментарий от svu

> Дуальная GPL + LGPL смысла не имеет ИМХО (впрочем, IANAL). Во всяком случае, пусть мне кто-нибудь плиз объяснит разницу между такой комбинацией и просто LGPL.

Исключительно для удобства переноса кода. Вот мой проект полностью под GPL - я не хочу иметь в своих исходниках пёстрых заголовков BSDL или LGPL, и потом в суде доказывать, что всё чисто и совместимо. Я хочу сразу взять код Sun/Mozilla с заголовками GPL.

Лично я считаю, что лучше если компилятор будет под GPL, а run-time classes - под GPL с исключением на линковку с ними (подобно LGPL).

Не исключено, что второй (или третьей) лицензией будет какая-то коммерческая, по типу Qt.

mihalych ★★★
()
Ответ на: комментарий от r

> Если уж ты ударился в "что если" подумай что выбрали бы те кто голосовал за "неоткрывать". А их столько же сколько тех кто голосовал за GPL.

Эти проголосовавшие не изменили бы свой выбор, потому как боятся, что открытие вызовет появление несовместимых форков. Они просто не в курсе, что открытие может быть честным, и нет смысла его бояться. Именно по этой же причине, те кто выбрали LGPL/GPL вероятней всего не изменили бы свой выбор на ASL, потому как такая лицензия (будучи неплохой сама по себе) просто напрашивает всякие риски и ненужные несовместимые форки.

mihalych ★★★
()
Ответ на: комментарий от mihalych

>потому как такая лицензия (будучи неплохой сама по себе) просто напрашивает всякие риски и ненужные несовместимые форки.

Например Apache HTTPD - много "несовместимо" нафоркался? SpamAssasin? Tomcat?

r ★★★★★
()
Ответ на: комментарий от r

Тот факт, что никто пока ещё не напакостил, вовсе не ислючает такой возможности. Зачем рисковать, если есть copyleft (LGPL/GPL), защищающий от любых пакостей?

mihalych ★★★
()
Ответ на: комментарий от r

Несовместимо для апача - это как? Если http стандартизован?

А вот вы попробуйте какой-нибудь левый mod_foobar прикрутить к любому из апачей, которые вендоры так любят запихивать в свои проприетарные продукты (тот же Оракл)? Уверены, что это всегда получится?

svu ★★★★★
()
Ответ на: комментарий от mihalych

>ачем рисковать, если есть copyleft (LGPL/GPL), защищающий от любых пакостей?

Да? Мне привиделись снежные кроты от мозиллы, и "более дебианистый дебиан"? Мне привиделось как большая половина разработчиков (L)GPLного жбосс собрала вещички и свалила в apache geronimo? Мне привиделось как (L)GPLный JBoss Federation был продан с потрохами конкретной коммерческой компании и стал "подразделением"? От каких еще пакостей защищает GPL?

r ★★★★★
()
Ответ на: комментарий от svu

> Несовместимо для апача - это как? Если http стандартизован?

Хинт - Java Platform тоже стандартизирована по самое нихочу. Вы уверены что "плодить несовместимые форки" вообще кому-то нафиг надо? Кому они нафиг нужны если они несовместимые? На сегоднашний день jvm/jre сильно больше одной. Сантехники выпускают жабу только под винлинарис. Под маки делает жабку Apple. Под чпуксы - HP. До недавнего времени под Irix делал жабку SGI. У всех у них вполне совместимые со стандартом жабы. А на одной платформе даже совместимые никому не нужны, IBM забил делать свою жабу - продолжает делать только под AIX(еще одна!) - и все выкинул в хармони. Blackdown где? Загнулся по причине никомуненужности?

>А вот вы попробуйте какой-нибудь левый mod_foobar прикрутить к любому из апачей, которые вендоры так любят запихивать в свои проприетарные продукты (тот же Оракл)?

А зачем я буду это делать? Ради нетрадиционного секса? У меня как-то не возникло желания mod_foo прикручивать к апачу который установился в качестве конфигурилки nVidia сетевушки. А что плохого в том что nVidia использовала апач не как вебсервер, а как фронтэнд к firewall?

r ★★★★★
()
Ответ на: комментарий от r

Стандартизованность жабки 1.0 однажды уже не помешала мелкомягким "расширить" стандарт. И не только мелкомягкие этим занимались. Конечный пользователь очень даже может предпочесть то, что он сочтет "удобной фишкой" соответствию стандартам (см. историю про w3c & ie). Так что если несовместимые форки со своими "изюминками" появятся - у них будет ниша, это факт. Сан этого боится.

Зачем прикручивать mod_* - это не тот вопрос, который мы обсуждаем (в случае оракла может быть куча резонов так делать, кстати). Вы хотели пример того, как недальновидность лицензии приводит к появлению форков сомнительной совместимости - я Вам привел пример апача. Плохо это или хорошо - вопрос сложный. Для nvidia/oracle - наверное, хорошо. Для самого апача - сомнительно. Почему? На эту тему очень хорошо недавно кто-то высказался по поводу апача в дистрибуциях линуха - о том, что в конечном счете все посылают людей на апачевский канал ирц, а сами апачеры тихо шизеют от кол-ва возможных конфигураций (каждый дистрибутив извращается как умеет). И это только конфигурация! А когда вендоры начинают патчить "взакрытую", а потом народ ищет решения по апачевским мейллистам - вот где настоящая шиза-то начитается...

svu ★★★★★
()
Ответ на: комментарий от r

Рассматривать конкретные примеры (никак несвязанные с темой) неинтересно. Всё-таки было бы интересно узнать преимущества ASL над LGPL для Sun и сообщества.

mihalych ★★★
()
Ответ на: комментарий от svu

>Так что если несовместимые форки со своими "изюминками" появятся - у них будет ниша, это факт. Сан этого боится.

Они давно есть. Под эпплом есть MRJ API, Cocoa API, jdirect(самая интересная штука к стати) и т.д. Насколько я помню наезд на MS был по двум причинам: 1) лапы проч от языка 2) отказ реализовывать стандартные библиотеки (вроде у них rmi не было - они что-то свое пропихнуть пытались). А дописывать свои различные штуки никто не запрещал.

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

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

К стати я не понимаю как с заворачиванием в дистрибутивах поможет GPL - будет тоже самое. Лицензия ж не ограничивает форканье. Есть желающие - будут форки. Хотят дистростроители извращаться с конфигами - нихто им не помешает. Первым к стати туда руки засунет дебиан и начнет патчить джаву лохматой давности;))

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

r ★★★★★
()
Ответ на: комментарий от mihalych

>Всё-таки было бы интересно узнать преимущества ASL над LGPL для Sun и сообщества.

С LGPL неинтересно. Я ж там выще написал что это одного поля виноградины, только ASL позволяет неоткрывать derivative work.

r ★★★★★
()
Ответ на: комментарий от r

> только ASL позволяет неоткрывать derivative work.

Я не понял. Это преимущество или недостаток для Sun и сообщества Java?

mihalych ★★★
()
Ответ на: комментарий от mihalych

>Это преимущество или недостаток для Sun и сообщества Java?

По моему ИМХЕ - без разницы.

r ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.