EDICIóN GENERAL
305 meneos
 

Wine ya tiene su código modificado de Parallels

Finalmente el pequeño enfrentamiento entre ambas y la supuesta violación de la LGPL parece haber llegado a su fin y, en principio, con un final feliz. Hace pocas horas Parallels ha entregado el código fuente de Wine modificado tal y como requiere la licencia a la que estaba acogida. Prácticamente un mes más tarde pero y ha sido entregado. Se acabo el culebrón. A ver si otras compañías toman ejemplo.

| etiquetas: wine , software libre , parallels
174 131 7 K 924 mnm
174 131 7 K 924 mnm
Esta vez "han pillado" a Parallels, ¿pero cuántas veces alguien habrá robado código de software libre para meterlo en software propietario y venderlo como tal?

Ojalá veamos pronto estos avances.
#7 Quizás deberías aprender un poco de ortografía.
#3 el problema, aunque parezca lo contrario, es para quien no comparte, ya que tendrá que ir adaptando sus modificaciones cada vez que haya cambios en la versión abierta. Al final, el listo termina siendo el gato y la versión abierta el ratón... que no para de correr.

Intentar quedarse en propiedad con un código abierto vivo es un cortoplacismo absoluto.
#0, ¿tomar ejemplo de qué?, ¿de cumplir con la ley tarde y a regañadientes? Han hecho lo que debían hacer, ni más ni menos. No hay nada que agradecer ni imitar.
#11 No creo, es imposible que haya código de software libre tan malo... :-P
#16 A ver, pero ese problema sigue existiendo cuando se hace un fork. No veo por qué hacer un merge tiene que ser a la fuerza más fácil entre dos proyectos open source que entre uno open source otro cerrado, si nacieron del mismo punto. Los forks nacen porque los desarrolladores quieren seguir caminos distintos, no porque quieran un skin diferente.

Depende de cómo difieren el que un merge sea fácil o difícil, pero exactamente igual pasaría en el caso de una rama cerrada y otra libre.
#5 No tiene por qué; si fuera como tú dices, nadie haría un fork nunca. Entre otras cosas, quizá los desarrolladores de Parallels vayan más rápido que los de Wine.
#13 la diferencia es que en un fork, ambas ramas pueden mirarse entre sí y avanzar a la vez (si hay interés en ello, claro) mientras que si es un programador/equipo-pequeño contra toda la comunidad, la balanza está un poco más desequilibrada.
#14 No necesariamente, en primer lugar, el equipo pequeño sigue teniendo acceso al código de la comunidad; y en segundo lugar, un equipo pequeño dedicado 8x5 horas a la semana probablemente haga más que 100 programadores que dedican una hora entre semana, aunque los segundos dediquen más del doble de horas.
#15 de acuerdo, sacan una versión en la que han invertido porrón de horas. Pasan un par de versiones y resulta que, como no devuelven el código, la rama abierta no incluye ninguna línea de esas modificaciones. La rama libre sigue por su camino y al final, los de la rama cerrada tienen que tragarse no sólo las modificaciones si no también el mantenimiento (no valen los parches de la comunidad) y la actualización de todo el código antiguo, al cual se le terminará no pudiendo añadir los parches…   » ver todo el comentario
esta noche ya puedo dormir tranquilo :-D
Espero que esto aparezca en wine-0.9.41.
comentarios cerrados

menéame