Hace 8 años | Por meneante2015 a infoworld.com
Publicado hace 8 años por meneante2015 a infoworld.com

En una decisión perjudicial para los desarrolladores de EEUU, la Corte dictaminó que las interfaces de programación de aplicaciones tienen Copyright y solo pueden utilizarse con el permiso explícito del autor.

Comentarios

David_VG

#7 Y la interoperabilidad pesa bastante más que el tiempo de desarrollo y el tamaño de las aplicaciones.

Jiraiya

#1 Podrías haber explicado la importancia de la noticia sin haber sido ofensivo con el resto de Meneantes que les puede parecer bien menear noticias con las que tú no estás de acuerdo?

Has sido insultante de manera gratuita.

Jiraiya

#59 Yo he votado irrelevante después de leer tu comentario porque me ha ofendido la manera insultante que has tenido de hablar de Menéame como si fueramos una panda que literalmente votamos noticias "Rajoy caca, Pablo Iglesia es lo más". Reducción infantiloide de la realidad que busca ofender y ridiculizar.

Es insultante porque en definitiva Menéame se basa en votos. La gente decide qué publicar y aunque exista un corte evidente en temas de políticas desde una perspectiva de izquierdas, aquí no se existen más filtros que los votos.

La mejor manera de pedir que la gente vote y lea tus noticias no es insultar al resto y hablar de nosotros como si tuviésemos 10 años.

D

#61 Seguramente eres un pijo de clase media porque eres muy sensible a los comentarios que hacen los demás. A ti te haría falta hacer la mili en los marines de los años 80:



A mucha gente sensible le haría falta unas vacaciones en Siberia picando piedra durante una larga temporada.

XrV

#74 first world problems everywhere!

D

#90 "Toda la manada de pijos mimados de clase media que se ofenden porque los llamen "hijos de la gran puta" (si a mí me dicen eso no lo considero un insulto sino un elogio),"

Lo entiendo, lo entiendo... Es normal que lo elogies, cada uno defiende la profesión de sus madres lol

Espero que no me des negativo, ya que no te sienta mal que te lo digan.

Jiraiya

#74 Jajajaja pijo de clase media?! Me hace falta una buena mili?!! Que si Siberia picando piedra?!!

Pero de dónde has salido?! De la Universidad de Bertín Osborne? lol lol lol

D

#61 le estás dando la razón al votar irrelevante por una razón distinta a la naturaleza de la noticia

N

#1 No, no es bueno para nadie.

G

#3 El problema podría QUIZÁS, ocasionar algo como por ejemplo con DirectX, que no hay permiso explicito y es un engine básico con lo que se mueven todos esos engines más completos y todos los juegos.

Supongo que habrá (EEUU y todos los que se planteen comercializar allí) que solicitar permisos expreso a Microsoft para tener algo escrito si no siempre podrías ser denunciado.
Pero no creo que sea inconveniente por parte de Microsoft seria la bomba si pusiera pegas o limitaciones o no diera permisos

Lo más tal es a ver si otros engines como Opengl o trabajos para soportar Win32/DirectX/etc sobre Linux se quedan totalmente con el culo al aire.

Es el lo único que se me ocurre de este cambio en estos momentos aunque aun no tengo claro del todo el tema.

ur_quan_master

#6 OpenGL es un API, no un engine.

G

#20 Tanto Opengl como DirectX apesar de ser ciertamente APIs se puede considerar perfectamente un engine básico. Hay motores que son simplemente APIs tambien.

ur_quan_master

#22 el minimotor estaría formado por los drivers de la tarjeta y la parte correspondiente al sistema operativo. Pero tienes razón es ponerse muy puntilloso a estas horas.

G

#25 No, los drivers de la tarjeta no son parte de DirectX. DirectX provee eso si una capa de abstración para que el programador no tenga que lidiar con los drivers de cada tarjeta en el mercado y sea el driver el que tenga que lidar con DirectX.

El tema es simple no es ponerse puntillo ¿que es un motor gráfico? si nos vamos a la wikipedia:

Un motor de videojuego es un término que hace referencia a una serie de rutinas de programación que permiten el diseño, la creación y la representación de un videojuego
https://es.wikipedia.org/wiki/Motor_de_videojuego

Y exactamente eso es también DirectX, un API con rutinas para facilitar la programación gráfica, eso si en su forma más básica para que su uso sea general.

