Google возвращается в суд, чтобы защитить будущее программирования

[@ZmeeeD]

Есть где тотализатор на это дело?)уж очень «азарт-абелен» исход дела…

[@DEMENT0R]

Вроде, да:
betsofbitco.in

Можно поставить хоть на третью мировую =)

[@leks2git]

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

[@stdrone]

Армия юристов не может писать код, а занять их, увы, чем-то надо…

[@meranged]

Да здесь миллиард долларов имеет символический смысл. Дело совсем не в миллиарде. Оракл умеет зарабатывать деньги и за пределами стен суда. Первую причину автор привел в самой статье — решение суда может стать прецедентом и в этом случае компании-последователи, имитирующие интерфейсы лидеров рынка, окажутся в очень уязвимой позиции. Вполне вероятно, что за Ораклом тут стоят и другие крупные компании. Я тут вижу еще и другую причину — Google успешно зарабатывает на Java и всем, что связано с этим языком. При этом, косвенно, через производителей девайсов, выплачивают дань Майкрософт. Почему бы подобную схему не организовать Ораклу? Неплохой доход и косвенная сопричастность к успеху динамичных друзей-конкурентов — разве это плохо?

[@23derevo]

а кто Вам сказал, что у них не ведутся совместные разработки?

[@twentyfivesymbolsusername]

Вот я не понимаю, гугл невероятно популяризировал джаву, благодаря им появилось огромное новое поколение джава-программистов. И Оракл еще возмущается? Почему бы просто не начать работать вместе?

[@Dremkin]

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

[@pfa]

У Оракла оригинальные взгляды на пиар, однако.

[@apollo2k4]

Как по мне куда выгоднее сесть на шею Google и получать по доллару с каждого устройства. В перспективе выйдет больше.

Как-то не понятно чего в итоге хочет добиться Oracle. Допустим – заплатят им и что дальше?

[@Colwin]

Дальше наложение вето на ЛЮБОЕ копирование API ЛЮБОЙ защищенной патентами системы :-)
Т.е. прощай совместимость интерфейсов фирм-конкурентов.

[@23derevo]

а с чего Вы взяли, что они не работают вместе?

[@twentyfivesymbolsusername]

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

[@23derevo]

А Вам не кажется, что отношения между айтишными гигантами, в которых работают сотни тысяч людей и разрабатыаются тысячи проектов, могут быть несколько сложнее, чем «вы наехали на нас из-за джавы, поэтому мы поверёмся к вам задом»? :)

[@Mairon]

Но пока отношения именно такие :)

[@23derevo]

ерунда полная. Кто вам это сказал? Показывают только верхушку айсберга.

[@Mairon]

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

[@23derevo]

Ну называет и называет. При чём тут всё сказанное мною выше? Вы серьёзно думаете, что отношения гугла и оракла ограничиваются разборками вокруг андроида?

[@Mairon]

Ну называет и называет

Хахах. Партнёры друг друга не называют абсолютным злом.

Вы серьёзно думаете, что отношения гугла и оракла ограничиваются разборками вокруг андроида?

А Оракл ещё где-то нарушения Гугла себе нафантазировал?

[@bigfatbrowncat]

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

[@VYBGSS]

Кстати, эта фраза звучит, будто судья учился писать на Java специально для дела Google — Oracle. Но, когда об этой победе со стороны Google писали здесь на Хабре, написано было, что судья просто когда-то был программистом, и в юности программировал довольно много. Даже слова судьи приводились, что-то вроде «Да я сам такие конструкции много раз писал».

[@MadHacker]

Блин. Лучше бы они вместо этих судов документацию на русский язык переводили.

[@Arks]

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

[@Colwin]

Насколько я знаю — да. Перевод без согласия автора является нарушением авторского права. В стране американского автора, разумеется. :-)

[@nile1]

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

[@knott]

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

[@knott]

Лучше бы он документацию хотя бы на английском дописал, тогда уж.

[@ilammy]

