Wine ya tiene su código modificado de Parallels

#1   Relacionada meneame.net/story/parallels-viola-lgpl-de-wine

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

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

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

#8   #7 Quizás deberías aprender un poco de ortografía.

#9   Espero que esto aparezca en wine-0.9.41.

#10   esta noche ya puedo dormir tranquilo

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

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

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

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

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

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