Antiguamente, un motor grafico era empezar a hacer una api tipo directx. Claro que despues de directX el motor gráfico empezaba un paso más adelante y la salida de más de un chip grafico con los que lidiar obligaba a simplificar el tema de algun modo. Pero aun existen motores graficos que son simplemente APIs como DirectX o OpenGL y que no hacen uso de ellas. Aunque no es lo normal claro. Reinventar la rueda nunca es bueno y dudo que nadie haga algo mejor a ellas.

ur_quan_master

#30 ok,lo que tu quieras.

G

#32 No es lo que yo quiera es lo que es. Si no tienes argumento para reafirmar lo que has dicho de que no es un motor grafico simplemente no contestes

ur_quan_master

#33 https://www.khronos.org/opengl/ (OpenGL is the most widely adopted 2D and 3D graphics API)
Entra tu mismo y enterarte de lo que es o deja de ser. Pero si prefieres "ganar" roll y no aprender nada, pues ya has ganado.

G

#40 Hola. Llevo 5 años haciendo programación gráfica! desde Win32, 3D (DirectX) y algún que otro de los que tu conoces como "motor graficos" . ¿y tu?

ur_quan_master

#41 Hola! Aprendí ensamblador con el Spectrum y de ahí todo ha ido a peor lol . Si solo has visto DirectX has visto la parte de arriba del iceberg y te has perdido todo lo que hay debajo de la linea (ver esquema). Y sí, simplificando, los que implementan tanto openGL como directX son los drivers del fabricante del hardware. Pero oye! que si eso tienes razón y tal.

G

#44 ¿concurso de quien la tiene más grande? El primer libro de informática que leí y puse en practica no fue microsoft office para Dummys si no el Intel ia32 Architectural Developer Manual, tendria 17/18 años, hace 20 años.

Wayfarer

#46 #44 Venga, el mío fue "Basic Basico", allá por 1989, hace 26 años. lol

G

#93 Bueno yo empezar empecer con basic tambien, aunque no hacia mucho más algunos menus para moverme por el ms-dos y chorradas varias. Pero nada de libro a pelo con ejemplos.

I

#41 hola! Llevo 15 años programando gráficos en win32, iOS, Linux, psp, android y mac. En OpenGL y algún que otro motor gráfico. Hay cierto consenso en la industria en llamar motor gráfico a una abstracción por encima de la api subyacente, ya sea ogl, d3d, la de Wii o la de ps4. De la misma forma q llamar a la stdio "sistema de ficheros" es un poco campeón. Si, se puede programar un motor gráfico con llamadas directa a ogl, pero seria una manera muy idiota de hacer sw. Abstracciones como el modelo, las animaciones, los esqueletos, los shaders la gestión de lods, el batching, el culling, todas esas utilidades y muchas más, hechas multi plataforma, son un motor gráfico. Direct3d y ogl son apos para abstraer del hw, y más aun ahora con d3d12 y vulkan, q abstraer, abstraerán poco.

G

#83 Que haya cierto consenso para llamar engine a lo otro (que es cierto) no quita que DirectX y OpenGL no se puedan considerar motores gráficos básicos simplemente por que lo son. Y suficiente motor gráfico para que no sea estúpido crear un juego o cualquier aplicación grafica, claro que tienes que implementar cosas de las que carece y siempre es más inteligente aprovechar el trabajo echo en un game engine si vas a hacer un juego.

De todas formas quizás "Game engine/motor de juegos" seria más correcto para lo otro, más que motor gráfico ¿no crees?

G

#40 Y lo que tu y todos conocemos por engine no es más que un api de librerías también.

pawer13

#3 según entiendo yo la noticia, lo que no puedes hacer es tu propia implementación de un API no abierta, no afecta a los usuarios. Por ejemplo MS podría demandar a wine o a ReactOS, pero no a los usuarios de sus APIs públicas.

Nomader

#35 si los desarrolladores y fabricantes tienen que pedir permiso para extender los servicios y productos de terceros ... Si afecta a los usuarios. El conector de iPhone es un tipo de API. Si solo puede utilizarlo quién Apple decida ... Se convierte en un monopolio con los precios que Apple escoja. Lo mismo ocurrirá en miles de ocasiones mas que ni nos enteraremos porque forma parte del software ... Pero si nos perjudicará.

Es una ley perjudicial para El Progreso.

D

