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.
#1:
Para los que votan negativo a toda noticia que no tenga las palabras "Rajoy caca" o "el coletas es lo más" explico la relevancia de la noticia
Las APIS se utilizan para ahorrar tiempo de programación y espacio en las aplicaciones. Si bien en Europa no rige ya que el máximo tribunal y la normativa europea las excluyen de la protección de derechos de autor, el mercado norteamericano sigue teniendo mucho peso en el mundo de la tecnología. Esto significa aplicaciones más caras, más pesadas y concentración del mercado.
Aunque también puede ser bueno para plataformas como Ubuntu Touch y Firefox OS que se basan en apis libres
#3:
buena forma de joder a las Apis privativa ... dando mas motivos usar Apis Libres
generalmente es el código fuente que tiene copyright pero las interfaces no deberían ya que la mayorías son librerías ya compiladas
un retraso en toda regla, imaginate que haces un juego en unreal y empieza a vender y el juez declara que las ganancias integras son para el dueño del motor y no un consenso entre el dueño del motor y del desarrollador del juego
#9:
#8 El problema es por el uso de Java, en sus inicios era propiedad de Sun que tenía una actitud muy abierta con el uso de sus productos. Cuando la compró Oracle cambió radicalmente de enfoque. Cerró Solaris, se desprendió de OpenOffice (después de perder gran parte de los desarrolladores) y demandó a todo el mundo que no tenía nada firmado por Sun.
#49:
Creo que la gente se está haciendo la picha un lío con esta noticia.
Para empezar, el uso de APIs ya está sujeto a posibles restricciones mediante el uso de licencias. Por ejemplo, no puedo usar una librería con GPL si en la distribución de mi software no libero el código fuente con GPL por requisito de la licencia. Hay multitud de APIs (la de windows incluida) por las que hay que aceptar un EULA para su uso, ese al que le damos "acepto los términos" sin leer una línea.
No es el uso de APIs lo que se restringe, sino la copia. Básicamente, como dicen #13 y #43, Wine o ReactOS serían ilegales con esta ley si no tienen permiso explícito de Microsoft.
Para entenderlo mejor, hay que conocer el contexto de este juicio: se trata de Oracle vs. Google por la copia del API de java en android. Android se programa en java, pero su implementación no es la oficial de Oracle sino que es una implementación totalmente distinta con un API compatible, por lo que Google se libra de tener que pagar ninguna tasa a Oracle. Oracle demanda a Google por esto alegando que el API tiene copyright y por tanto Google no tiene derecho a desarrollar un software con un API compatible con java sin el permiso de Oracle, el dueño del copyright. Si esto prospera, el caso Oracle vs Google se resolverá con un acuerdo económico entre Google y Oracle y santas pascuas. El problema es que de paso joden a todo el mundo que está haciendo lo mismo que Google y que no tienen capacidad económica para hacer lo mismo.
#7:
De todas formas, el desarrollo del software libre debería estar garantizado a escala planetaria. No es agradable volver a la época en que había unas versiones de software en EEUU y otras internacionales, debido a la ley de aquel país. #1 además de los problemas que indicas, añadir el de interoperabilidad.
#96:
#19#64 Ah, ese es el APIS que se distribuye comprimido en formato tar... y que para acceder hay que un-tar...
Dios, es un chiste tan malo que no merece ni ser llamado chiste...
#62:
#61 A los meneantes no, el comentario dice " Para los que votan negativo a toda noticia que no tenga las palabras "Rajoy caca" o "el coletas es lo más" explico la relevancia de la noticia"
En ninguna parte dice que sean todos los meneantes.
#90:
#89 Mucho pijo mimado de clase media en este país. Ya se espabilarán cuando sus padres no puedan pagar la hipoteca y se vean viviendo en la calle, comiendo bocatas de mortadela (que eso es un lujo en Somalia) y trabajando de peón en el campo bajo el látigo del patrón. El mundo, fuera de la burbuja de los putos pijos de clase media, es un medio hostil, difícil, y nade regala nada. 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), cuando tengan que trabajar en cualquier sitio normal (fuera del enchufe pijo de sus padres) no duran una semana vivos.
#103:
#49 Eres tú el que estás confundiendo el API con la librería. La licencia GPL, por usar el ejemplo que tú has puesto, aplica a la implementación de la librería, no al API. Yo puedo coger el API de una librería GPL y reimplementarlo con una licencia que yo quiera (en Europa por lo menos).
Otro ejemplo es Wine. El EULA que aceptas de Windows es por usar su implementación. Wine es una implementación del API de windows, y por usarlo no tienes que aceptar el EULA de windows, si no la licencia de Wine, que es LGPL.
#59:
#53 Yo no voto irrelevante noticias sobre temas que no me interesan, lo hago con noticias irrelevantes sobre temas que si me interesan, y no insulté a nadie
#13:
Si bien entiendo, ahora WINE es ilegal. Cualquier implementación libre de una API propietaria es ilegal porque la especificación pasa a estar protegida, cosa que antes no ocurría.
#5:
#3 Mal ejemplo. Epic te licencia su motor para que puedas hacer exactamente eso, no hay forma teniendo la licencia que pase eso. Evidentemente sin licencia/permiso no puedes hacer un juego y venderlo, pero eso ya pasaba antes.
#4:
#3 Bueno, tenían que compensar lo del matrimonio gay, y que mejor manera de hacerlo que dándole por el culo a los desarrolladores
#55:
#10 Ah, claro! Como no habiamos pensado en eso? Dejamos de programar en Java y listo.
Problema solucionado .
Ahora solo falta migrar hibernate, spring, SWT, y todos los principales frameworks de desarrollo a otros lenguajes.
Bueno, y migrar todos los millones de lineas de las aplicaciones existentes desarrolladas en Java.
Por supuesto, en algun momento del dia intentaremos reemplazar a toda nuestra plantilla de programadores expertos en java o entrenarlos en un lenguaje completamente nuevo.
Pero todo eso no son mas que detallitos. Lo que importa es que desde MAÑANA MISMO dejamos de programar en java.
#67:
#36 API explicado sobresimplificando: son los nombres de las funciones de los lenguajes de programación o de un programa.
Si un lenguaje tiene una función llamado Math.round() que redondea un numero con decimales a un entero, pues el nombre "Math.round()" es parte de su API. Por ejemplo, la API de JAVA7 es http://docs.oracle.com/javase/7/docs/api/
Si un programa se maneja con tres botones, uno rojo, uno amarillo y otro verde, estos tres botones de colores son su API. La API de un semáforo son los colores rojo, ambar y verde.
Si. Es algo absurdo que se pueda restringir el uso o reimplementación de las APIs. Es mareante.
Para los que votan negativo a toda noticia que no tenga las palabras "Rajoy caca" o "el coletas es lo más" explico la relevancia de la noticia
Las APIS se utilizan para ahorrar tiempo de programación y espacio en las aplicaciones. Si bien en Europa no rige ya que el máximo tribunal y la normativa europea las excluyen de la protección de derechos de autor, el mercado norteamericano sigue teniendo mucho peso en el mundo de la tecnología. Esto significa aplicaciones más caras, más pesadas y concentración del mercado.
Aunque también puede ser bueno para plataformas como Ubuntu Touch y Firefox OS que se basan en apis libres
De todas formas, el desarrollo del software libre debería estar garantizado a escala planetaria. No es agradable volver a la época en que había unas versiones de software en EEUU y otras internacionales, debido a la ley de aquel país. #1 además de los problemas que indicas, añadir el de interoperabilidad.
#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?
#53 Yo no voto irrelevante noticias sobre temas que no me interesan, lo hago con noticias irrelevantes sobre temas que si me interesan, y no insulté a nadie
#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.
#61 A los meneantes no, el comentario dice " Para los que votan negativo a toda noticia que no tenga las palabras "Rajoy caca" o "el coletas es lo más" explico la relevancia de la noticia"
En ninguna parte dice que sean todos los meneantes.
#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.
#89 Mucho pijo mimado de clase media en este país. Ya se espabilarán cuando sus padres no puedan pagar la hipoteca y se vean viviendo en la calle, comiendo bocatas de mortadela (que eso es un lujo en Somalia) y trabajando de peón en el campo bajo el látigo del patrón. El mundo, fuera de la burbuja de los putos pijos de clase media, es un medio hostil, difícil, y nade regala nada. 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), cuando tengan que trabajar en cualquier sitio normal (fuera del enchufe pijo de sus padres) no duran una semana vivos.
#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
Espero que no me des negativo, ya que no te sienta mal que te lo digan.
buena forma de joder a las Apis privativa ... dando mas motivos usar Apis Libres
generalmente es el código fuente que tiene copyright pero las interfaces no deberían ya que la mayorías son librerías ya compiladas
un retraso en toda regla, imaginate que haces un juego en unreal y empieza a vender y el juez declara que las ganancias integras son para el dueño del motor y no un consenso entre el dueño del motor y del desarrollador del juego
#3 Mal ejemplo. Epic te licencia su motor para que puedas hacer exactamente eso, no hay forma teniendo la licencia que pase eso. Evidentemente sin licencia/permiso no puedes hacer un juego y venderlo, pero eso ya pasaba antes.
#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.
#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.
#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.
#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 videojuegohttps://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.
#33https://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" y no aprender nada, pues ya has ganado.
#41 Hola! Aprendí ensamblador con el Spectrum y de ahí todo ha ido a peor . 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.
#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.
#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.
#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.
#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?
#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.
#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á.
#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.
Si bien entiendo, ahora WINE es ilegal. Cualquier implementación libre de una API propietaria es ilegal porque la especificación pasa a estar protegida, cosa que antes no ocurría.
Creo que la gente se está haciendo la picha un lío con esta noticia.
Para empezar, el uso de APIs ya está sujeto a posibles restricciones mediante el uso de licencias. Por ejemplo, no puedo usar una librería con GPL si en la distribución de mi software no libero el código fuente con GPL por requisito de la licencia. Hay multitud de APIs (la de windows incluida) por las que hay que aceptar un EULA para su uso, ese al que le damos "acepto los términos" sin leer una línea.
No es el uso de APIs lo que se restringe, sino la copia. Básicamente, como dicen #13 y #43, Wine o ReactOS serían ilegales con esta ley si no tienen permiso explícito de Microsoft.
Para entenderlo mejor, hay que conocer el contexto de este juicio: se trata de Oracle vs. Google por la copia del API de java en android. Android se programa en java, pero su implementación no es la oficial de Oracle sino que es una implementación totalmente distinta con un API compatible, por lo que Google se libra de tener que pagar ninguna tasa a Oracle. Oracle demanda a Google por esto alegando que el API tiene copyright y por tanto Google no tiene derecho a desarrollar un software con un API compatible con java sin el permiso de Oracle, el dueño del copyright. Si esto prospera, el caso Oracle vs Google se resolverá con un acuerdo económico entre Google y Oracle y santas pascuas. El problema es que de paso joden a todo el mundo que está haciendo lo mismo que Google y que no tienen capacidad económica para hacer lo mismo.
#49 Eres tú el que estás confundiendo el API con la librería. La licencia GPL, por usar el ejemplo que tú has puesto, aplica a la implementación de la librería, no al API. Yo puedo coger el API de una librería GPL y reimplementarlo con una licencia que yo quiera (en Europa por lo menos).
Otro ejemplo es Wine. El EULA que aceptas de Windows es por usar su implementación. Wine es una implementación del API de windows, y por usarlo no tienes que aceptar el EULA de windows, si no la licencia de Wine, que es LGPL.
#8 El problema es por el uso de Java, en sus inicios era propiedad de Sun que tenía una actitud muy abierta con el uso de sus productos. Cuando la compró Oracle cambió radicalmente de enfoque. Cerró Solaris, se desprendió de OpenOffice (después de perder gran parte de los desarrolladores) y demandó a todo el mundo que no tenía nada firmado por Sun.
#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.
#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.
#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.
#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?
#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.
#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.
#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
#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.
#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.
#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.
#10 Ah, claro! Como no habiamos pensado en eso? Dejamos de programar en Java y listo.
Problema solucionado .
Ahora solo falta migrar hibernate, spring, SWT, y todos los principales frameworks de desarrollo a otros lenguajes.
Bueno, y migrar todos los millones de lineas de las aplicaciones existentes desarrolladas en Java.
Por supuesto, en algun momento del dia intentaremos reemplazar a toda nuestra plantilla de programadores expertos en java o entrenarlos en un lenguaje completamente nuevo.
Pero todo eso no son mas que detallitos. Lo que importa es que desde MAÑANA MISMO dejamos de programar en java.
#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
#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
#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...
#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.
#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
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"
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.
#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
#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
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.
#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.
#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.
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.
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.
#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.
#68#72En 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.
¿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.
#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)
#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).
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.
#36 API explicado sobresimplificando: son los nombres de las funciones de los lenguajes de programación o de un programa.
Si un lenguaje tiene una función llamado Math.round() que redondea un numero con decimales a un entero, pues el nombre "Math.round()" es parte de su API. Por ejemplo, la API de JAVA7 es http://docs.oracle.com/javase/7/docs/api/
Si un programa se maneja con tres botones, uno rojo, uno amarillo y otro verde, estos tres botones de colores son su API. La API de un semáforo son los colores rojo, ambar y verde.
Si. Es algo absurdo que se pueda restringir el uso o reimplementación de las APIs. Es mareante.
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")
#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í.
#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.
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.
#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.
#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?
#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.
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
“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.
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..
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.
#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.
(#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/
#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
#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?)
Comentarios
Para los que votan negativo a toda noticia que no tenga las palabras "Rajoy caca" o "el coletas es lo más" explico la relevancia de la noticia
Las APIS se utilizan para ahorrar tiempo de programación y espacio en las aplicaciones. Si bien en Europa no rige ya que el máximo tribunal y la normativa europea las excluyen de la protección de derechos de autor, el mercado norteamericano sigue teniendo mucho peso en el mundo de la tecnología. Esto significa aplicaciones más caras, más pesadas y concentración del mercado.
Aunque también puede ser bueno para plataformas como Ubuntu Touch y Firefox OS que se basan en apis libres
De todas formas, el desarrollo del software libre debería estar garantizado a escala planetaria. No es agradable volver a la época en que había unas versiones de software en EEUU y otras internacionales, debido a la ley de aquel país.
#1 además de los problemas que indicas, añadir el de interoperabilidad.
#7 Y la interoperabilidad pesa bastante más que el tiempo de desarrollo y el tamaño de las aplicaciones.
#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.
#53 Yo no voto irrelevante noticias sobre temas que no me interesan, lo hago con noticias irrelevantes sobre temas que si me interesan, y no insulté a nadie
#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.
#61 A los meneantes no, el comentario dice " Para los que votan negativo a toda noticia que no tenga las palabras "Rajoy caca" o "el coletas es lo más" explico la relevancia de la noticia"
En ninguna parte dice que sean todos los meneantes.
#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.
#74 first world problems everywhere!
#89 Mucho pijo mimado de clase media en este país. Ya se espabilarán cuando sus padres no puedan pagar la hipoteca y se vean viviendo en la calle, comiendo bocatas de mortadela (que eso es un lujo en Somalia) y trabajando de peón en el campo bajo el látigo del patrón. El mundo, fuera de la burbuja de los putos pijos de clase media, es un medio hostil, difícil, y nade regala nada. 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), cuando tengan que trabajar en cualquier sitio normal (fuera del enchufe pijo de sus padres) no duran una semana vivos.
#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
Espero que no me des negativo, ya que no te sienta mal que te lo digan.
#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?
#61 le estás dando la razón al votar irrelevante por una razón distinta a la naturaleza de la noticia
#1 No, no es bueno para nadie.
buena forma de joder a las Apis privativa ... dando mas motivos usar Apis Libres
generalmente es el código fuente que tiene copyright pero las interfaces no deberían ya que la mayorías son librerías ya compiladas
un retraso en toda regla, imaginate que haces un juego en unreal y empieza a vender y el juez declara que las ganancias integras son para el dueño del motor y no un consenso entre el dueño del motor y del desarrollador del juego
#3 Bueno, tenían que compensar lo del matrimonio gay, y que mejor manera de hacerlo que dándole por el culo a los desarrolladores
#3 Mal ejemplo. Epic te licencia su motor para que puedas hacer exactamente eso, no hay forma teniendo la licencia que pase eso. Evidentemente sin licencia/permiso no puedes hacer un juego y venderlo, pero eso ya pasaba antes.
#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.
#6 OpenGL es un API, no un engine.
#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.
#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.
#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.
#30 ok,lo que tu quieras.
#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
#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" y no aprender nada, pues ya has ganado.
#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?
#41 Hola! Aprendí ensamblador con el Spectrum y de ahí todo ha ido a peor . 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.
#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.
#46 #44 Venga, el mío fue "Basic Basico", allá por 1989, hace 26 años.
#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.
#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.
#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?
#40 Y lo que tu y todos conocemos por engine no es más que un api de librerías también.
#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.
#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.
#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.
Si bien entiendo, ahora WINE es ilegal. Cualquier implementación libre de una API propietaria es ilegal porque la especificación pasa a estar protegida, cosa que antes no ocurría.
#13 Y ReactOS esta en el mismo problema.
Creo que la gente se está haciendo la picha un lío con esta noticia.
Para empezar, el uso de APIs ya está sujeto a posibles restricciones mediante el uso de licencias. Por ejemplo, no puedo usar una librería con GPL si en la distribución de mi software no libero el código fuente con GPL por requisito de la licencia. Hay multitud de APIs (la de windows incluida) por las que hay que aceptar un EULA para su uso, ese al que le damos "acepto los términos" sin leer una línea.
No es el uso de APIs lo que se restringe, sino la copia. Básicamente, como dicen #13 y #43, Wine o ReactOS serían ilegales con esta ley si no tienen permiso explícito de Microsoft.
Para entenderlo mejor, hay que conocer el contexto de este juicio: se trata de Oracle vs. Google por la copia del API de java en android. Android se programa en java, pero su implementación no es la oficial de Oracle sino que es una implementación totalmente distinta con un API compatible, por lo que Google se libra de tener que pagar ninguna tasa a Oracle. Oracle demanda a Google por esto alegando que el API tiene copyright y por tanto Google no tiene derecho a desarrollar un software con un API compatible con java sin el permiso de Oracle, el dueño del copyright. Si esto prospera, el caso Oracle vs Google se resolverá con un acuerdo económico entre Google y Oracle y santas pascuas. El problema es que de paso joden a todo el mundo que está haciendo lo mismo que Google y que no tienen capacidad económica para hacer lo mismo.
#49 De acuerdo en todo, pero yo no usaría la palabra "copia" sino "reimplementación", porque no está copiando nada.
#49 Eres tú el que estás confundiendo el API con la librería. La licencia GPL, por usar el ejemplo que tú has puesto, aplica a la implementación de la librería, no al API. Yo puedo coger el API de una librería GPL y reimplementarlo con una licencia que yo quiera (en Europa por lo menos).
Otro ejemplo es Wine. El EULA que aceptas de Windows es por usar su implementación. Wine es una implementación del API de windows, y por usarlo no tienes que aceptar el EULA de windows, si no la licencia de Wine, que es LGPL.
#43 #13 Sólo en USA, por suerte. Y creo que en Rusia estarían encantados de acoger ambos proyectos.
ReactOS es seleccionado como segundo sistema operativo por el Gobierno Ruso
ReactOS es seleccionado como segundo sistema opera...
reactosnews.blogspot.com.es¿Y cuál es la novedad? La mayoría de las APIs te piden aceptar unas condiciones de servicio y de uso.
#8 El problema es por el uso de Java, en sus inicios era propiedad de Sun que tenía una actitud muy abierta con el uso de sus productos. Cuando la compró Oracle cambió radicalmente de enfoque. Cerró Solaris, se desprendió de OpenOffice (después de perder gran parte de los desarrolladores) y demandó a todo el mundo que no tenía nada firmado por Sun.
#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.
#10 Java es un problema en este juicio, ¿Pero que pasa con todas las otras api de licencia dudosa?
#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.
#37 Google usó para Android apis deJava cuyo uso Sun permitía pero Oracle no
#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.
#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?
#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.
#37 Deduzco que has dejado la parte técnica para dedicarte a la gestión de proyectos/equipos...
#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.
#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
#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.
#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.
#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.
#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.
#10 Ah, claro! Como no habiamos pensado en eso? Dejamos de programar en Java y listo.
Problema solucionado .
Ahora solo falta migrar hibernate, spring, SWT, y todos los principales frameworks de desarrollo a otros lenguajes.
Bueno, y migrar todos los millones de lineas de las aplicaciones existentes desarrolladas en Java.
Por supuesto, en algun momento del dia intentaremos reemplazar a toda nuestra plantilla de programadores expertos en java o entrenarlos en un lenguaje completamente nuevo.
Pero todo eso no son mas que detallitos. Lo que importa es que desde MAÑANA MISMO dejamos de programar en java.
#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
#94 A ver, vuelvo a repetir, si hay q realiza un NUEVA aplicación, no rehacer una ya hecha.
#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
#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...
#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.
#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
Si no hay APIS, usaremos MINA.
#19 #64 Ah, ese es el APIS que se distribuye comprimido en formato tar... y que para acceder hay que un-tar...
#BadumTss
Dios, es un chiste tan malo que no merece ni ser llamado chiste...
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"
#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
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.
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
Esto es lo que pasa cuando los legisladores tratan temas sobre los que no tienen ni puta idea . ¿Qué lobby habrá pagado para esto?
#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
#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
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.
#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.
#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.
Nos quieren hacer comulgar con ruedas de molino
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.
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.
#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.
#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.
#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.
¿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.
#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)
#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.
#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).
#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.
#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.
#36 API explicado sobresimplificando: son los nombres de las funciones de los lenguajes de programación o de un programa.
Si un lenguaje tiene una función llamado Math.round() que redondea un numero con decimales a un entero, pues el nombre "Math.round()" es parte de su API. Por ejemplo, la API de JAVA7 es http://docs.oracle.com/javase/7/docs/api/
Si un programa se maneja con tres botones, uno rojo, uno amarillo y otro verde, estos tres botones de colores son su API. La API de un semáforo son los colores rojo, ambar y verde.
Si. Es algo absurdo que se pueda restringir el uso o reimplementación de las APIs. Es mareante.
#36 Goto #131
Buen día para los desarrolladores de APIs...
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")
#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í.
¿Desde cuándo las APIs no se utilizan bajo una determinada licencia? Noticia monger del día.
#63 no lo has entendido
#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.
Larry Ellison necesita más pasta para sus barquitos... y para ayudar a Ironman
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.
Un buen día para el software libre.
Menuda estupidez. Y la de problemas que va a traer
No entiendo. No necesitas ya tener permiso para el uso de una api?
#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.
#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?
#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.
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
“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.
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..
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.
#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?
#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.
Esta corte perdió toda credibiiad desde que aprobó el matrimonio gay.
#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.
#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
(#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
http://dronesymoviles.com/moviles/corte-suprema-no-escuchara-la-apelacion-de-google-en-el-caso-de-la-api-de-java/
#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
#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?)