¿La gente está realmente preocupada por usar React y ReactNative con el lenguaje que está en el archivo PATENTS de Facebook?

Posiblemente sí, si le preocupa que infrinjan sus patentes y mantengan a su software / sitio web / aplicación como rehén para negociaciones legales / financieras. Proporcionaré un caso de uso en el que su empresa podría verse perjudicada debido al archivo de patentes adicionales.

Tome un hospital que use React y ReactNative en su sitio web y aplicación de reservas. Ahora, alguien en este hospital tiene una patente relacionada con la cirugía remota, que utiliza la realidad virtual de alguna forma, un campo en el que FB está invirtiendo fuertemente. FB se interesa por su patente y se pone en contacto con el hospital pidiéndole permiso para usar la patente de forma gratuita, aprovechando el hecho de que pueden mantener como rehenes al sistema de reservas del hospital, porque si el hospital no está de acuerdo y decide demandarlos, su licencia para la tecnología que potencia su sistema de reservas será revocado. Dado que la patente de telecirugía no va a ser tan importante desde el punto de vista financiero como el funcionamiento del sistema de reserva de todos modos, y el hospital posiblemente no pueda desarrollar un sistema de reserva completamente nuevo o un negocio en torno a la patente en poco tiempo, se verá obligado a llegar a un acuerdo de uso de patentes en gran medida a favor de FB.

Por supuesto, el escenario final depende del caso; por ejemplo, si dicho hospital presenta la cura del cáncer, es viable registrar una entidad legalmente separada dedicada al desarrollo de la cura del cáncer donde no se utilizará ninguna patente de FB. Del mismo modo, una empresa como Microsoft no necesita preocuparse por usar React en proyectos pequeños como una aplicación de Skype o algo así; si es necesario, tienen los recursos para reemplazarlo completamente con algo que no use una sola línea de javascript o, por el contrario, tiene poco sentido que una universidad construya todo su sitio web en React.

Sin embargo, el problema con el archivo de patentes, tal como lo veo, es que está contaminando todo el ecosistema de código abierto. Si utiliza una biblioteca que depende de una biblioteca que depende de un módulo Apollo que utiliza GraphQL de alguna manera, todavía le está dando a FB la opción de infracción de patente. Después de unos años, FB puede comenzar a abusar de esta escapatoria y será demasiado tarde para que la gente descubra que FB es solo otra corporación con poca preocupación por la buena voluntad. Aguas fangosas.

Creo que es muy peligroso usar el software de “código abierto” de Facebook. ¿Qué sucede si su empresa crece en un área que amenaza a Facebook o si se expande en un área que se superpone con su empresa? Podrían infringir sus patentes y usted no podría hacer nada al respecto, o correría el riesgo de tener que reconstruir su aplicación. Uno nunca debe suponer que los abogados “harán lo correcto”.

No solo eso, sino que ahora hay que tener cuidado al tener el software de Facebook como una dependencia de una biblioteca o marco. No es solo React, sino que immutable.js y GraphQL también tienen estos términos de patente. Los desarrolladores y gerentes de proyecto deben ser extremadamente cuidadosos.

• React License – Concesión adicional de derechos de patente
• Lamentablemente, esto tiene la nueva y horrible cláusula de patentes de Facebook. Para aquellos que no son aw …
• Lo primero que hago ahora en cada revelación de código abierto de Facebook es verificar la AP … Posición de Google: ” Trabajo en Google, donde muchos están tristes de no poder usar el código reciente de Facebook ” .

En mi humilde opinión, Facebook está envenenando software gratuito y de código abierto con esta estrategia. Hasta que eliminen las reclamaciones de patentes, no creo que las empresas deban usar estas bibliotecas. Es posible que desee buscar alternativas como Vue o Mercury.

La gente está preocupada, pero ¿deberían estarlo?

El ingeniero front-end de Facebook, Christopher (que trabaja con React y React Native casi exclusivamente) organizó un AMA en Hashnode. Lo primero que hizo fue responder a los problemas relacionados con el problema de la licencia de reacción.

AMA con Christopher Chedeau – Hashnode

Dale una lectura. Cubre algunas cosas importantes en su respuesta.

1. ¿Por qué Facebook está haciendo lo que está haciendo?

2. Comunicados de prensa de Facebook relacionados con el tema.

3. Su opinión general sobre todo el tema y cómo se siente sobre la forma en que se ha manejado

Esta respuesta es de mi publicación original ” ¿React Native es una buena opción para el desarrollo de aplicaciones móviles a largo plazo? ”

Durante el último año, React Native ha ido ganando popularidad entre los desarrolladores de aplicaciones móviles. También hay un aumento muy constante en el número de aplicaciones de producción y de código abierto escritas usando React Native. Facebook, el mantenedor de React Native, ha hecho que sea relativamente fácil para los desarrolladores aprender y adoptar React Native al adoptar el lenguaje JavaScript demasiado familiar. Los desarrolladores que ya tienen experiencia con Javascript encontrarán que React Native es una excelente opción. El desarrollador de PhoneGap encontrará que aprender y adelantarse a la curva de aprendizaje es relativamente fácil. ¿Pero es React Native una buena opción para una aplicación estable a largo plazo?