#3 la verdad que si. El software libre cada vez lo tiene mejor gracias a estas leyes, al final habra que agradecer a los defensores de tanto copyrigth su propia desaparicion.

SemosOsos

#13 Y ReactOS esta en el mismo problema.

D

#49 De acuerdo en todo, pero yo no usaría la palabra "copia" sino "reimplementación", porque no está copiando nada.

Wayfarer
angelitoMagno

¿Y cuál es la novedad? La mayoría de las APIs te piden aceptar unas condiciones de servicio y de uso.

D

#9 Y que problemas hay? Pues cuando se evalúe en que lenguaje se ha de programar, que no se programe en Java y punto, verás como cuando toda la comunidad le dé la espalda a este lenguaje, se dan cuenta del problema que supone no liberar su código.

m

#10 Java es un problema en este juicio, ¿Pero que pasa con todas las otras api de licencia dudosa?

G

#11 cuando estuve de programador hace 10 años, sólo podíamos usar apis libres... Joder, ya no me acuerdo del nombre... De las que no te obligan a que tu programa también sea libre. Y había apis muy chulas que desechábamos y en algún caso se mando email al desarrollador para pedirle una licencia especial.

No entiendo la noticia o me he perdido algo.

m

#37 Google usó para Android apis deJava cuyo uso Sun permitía pero Oracle no

G

#60 si te bajas una API con licencia de uso y luego cambian la licencia te afecta para la actualizaciones pero no para lo usado. Otra cosa es que uses algo que no ponía que tuvieras licencia pero nadie te decia nada y de repente te lo piden. Yo me harte de mandar emails a desarrolladores preguntando si usaban la licencia que queriamos.

m

#65 El caso es que Google se durmió. Sun no tenía problemas y nunca consiguieron la licencia.
¿Qué pasa si a Oracle después se le ocurre ir por los desarrolladores o los fabricantes de equipos como hizo Microsoft co nlos fabricantes de terminales Android?

G

#79 efectivamente, algunos desarrolladores se durmieron. Y ahora tendran un problemon. Nosotros tuvimos problemas con alguna api que cambio la licencia de abierta a abierta si tu codigo es abierto y al dejar de poder actualizarla tocó cambiar de libreria.

a

#37 Deduzco que has dejado la parte técnica para dedicarte a la gestión de proyectos/equipos...

G

#88 deduces bien, la parte de programar es divertida, pero la parte de ingenieria de software se hace tan mal (al menos en los sitios que conozco) que al final te hartas de reescribir codigo y te mueves a otro campo.

a

#99 Las metodologías ágiles requieren equipos multidisciplinares en los que la ingeniería de software la realizan los miembros del equipo. En este mundillo, olvidar la parte técnica (más aún con las nuevas metodologías) y no actualizarse es practicamente suicidarse a medio plazo. Ya he visto a más de un perfil "antiguo desarrollador" que le ha tocado volver a desarrollar y tengo muy claro que es mejor un perfil más junior que intentar hacer ver como se hacen las cosas en la actualidad

D

#8 que puedas o no puedas hacer software libre interoperable con ellos.
O software privativo, el problema es el mismo.
Tú lo que dices es pagar por el uso. Aquí se dice pagar por el desarrollo.
#10 abandonar el java (si te he entendido bien) es tirar todo el trabajo ya hecho. Todo un golpe. Supongo que se buscará alguna solución para no llegar a eso.

D

#12 no hablo de tirar lo ya hecho, sino, q si se va a hacer algo nuevo, evaluar si se puede hacer con otro lenguaje.

ED209

#10 y en qué se va a programar, en PHP?
Java en los servidores de la Administración es lo mismo que Windows en los escritorios de la Administración: ad aeternum

Más: Android. No va a ser Go, ni Dart, ni JS, ni Python en menos de 5 años.

D

#21 PHP? No se las necesidades de tu empresa, pero utilizar Java requiere una maquina virtual q ralentiza el proceso, y en ocasiones un auténtico engulle recursos. Sin conocer parte de las necesidades puedes utilizar node u a lo mejor PHP, y si utilizas un entorno de windows, porque no .net? Hay alternaticas, muchos desarrolladores utilizan java como vagancia, no porque realmente de un mayor performance.

Wayfarer

#55 #10 Por no mencionar el tema de las aplicaciones web corporativas... Joer, sé de sitios donde aún tienen la máquina JRE de la versión 1.4 porque la aplicación que usan no es compatible con nada posterior y cambiarla costaría un huevo...