Документацию надо не только один раз перевести, а ещё и поддерживать в адекватном состоянии. Лучше уж никакой документации (или даже машинный перевод), чем лживая.

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

[@Colwin]

Помимо документации еще нужна такая вещь, как vision.
В случае наличия исходников это подчас оказывается намного нужнее JavaDoc'ов и тому подобной «низкоуровневой» документации.

[@bigfatbrowncat]

Мне кажется, что у Oracle ничего не выйдет.

Поправьте меня, если я ошибаюсь, но насколько я понимаю, запатентовать можно устройство чего-то. Идею запатентоать нельзя. В данном случае, насколько я понимаю, речь идет о стандартной библиотеке классов. То есть, например, есть FileReader — стандартный класс, читающий данные из файла. В нем есть метод read, осуществляющий чтение. То есть, переводя всё в плоскость идея-реализация, можно сказать, что то, что класс с таким именем должен читать из файла и метод должен называться read — это идея. Она не содержит в себе реализации. Ничего об устройстве не известно — только внешняя сторона. А вот что внутри — это уже запатентовано.

Так что патент на API — бессмыслица. Патент может быть на конкретный способ реализации этой API.

В феврале 2013 года компания подала апелляцию, сопроводив ее аргументацией, что клонирование API компанией Google — это как скопировать названия глав и заголовки из книги «Гарри Поттер», перефразировать текст и выдать результат за оригинальную работу.

Вот это — явное передергивание. Google нигде не пытается выдать свою работу за оригинал. Напротив, всячески отпочковывается. Dalvik — не JVM и т. д. А если я взял некоторых персонажей из чужой книги, придумал про них оригинальный сюжет, нигде не пиарил себя за счет автора, но и нигде не утверждал, что этих персонажей придумал я, это называется fan fiction и, насколько я понимаю, законом не карается.

А теперь главная мысль, ради которой я написал этот длинный комментарий:
Oracle пытается наложить лапу не на API. API и так принадлежит им с потрохами. Они пытаются наложить лапу на опыт, накопленный кучей программистов по всему миру в процессе обучения разработке на Java. Они считают несправедливым, что, дескать, многие учились-учились кодить на их проприетарном языке, а потом пришел Google и легко дал этим людям возможность писать под Android почти так же, почти теми же словами.

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

Так что давайте болеть за Google ;)

[@D_R]

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

Можно запатентовать конкретную реализацию идеи.

[@bigfatbrowncat]

Ну так я дальше про это и написал, вроде.

[@D_R]

… это называется fan fiction и, насколько я понимаю, законом не карается.

Ага, если бы…
Фанфик в большинстве случаев — производное произведение со всеми вытекающими из этого последствиями. См, к примеру, en.wikipedia.org/wiki/Legal_issues_with_fan_fiction

[@ArtyomKazak]

это называется fan fiction и, насколько я понимаю, законом не карается.

Коммерческое — карается. Поэтому некоторые авторы популярных фанфиков даже кнопку «пожертвовать» разместить боятся — в принципе, могут засудить.

[@Mairon]

Так что патент на API

Данное разбирательство не имеет никакого отношения к патентному праву, речь об авторском праве.

[@Proxmiff]

>>> Так что патент на API — бессмыслица.
>>> Патент может быть на конкретный способ реализации этой API.
Это еще почему? Это как говорить, что архитектура — ничто, пиши код, блядь.
API, логичное, красивое и удобное — результат кропотливой работы архитекторов, который, на секундочку, не подразумевает сильно много вольностей в реализации этого API. Спор не о том, стоило ли класс для чтения файлов обзывать FileReader или как-то иначе, а о том, что целиком была содрана архитектура.

[@Sap_ru]

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

[@Rast1234]

Хоть пост и неплох, но по заголовку опять угадался автор :)

наболевший вопрос, не по теме

Можно ли исключить посты определенного автора из ленты Хабра?

[@Proxmiff]

$('.post').each(function () { var $post = $(this); if ($post.find('.author a').text() === 'alizar') { $post.remove(); } });

[@Rast1234]