Limitaciones y desventajas de React Native

En este artículo, intentaré mencionar la limitación y las áreas grises que actualmente tiene React Native. La mayoría de estas deficiencias están siendo abordadas por Facebook y la comunidad React Native. Pero hay algunas preocupaciones que podrían evitar que saltes de un barco al desarrollo de la aplicación móvil React Native. Siempre es bueno saber estas preocupaciones con suficiente antelación.

• El desarrollo de aplicaciones nativas tiene sus ventajas
  Sabemos que Javascript es rápido, pero Java, ObjC y Swift son más rápidos, especialmente para cálculos pesados. Es un hecho conocido que el código JavaScript no es tan eficiente para las tareas de cálculo intensivo, y hay una sobrecarga cuando JavaScript controla elementos nativos. JavaScript tiene un único subproceso de dispositivo dedicado, mientras que el código nativo es libre de usar los subprocesos que desee. En rendimiento, React Native se queda atrás de una aplicación nativa optimizada.

  Si su aplicación no está haciendo mucho trabajo pesado (es decir, en términos de uso intensivo de memoria o CPU), React Native parece una muy buena opción. Después de haber trabajado con plataformas híbridas y nativas antes, si su aplicación está haciendo un montón de trabajo pesado, aún recomendaría el desarrollo nativo como una forma de administrar más de cerca cosas como el uso de CPU y la huella de memoria.

• Actualizaciones constantes de la plataforma.
  React Native es una plataforma relativamente joven y emergente. Mientras que el desarrollo nativo es bastante maduro. iOS (ObjC) y Android (Java) han estado en movimiento durante casi 10 años y hay algunas herramientas realmente excelentes que se han desarrollado en ese momento. Esto no es realmente una desventaja, sino más bien otro punto que React Native tiene mucho que ponerse al día. Debido a su entrada relativamente nueva, React Native está en pleno desarrollo, y se lanza una nueva versión cada mes. Las actualizaciones constantes traen nuevos componentes nativos portados, personalizados mejorados (como el Navegador), correcciones de errores y mejoras de rendimiento. Esto es bueno en términos de actividad de la plataforma. Pero es una mala elección si la aplicación se va a mantener a largo plazo, ya que cada compilación puede requerir la actualización de la plataforma, lo que conlleva una verificación de dependencia para la base de código existente. La incorporación de estas nuevas versiones requiere actualizaciones vigilantes de nuestro propio código si cambia la lógica de los componentes preconstruidos. Por lo tanto, los desarrolladores tendrán que hacer un esfuerzo para incorporar estos cambios a fin de mantenerse al día con la plataforma. Muchas personas toman React Native entendiendo completamente esta situación. Pero si está consultando a un cliente, asegúrese de que comprenda este hecho.
• Lenguaje vagamente escrito
  React Native utiliza código JavaScript, hojas de estilo CSS y etiquetas HTML para el diseño. El lado bueno es que podemos usar todos los mejores aspectos de JavaScript, pero por supuesto, el lado malo es que trae algunos de los horrores de Javascript. A diferencia de Java y Swift, Javascript no aplica un tipo de variables y parámetros a las funciones. Es decir, cualquier variable puede ser cualquier cosa en cualquier momento. Los desarrolladores deben seguir la disciplina y los estándares que practican en su lenguaje de programación nativo fuertemente tipado
• Dependencia del idioma nativo
  Si una funcionalidad que necesita no está disponible actualmente en React Native, terminaremos escribiendo módulos nativos. Los módulos nativos son una forma de puentear el código nativo y el código React Native. El módulo nativo debe estar escrito en Java y rápido / objetivo c. Posiblemente, en algún momento durante su desarrollo, tenga que pedir ayuda a un desarrollador nativo o hacerlo usted mismo en el idioma nativo.
• Limitaciones de las capas de abstracción
  React Native es una abstracción, lo que significa que hay una gran cantidad de código entre el desarrollador y la plataforma nativa para la que está desarrollando. Un problema importante con las abstracciones son los errores. Si encuentra un problema con la capa de abstracción, es posible que deba profundizar en la implementación y solucionarlo usted mismo. ¡Esto puede llevar mucho tiempo y puede encontrar problemas que no puede resolver! Otro problema con las capas de abstracción es que usted depende de un tercero no solo para la corrección de errores, sino también para mantener su marco actualizado. El mundo de iOS se mueve muy rápido, y otras compañías como Xamarin tienen que trabajar muy duro para mantener actualizada su capa de abstracción. Otra fuga de abstracción menos obvia son las funciones a las que no puede acceder. La mayoría de las capas de abstracción están incompletas porque hay algunas características del sistema subyacente que no están expuestas a través de la capa de abstracción.