Y si no se gastan un céntimo en actualizar la aplicación para que sea compatible con Java 1.8, como para decirles que la rehagan por completo en otro lenguaje. Ni de coña.

Eso sí, lo que está claro es que si hay que hacer una aplicación nueva ya habrá que valorar el hecho de depender de Oracle como un punto en contra de Java

D

#94 A ver, vuelvo a repetir, si hay q realiza un NUEVA aplicación, no rehacer una ya hecha.

D

#55 claro, claro... No se q parte de, hay q evaluar PARA NUEVAS APLICACIONES no entiendes. Como he dicho en otro ejemplo, si utilizas Spark q esta esta en Scala, en lugar de utilizar Scala para hacer tu proceso de streaming, puedes utilizar python con pyspark. Eso significa q dependes de java solo por Spark, pero tu compañía no. Ahora si has decidido hacerlo todo en java en el pasado, porque no evaluastes otras alternativas, solo por comodidad y por utilizar herramientas como hibernate porque ahorra trabajo al programador, no te recomiendo q lo cambies todo, pero si hay q hacer algo nuevo puedes buscar alternativas... A no ser q te comportes como los .NET fans

c

#10 no es tan fácil, si fuese sólo por android... Java tiene una openjdk que a ver ahora...
Y hay muchísimas soluciones muy avanzadas que sólo están desarrolladas en Java/Scala como hadoop, spark, kafka...

D

#58 si, la mayoría de las aplicaciones realizadas con hadoop están en java, y no se implicaciones tendrían, pero las herramientas q tu hagas utilizando cualquier tool del ecosistema de hadoop se puede realizar en otro lenguaje. Por ejemplo, puedes implementar procesos en python para Spark. Vuelvo a repetir, son las cosas nuevas y no lo q esta hecho lo q habría q evaluar.

pawer13

#8 Que ahora no puedes hacer una versión nueva de una API privativa. Google está siendo denunciado por Oracle por crear su propia versión de Java para Android sin permiso. Veremos como afecta esto a Wine, SAMBA, Mono

TocTocToc

Si no hay APIS, usaremos MINA.

voromir

Erronea.
No son todas las APIs, si no las 37 de Oracle que estaban en litigio con Google.
Aunque marque jurisprudencia, no es una ley automáticamente.
Y aunque tengan copyright, falta por dirimir el "fair use"

ED209

#0 APIs, no APIS

El hígado de cerdo sigue siendo un producto de libre uso
https://espanaencasa.com/4294-home_default/pork-liver-pate-200-grs-apis.jpg

pip

La decisión de Google de meter la mierda de Java en Android sólo podía traer desgracias. Espero que eliminen ese tumor de la faz de la tierra.

Nova6K0

Una estupidez más para el libro de las "estupideces del copyright" que al final voy a tener que crearlo de verdad. Y lo peor esto puede dar un golpe al copyright. Ya que como dicen los compañeros, las APIs libres se ven fortalecidas. Sería curioso que por sentencias estúpidas a favor del copyright, se acabase con ese mismo copyright.

Es más es lo que llamo "principio de aislamiento". Mirémoslo así. Cada vez que hay una sentencia de este tipo, los autores que la defienden ponen un barrote fictício que los va aislando, cuanto más barrotes ponen por cada sentencia ganada, cierto es que se ven más protegidos, pero sin embargo cada vez están más aislados. Llegará un momento en que estarán tan aislados que habrán limitado sus propios movimientos y en ese momento la cultura y el software libre habrán ganado.

Salu2

Ñbrevu

Esto es lo que pasa cuando los legisladores tratan temas sobre los que no tienen ni puta idea . ¿Qué lobby habrá pagado para esto?

m

#82 Primero, coincido contigo en que la noticia elegida no es la que mejor refleja el tema.
Segundo: Google tiene dinero para litigar y ensayar la defensa del legítimo uso, pero si eres una pequeña empresa de Denver vas a aceptar pagarle a Oracle antes de meterte en un jucio contra alguien que puede pagar a los mejores bufetes de abogados. De ahí que por ejemplo muchas empresas hayan decidido pagar licencias a Microsoft por el uso de Android y que los trolls de patentes hagan tanto negocio. Por eso hubiera sido importante que la corte hubiera avalado el fallo de primera instancia. Una declaración de legítimo uso de Google solo le sirve a Google.
Tercero: lo de " tanta respuesta/afirmación a todo aquel que no está de acuerdo con la noticia o un punto de ella (cualquier punto) o algo que no coincide con tu opinión (cualquier punto)" se llama debate, y resulta muy útil para aprender y conocer la manera de pensar de otras personas. Te lo recomiendo

