Hace 16 años | Por --37966-- a tuxpepino.wordpress.com
Publicado hace 16 años por --37966-- a tuxpepino.wordpress.com

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.

Comentarios

gskbyte

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.

D
D

#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.

D

#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.

D

#11 No creo, es imposible que haya código de software libre tan malo...

g

#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.

D

#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 abiertos por estar cada vez más separados.

La principal baza que le veo al software abierto es que evita la divergencia exagerada, ya que se comparte código siempre con los demás. Los forks no son tampoco demasiado diferentes del original, normalmente. Lo que hacen es modificar un código común y tener sus propias modificaciones. Si otro fork quiere, puede agregar código de esas modificaciones, haciendo que los forks se acerquen entre sí. Finalmente, si la cosa sale como toca, los forks terminan reunificándose, incluyendo las mejoras de cada rama.

g

#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.

D

#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.

g

#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.

D

#3 microsoft lo hace?

D

esta noche ya puedo dormir tranquilo

m

Espero que esto aparezca en wine-0.9.41.

D

Porque votan negativo a mi comentario #4? no dice nada contra nadie... solo digo que hay compañias pribadas que usas software libre sin permiso. vaya :-?

D

le da a uno verguenza ajena, al ver como se aplovechan de la umildad del software libre... me ofenden esas compañias propietarias tan malas.