Я понимаю, что меня будут бить ботинками, но такое решение очевидно; всегда можно сделать юзерскрипт. Интересно другое, есть ли на хабре «блэклист».

[@SVolkov]

Тем временем за кулисами: habrastorage.org/storage3/317/484/9a5/3174849a5b5469433668210ccdda48b1.png

[@Lure_of_Chaos]

API — публично. Его никто не реверсил и никогда не закрывал. Наоборот, только документировал. Оно не является продуктом творчества и изысков, это удел реализации — напротив, оно должно быть максимально естественным и удобным. Чтобы каждый, подумав хорошенько смог же его повторить, в отличие от реализации.
Патентовать API — аналогично патентованию алфавита и слов естественного языка, для его разработки не требуется труда, а случайно повторить его — вероятность 90%.
Вперед, Оракл, вы уже купили чужие свободные наработки, теперь запрещайте их использовать вообще. Стимулируйте нас извращаться и эволюционировать в мутантов, которые способны жить там и теми, какими и там, где мы не должны быть. и мы придумаем свое API, где для открытия файла нужно 20 команд с 10ю параметрами, но вы же и погибнете оттого, что ваша уникальная разработка потеряла вкус у масс.

[@Proxmiff]

>>> API — публично.
Угу. Фотографии, к примеру, тоже публичны, и для их разработки тоже не требуется труда; Аллах дает нам свет и тень, создает пейзажи и живых существ, кто такой фотограф?

>>> Оно не является продуктом творчества и изысков
>>> для его разработки не требуется труда
>>> случайно повторить его — вероятность 90%
Да ну нахуй! Нет, серьезно? Ну совсем никакого труда?

Почему же у Гослинга получилось вот это:
>>> максимально естественным и удобным

А у Расмуса это:
>>> для открытия файла нужно 20 команд с 10ю параметрами

Если они оба одинаково не прилагали никакого труда, то почему Гугл захотел повторить API стандартной библиотеки Java, а не глобальную клоаку PHP?

ПС Если чо, свободной наработкой это API стало только в 2007-м, когда стало видно, что Oracle захавает Sun. Таким образом перед сделкой успокоили комьюнити и ынтырпрайз, уже готовящийся к худшему. Тот халявщик (который совсем не утруждался придумыванием API, а просто был одарен Аллахом) пережил переход в Oracle и свалил оттуда позже (сюрприз!) в Гугл. Так что тут весьма неоднозначный конфликт, я лично на стороне гугла.

ППС Перл про 90% вероятность повторить API напоминает Самсунг и Эппл. И правда, каким же еще может быть смартфон? Всем известно, что это закругленный параллелепипед без кнопок, управляемый пальцем. Это естественно, как слова естественного языка, и конечно же никто не утруждал себя придумыванием.

ПППС И да, алфавит придумывали!!!

[@MAXH0]

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

Нужно не быть на стороне одной из корпораций [якобы] защищающей свободу [когда ей выгодно]. А быть свободными людьми с ЗАКОНАМИ защищающими свободу.

[@Proxmiff]

Я на стороне не корпораций, а автора. В данном случае автор против Oracle и не имеет ничего против сторонних реализаций его API.

Слабое место патентной системы — люди, которые с одной стороны дают Adobe патенты на то, что было придумано итальянцами в XV веке, а с другой стороны не хотят видеть, в чем состоит труд архитектора.

[@AraneusAdoro]

Как сказал Пратчетт

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

А что, сроки патента на алфавит истекли, или надо заплатить копеечку за его использование наследникам Кирилла?

[@midday]

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

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

[@Colwin]

Не соглашусь с тем, что «для его разработки не требуется труда».
Для разработки хорошего и удобного API нужно затратить достаточное количество времени на анализ вариантов использования этого самого API.

[@Colwin]

Особенно это касается расширяемого API.

[@Lure_of_Chaos]

Если вы тратите время на то, чтобы придумывать интерфейсы — вы делаете что-то не то.

[@bigfatbrowncat]

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