noexisto

#84 Creeme que gusta debatir, pero no tiene nada que ver con el ridículo de ver un noticia donde el enviante replica a todo el mundo porque no coincide con el

De todas formas, créeme si te digo que quien necesita una respuesta no soy yo, sino #36

RadL

Creo que en el fondo la noticia va a tener poco impacto real. La gran mayoría de las APIs ya tienen unas licencias muy claras de uso, y este cambio legal no las va afectar.

pip

#69 por lo que entendemos algunos de la noticia, poco clara, consistiría en proteger con copyright la especificación en sí, de forma que no se podría hacer una librería compatible con otra ya que precisamente para ser compatible, la librería es otra pero el API es el mismo. Podría afectar a librerías como WINE (implementación del API de Windows), Mono (implementación del API .net), etc, etc. Si fuese ley, sería muy negativa para la inter-operatibilidad y crearía nefastos monopolios.

D

#69 El tema es que el copyright lo tendrá la definición de la funcionalidad, no la funcionalidad en sí. Es decir si yo hago un programa que suma A+B y lo distribuyo la licencia aplica al uso de ese programa/librería, no al concepto funcional en sí. En cambio según esta decisión nadie más podría implementar una librería totalmente diferente que sumase A+B y tuviese la misma API, por ejemplo sum(A,B), para que fuera compatible con la mía.

Esto viene de la reimplmentación que hizo Google en su momento de las API de Java para Android, donde mantienen la interficie de la API (no toda, hay partes que decidieron no incluir) pero no la implementación interna, y que es por los que Google los demandó.

En resumen, que no es la licencia de uso sino la de poder desarrollar software que implemente esa API.

D

Nos quieren hacer comulgar con ruedas de molino

saqueador

Todas las librerias tienen una licencia que especifica su uso, por ahí no veo ningún cambio. El problema entiendo que viene para las implementaciones alternativas de una cierta libreria. Las empresas grandes ya se protegian de esto mediante patentes, ahora estaran aun mas protegidas.

pip

En parte es lógico que el API en sí tenga copyright, ya que el diseño de un API no es trivial y de hecho, es una parte muy importante en el diseño de una librería. El hecho de que las cosas se hagan con esos métodos y no con otros puede determinar el éxito o el fracaso de una librería. Por ejemplo tu puedes hacer de cero una librería OpenGL compatible con su API, pero es innegable que el diseño del API en sí (los métodos y las especificaciones sobre cómo se almacenan vértices, texturas, los flags, el comportamiento de los estados, etc) es un grandísimo trabajo de ingeniería que hasta cierto punto podría estar protegido.

Ahora bien, sobre ese copyright debe de prevalecer el derecho a la inter-operatibilidad, para evitar situaciones de monopolio sobre todo en los API que acaban siendo estándar de facto; con lo que en la práctica, el API tendría copyright, pero los demás tendrían derecho a copiarlo y hacer su propia implementación de la librería. Eso sería lo lógico para el bien común.

D

#68 Acepto que aquella parte de una API que sea realmente innovadora tenga copyright.

El resto que es simplemente un refrito de todo lo anterior, ni es innovación ni nada.

Todo el trabajo de ingeniería lo han hecho los gigantes sobre los que estamos montados.

pip

#72 sería el mismo problema que las patentes de código. Todo código de alguna forma se basa en algo ya creado salvo pequeñas partes innovadoras. En la práctica, esto lo que hace es que las grandes empresas demanden a otras grandes empresas por crear código patentado o API's copiadas, porque solo gigantes pueden meterse en los costes enormes que supone un juicio de patentes o de copyright. Un juego de gigantes en el que la innovación sale perdiendo.

delawen

#68 #72 En parte es lógico que el API en sí tenga copyright, ya que el diseño de un API no es trivial y de hecho, es una parte muy importante en el diseño de una librería