• Compromiso a largo plazo y compatibilidad con la próxima versión del sistema operativo
  Una preocupación importante con el uso de React Native es la falta de compromiso a largo plazo con el proyecto. React Native no es un plug-and-play como CocoaPod, no es un simple SDK, no es una mera biblioteca, es una plataforma completa de desarrollo de software. Si Facebook deja de mantener React Native, mi aplicación se estancará y no habrá un “Reemplazo de React Native” a nuestra disposición. Hemos visto que esto sucede con Facebook con Parse.

  La adaptación a las nuevas versiones del sistema operativo será lenta. En otras palabras, actualmente no tiene ninguna garantía de que alguna vez sea compatible con iOS 11 o 12.

• Licencia y controversia de patentes
  Por último, pero una de las preocupaciones más importantes con React Native es su controversia sobre licencias y patentes. Junto con su licencia permisiva de estilo BSD, React Native se entrega con la concesión adicional de derechos de patente de Facebook, versión 2. La semana pasada, Facebook actualizó su licencia de código abierto y patente para React, ReactNative y otros proyectos de código abierto. Según la actualización, su derecho a usar los proyectos de código abierto de Facebook se rescindirá si demanda a Facebook por un problema de patente. En la práctica, esto parece un elemento disuasorio para usar Facebook sobre las patentes. Por implicación, también parece darle a Facebook un buen respiro para infringir patentes dentro de la aplicación que usa React Native. Este cambio en particular ha creado mucho pánico en torno a los desarrolladores que usan React, React Native y otros proyectos de código abierto. Este cambio dio como resultado que Automattic, el creador de WordPress, abandonara por completo su reescritura de código de WordPress en React (no React Native). ¡Eso fue un trabajo de años! La Fundación Apache había anunciado anteriormente que ya no usarán el código de licencia BSD + Patents de Facebook para nuevos proyectos. Estos incidentes suenan pesimistas. Pero debe ser pesimista al evaluar las licencias y patentes de software.

  Recientemente Facebook volvió a licenciar sus proyectos de código abierto React, Jest, Flow e Immutable.js bajo la licencia MIT y eliminando la licencia de estilo BSD + Patents. Este es un movimiento muy positivo de Facebook, ya que han reconocido las preocupaciones de la comunidad de código abierto. Espero que usen lo mismo para la licencia MIT para React Native, que todavía está bajo la licencia de estilo BSD + Patents.

Puede sentir que algunas de las limitaciones mencionadas aquí también son válidas para plataformas híbridas o incluso nativas. La intención de este artículo es hacerte consciente de la limitación de la plataforma antes de dar el salto al desarrollo nativo reactivo. Con la atención actual que React Native está reuniendo en la comunidad actual de desarrollo de aplicaciones móviles, estoy seguro de que en el futuro, React Native podría superar a PhoneGap y Xamarin.

Parece, al leerlo, que Facebook otorga explícitamente una licencia de patente a cualquier persona que use React Native, pero inmediatamente la revoca si intenta demandarlos por reclamos de patentes sobre cualquiera de ellos.

O, en otras palabras, una licencia de patente gratuita para cualquiera que no sea lo suficientemente estúpido como para patearlos.

Creo que el área de mayor preocupación debería ser con las startups. Si eres una empresa nueva con sueños de ser comprada o tragada por una empresa más grande (¿y quién no?) Me alejaría de React.

Es una biblioteca increíble , pero supongo que cualquier empresa que se pelee con Facebook por patentes ni siquiera lo mirará.

Si mi análisis es correcto, por ejemplo: suponga que Google está en litigio con Facebook sobre algunas patentes, no podrían comprar su empresa ya que está utilizando React y su licencia para hacerlo sería revocada en el momento de la adquisición debido a que no está relacionado lucha.

Sí, algunas personas lo son. Si trabaja para una compañía de software que tiene patentes, al usar React le está otorgando a Facebook una licencia gratuita para sus patentes. Esto se debe a que React.js tiene lo que se conoce como una “fuerte cláusula de represalia por patente”. Puede leer más sobre patentes y licencias de código abierto aquí: lj9

El código abierto de la tecnología de uso diario y su uso gratuito será necesario para todas las empresas. De lo contrario, llevará más tiempo capacitar a nuevos empleados para esta habilidad. De todos modos, soy un fanático de React JS, te sugiero que tú y otros desarrolladores front-end lo usen. Incluya HHVM, Facebook mantiene su patente. Pero no creo que sea un problema para nosotros usarlo en los negocios.

Facebook acaba de publicar en su blog hace unos días que entienden que esta licencia podría haber alejado a los desarrolladores de su plataforma, por lo que cambiaron la licencia:

Facebook relicenses Reacciona ante la reacción violenta de código abierto del desarrollador | ZDNet

Trabajo en una gran multinacional y he estado usando React para el desarrollo de una gran aplicación durante aproximadamente un año. Recientemente, nuestro equipo legal ha aconsejado que nos alejemos de React lo antes posible. Tal aviso del medio legal significa que las compañías están realmente preocupadas por el lenguaje en el archivo de Patentes.

Si un software no está bajo MIT o Apache, sí, debería estar preocupado, es tan simple como eso, por qué harían todo el camino para crear su propia licencia si pretenden regalarla de forma gratuita.