Eli
305meneos

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.

 17 comentarios en: tecnología, software libre karma: 924
etiquetas: wine, software libre, parallels
negativos: 7  usuarios: 174  anónimos: 131  compartir:  twitter  facebook  friendfeed
últimas relacionadas
  1. #1   Relacionada meneame.net/story/parallels-viola-lgpl-de-wine
    votos: 6, karma: 62
    por habladorcito el 03-07-2007 10:02 UTC
  2. #2   » ver comentario
    por --37966-- el 03-07-2007 10:34 UTC
  3. #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.
    votos: 10, karma: 76
    por gskbyte el 03-07-2007 17:05 UTC
  4. #4   » ver comentario
    por --25046-- el 03-07-2007 17:37 UTC
  5. #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.
    votos: 3, karma: 35
    por bufalo_1973 el 03-07-2007 18:35 UTC
  6. #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.
    votos: 2, karma: 20
    por --5631-- el 03-07-2007 19:38 UTC
  7. #7   » ver comentario
    por --25046-- el 03-07-2007 20:20 UTC
  8. #8   » ver comentario
    por --32642-- el 03-07-2007 21:07 UTC
  9. #9   Espero que esto aparezca en wine-0.9.41.
    votos: 0, karma: 5
    por maya2012 el 03-07-2007 22:23 UTC
  10. #10   esta noche ya puedo dormir tranquilo :D
    votos: 0, karma: 6
    por darkknigt el 03-07-2007 22:41 UTC
  11. #11   » ver comentario
    por --33882-- el 03-07-2007 23:17 UTC
  12. #12   » ver comentario
    por --32642-- el 03-07-2007 23:59 UTC
  13. #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.
    votos: 0, karma: 7
    por gothmog el 04-07-2007 06:14 UTC
  14. #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.
    votos: 0, karma: 7
    por bufalo_1973 el 04-07-2007 17:54 UTC
  15. #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.
    votos: 0, karma: 7
    por gothmog el 04-07-2007 19:01 UTC
  16. #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.
    votos: 0, karma: 7
    por bufalo_1973 el 05-07-2007 00:07 UTC
  17. #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.
    votos: 0, karma: 7
    por gothmog el 05-07-2007 06:03 UTC
comentarios cerrados

menéame