A día de hoy, poca innovación vas a poder hacer a nivel de API. Si nos ponemos tontos, al final no es más que un listado de funciones y parámetros. ¿Qué se puede realmente innovar ahí? Las lambdas, los parámetros opcionales, devolver un callback, usar json, llamadas asíncronas,... todo eso son sólo variantes de la clásica función que ya había en C, con un nombre del método, un tipo de retorno y un listado de parámetros.

La innovación está detrás, está en cómo haces la implementación.

TDsXXI

¿Alguien puede explicarme como si fuera un niño de 5 años qué es una API? Lo habré intentado buscar mil veces y jamás me he enterado de qué es realmente.

Ehorus

#36 voy a intentar simplificar el ejemplo (con permiso de los gurús).
Imaginate que quieres dibujar un cuadrado en la pantalla. Un simple cuadrado, cuatro lineas en medio de la pantalla.
Pues bien, con una API relacionada, bastaría con poner
Cuadrado_centrado(Punto1-Superior-Izquierda, Punto2-Inferior-Derecha)
La API cogería lo que has dicho y dibujaría el cuadrado en el centro, partiendo el las coordenadas Superior-Izquierda e Inferior-Derecha
¿Cuanto has tardado? Menos de 1 minuto y tienes ese cuadrado en el centro de la pantalla.
Ahora, si no dispusieras de la API, tendría que
- Averigurar la resolución de la pantalla (si es de 800x600, 1024x720... etc)
- Calcular cuál es la posición "centrada" de la pantalla
- Generar una linea recta, pixel a pixel, entre
-- Esquina-Superior-Izquierda contra la Esquina-Superio-Derecha
-- Esquina-Superior-Izquierda contra la Esquina-Inferior-Izquierda
-- Esquina-Inferior-Izquierda contra la Esquina-Inferior-Derecha
-- Esquina-Superior-Derecha contra la Esquina-Inferior-Derecha

¿Cuanto tiempo has tardado? Posiblemente entre una hora o dos, aparte - con suerte - si no has cometido fallos al introducir datos, o un valor no esta "fuera" del rango que quieres

(espero no haber metido mucho la pata con la explicación)

pip

#45 perdón estoy con el móvil y tropecé con el botón rojo.

Sólo puntualizar que el API es el interfaz de una librería, no la librería en sí. Es un matiz difícil de explicar para gente no técnica.

D

#36 #45 Como dice #54, la API no es la librería, si no la definición de la funcionalidad de la librería. En el ejemplo que has puesto, la API sería justo la definición del método "Cuadrado_centrado(Punto1-Superior-Izquierda, Punto2-Inferior-Derecha)". La librería implementaría ese API.
Puedes tener una librería que también dibuje cuadrados pero su interfaz (API) sea distinto, por ejemplo:
Cuadrado_centrado(Punto-Centro-Cuadrado, Longitud-Lado-Cuadrado).

Puedes tener dos librerías distintas que implementen el mismo API, por ejemplo Java y OpenJDK. En el ejemplo de dibujar un cuadrado, no podrías podrías cambiar una librería por otra, porque aunque la firma no coincide; aunque las funciones se llaman igual, los tipos de los argumentos no coinciden (una espera dos puntos, y la otra un punto y un entero).

pip

#36 explicación versión coches:

En un coche tienes unos pedales, un volante y un cambio de marchas que te permiten manejar el coche de una forma documentada, incluso estándar, porque funcionan parecido aunque el coche sea otro.
Ese es el API: los mandos que hacen de interfaz entre el coche y tu. Sólo que en el caso de un API, el coche es un programa y la persona otro programa. Es decir, un API son mandos documentados y puede que estandarizados mediante los cuales un programa sabe cómo manejar a otro programa.

s

#51 Buena explicación. Un API es una especificación (como deben ser y funcionar los pedales), y la implementación sería la transmisión, motor, etc.

a

#36 Goto #131

D

Buen día para los desarrolladores de APIs...

Ehorus

jodidisima noticia... imaginad el paquete ofimático "libreoffice" que indudablemente tendrá apis de windows para "acelerar" según que cosas; pues ahora tendrá que dejar de utilizarlo o pagar por ello. Gente que se dedique a hacer miniprogramas tipo shareware o freeware, también.
En el entorno de "software libre", las cosas también irían jodidas. Las miles de apis que las empresas se han apropiado (e incluso a veces, desarrollado) para dichos entornos gnu/linux - pasan ahora a tener copyright. Miles de aplicaciones Java de utilización de recursos.
Me pregunto hasta que punto afecta esto a Android.
Recordemos que en USA te pueden exigir el código fuente de tu aplicación para verificar que no tiene "elementos con derechos de autor" (por si alguien se le había pasado el hecho de pensar "pues no doy el fuente y listo")

D

#27 entiendo que lo que no se puede hacer es copiar la API que es lo que hace Wine y Google con su máquina virtual de Java. Pero usarla por supuesto que sí.

D

¿Desde cuándo las APIs no se utilizan bajo una determinada licencia? Noticia monger del día.

pawer13

#63 no lo has entendido

D

#63 Confundes APIs con librerias. La API es una especificación. Como comentaban arriba, que el boton de la x de la ventana en la esquina superior derecha siva para cerrarla. Ahora viene Apple y dice que eso lo han inventado ellos y nadie puede puede poner un boton en la esquina de la ventana.

Normalmente son soluciones tan obvias que a cualquiera se le ocurriría y frecuentemente programadores encuentran la misma solución para un mismo problema sin romperse mucho la cabeza.

s

Larry Ellison necesita más pasta para sus barquitos... y para ayudar a Ironman

delawen

Vamos, que OpenJDK tiene que decidir entre no poder funcionar en EEUU o separarse definitivamente a partir de Java8.

Esto es gravísimo, independientemente de si os gusta Java o no. A día de hoy hay muchísimo software basado en Java que no se puede mudar a otro lenguaje de forma ni rápida ni eficiente. A Python todavía le falta un par de niveles más de madurez para poder ser la alternativa por defecto. Y Ruby, Perl,... y otros lenguajes más diferentes de Java lo hacen más difícil todavía.

o

Un buen día para el software libre.

D

Menuda estupidez. Y la de problemas que va a traer

D

No entiendo. No necesitas ya tener permiso para el uso de una api?

D

#15 Es un poco confuso y en el artículo no se explica bien. Pero creo que se refiere a que por ejemplo si haces una aplicación para Windows o en Java, haces llamadas a las APIs para crear una ventana, menus, comunicaciones, etc...

Esto que es algo que todos los programadores hacen a diario, parece que ahora tienes que tener permiso expreso de Oracle para hacer cualquier aplicacion sobre Java o de Microsoft para hacer aplicaciones sobre Windows.

D

#16 hay cada genio legislando tecnologia..
De todas formas digo yo, que si esta gente pone en su licencia cosas tipo "libre uso" ya estará por mucho copyright que tenga ¿no?

a

#15 #16 #17 Me da la impresion de que no teneis claro el problema, pondre una analogia con el hardware:

Digamos que una empresa de seguridad fabrica un aparato que reconoce la voz y permite abrir y cerrar puertas. De modo que te instalas el aparato y dices "abrete" o "cierrate" y la puerta se abre o se cierra.

Despues surge una nueva empresa que tiene un sistema de reconocimiento de voz mucho mejor y decide fabricar un aparato que haga la misma tarea, el aparato es totamente distinto pero mucho mejor ya que reconoce a cada persona individualmente, y deciden que su aparato abra las puertas con los mismos comandos de voz "abrete" y "cierrate".

Aqui esta el problema, la primera empresa podria demandar a la segunda por usar las mismas palabras para abrir y cerrar puertas, porque estarian usan la misma "API", a pesar de que los dos aparatos son completamente diferentes, y los usuarios tendrian que dejar de usar el sistema nuevo (o por lo menos los nuevos clientes).

Asi que la segunda empresa tendria que usar otras palabras para abrir y cerrar las puertas, por ejemplo "dame paso" y "vuelve a cerrarte", lo que es un problema gordo, absurdo y un inconveniente para los usuarios que tendran que recordar palabras diferentes para distintas puertas.

Pepitorl

El uso de api a nivel interno de las aplicaciones es completamente necesario, y muchas veces no se puede abrir al público, por que tal vez se trate de una comunicación entre servicios internos, que a su vez, la gente puede o no saber la existencia de esa api.

Dicen de hacer todas las apis de todas las aplicaciones públicas? o no me enteré de nada lol

j

“solo pueden utilizarse con el permiso explícito del autor”

El problema se puede desenvolver, dando lugar a una asignación Apis libres (considerada en cada autor).

Al principio puediera ser complicación, mientras el autor se piensa el sí o el no. Después abundará o existirá bastantes Apis libres para cada acción que no implique la obstaculización.

D

Por el batiburrillo que he leido, esta es otra chorrada de Oracle que parece que todavía esta en el siglo XX y esta viendo su negocio peligrar. Hasta donde yo se si una API es libre, el autor da su consentimiento de uso implicito a menos que se modifique o se realizen cambios que deberían serle comunicados (es de memoria no me acuerdo exactamente). Esto lo que hace es que si hay una libre se tienda a utilizar en contra de la privativa aunque esta sea superior, por que sumar mas licencias a un desarrollo que ya de por si suele ir con un precio ajustado es casi mortal para muchas empresas. Ademas de contraproducente para las empresas grandes de Verdad (Google, Microsoft) que se nutren de mucho desarrollo libre y en algunos casos lo parasitan, si les cortas el grifo a los desarrolladores se lo cortas tambien a estas 2, si hay alguna API de las de verdad que se vea afectada por esta licencia ya contribuiran una de estas 2 a el desarrollo de la equivalente libre, casi en ese sentido es una buena noticia..

y

Sinceramente me parece una obviedad que una API tenga derechos de autor; ahora bien, afortunadamente las APIs tienen especial margen para seguir siendo muy potentes en su distribución libre y/o gratuita.

D

#31 Pues eres el único al que se lo parece, así que no es tan obvio para el común de los mortales.

¿Nos explicas por qué te parece obvio?

D

#31 En Europa las APIs no están sujetas a derechos de autor. Por motivos tan obvios como que se utilizan para acceder a servicios tan básicos como acceder al disco duro de tu ordenador. Si estuviesemos con restricciones de licencias, puedes hacer poco más que un "Hello World" en tu ordenador.

Mientras, los protocolos de Internet y el propio Windows utlizan APIs de software libre, que sin ellas no podría funcionar nada.

Otr cosa es que a compañías como Microsoft les interese que la gente haga aplicaciones para Windows, pero tiburones como Oracle, viven del patent trolling.

D

Esta corte perdió toda credibiiad desde que aprobó el matrimonio gay.

D

#18 la corte aún no ha dictado sentencia: http://www.theverge.com/2015/6/29/8856729/oracle-v-google-supreme-court-declines

The Supreme Court has declined to hear Oracle v. Google, sending the long-running case back to a lower court where Google will have to argue that it made fair use of Oracle's copyrighted APIs.

noexisto

#38 Ultimo párrafo básicamente de la que citas. Voto negativo, porque la noticia aquí es bien confunsa
http://arstechnica.com/tech-policy/2015/06/supreme-court-wont-weigh-in-on-oracle-google-api-copyright-battle/ o la de EFF

noexisto

(#77) #18 Ops, tiempo de edición
Quería citar este párrafo por ej:
"This is not the end of the road for this case—the Federal Circuit decision explicitly left open the possibility that the kinds of uses Google made were permissible under copyright's fair use doctrine,""
Como se ve, esto aún no ha acabado

editado:
"En teoría los tribunales aún podrían decidir en favor de Google, pero el uso justo no es mucho de un estándar para colgar miles de millones de dólares en ingresos en. Casos de Autor son típicamente decidieron sobre una base de caso por caso. Aunque el uso de Google de Java en este caso se descarta el uso justo, no hay garantía de que otro caso se resolvió de manera similar. Una declaración amplia que las API no pueden ser propiedad, en cambio, ofrece una protección adicional para los usuarios y programadores"
http://dronesymoviles.com/moviles/corte-suprema-no-escuchara-la-apelacion-de-google-en-el-caso-de-la-api-de-java/

m

#78 Google puede pagar abogados, pero si eres una pequeña empresa no tienes tantos recursos para litigar.
Caso TomTom con Microsoft o Todos los fabricantes de terminales Android que también le pagan a Microsoft regalías por Android

noexisto

#80 Esto.... y qué tiene que ver eso con lo que he escrito en #77 y #78?

Y qué diferencia hay entre Google/cualquier multinacional al respecto

No es por nada, pero tanta respuesta/afirmación a todo aquel que no está de acuerdo con la noticia o un punto de ella (cualquier punto) o algo que no coincide con tu opinión (cualquier punto) después queda muy ridículo: el azul destaca muchíííííííííííííísimo (he dicho muchííííííííííííííííííísimo?)

1 2