<div><br></div><div class="gmail_quote">El 12 de agosto de 2010 12:58, acm <span dir="ltr"><<a href="mailto:ana.cichero@gmail.com">ana.cichero@gmail.com</a>></span> escribió:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Mas allá de la anécdota, está bueno que se discuta este tema de propiedad de proyectos y del valor de las ideas. <br><br>¿Tiene una persona derecho a decir este proyecto es mio, este proyecto es tuyo, este proyecto es de ella? Yo pienso que si, pero capaz esté equivocada.... <br>
<br>¿Qué pasa cuando por ejemplo, un tema de tésis, es concretado por otra persona que no es la que lo propuso e investigó originalmente? ¿ Qué se dice en esos casos? Sin duda la tésis terminada se publica y es enteramente de dominio público. <br>
<br>El proyecto no es un producto pronto.... <br>¿Qué pasa cuando no llegaste a licenciar lo que estabas haciendo porque no estaba pronto? ¿Antes de la primer versión, cuando sólo tenés una lista elaborada de requerimientos sin licenciar , no podés decir " tengo un proyecto"?<br>
<br>¿Se entiende que las ideas llevan tiempo?<br>No me refiero a las ideas generales, sino a la planificación de todos los detalles de requerimiento de un sofware por ejemplo.<br>Que alguien pueda explicar en menos de 25 minutos los requerimientos para un sw no implica que le haya costado 25 minutos cranearlo.<br>
<br>Reivindico el derecho de decir este proyecto es de tal persona en el marco del sw libre .<br><br></blockquote><div><br></div><div><br></div><div>El ownership es base fundamental para el sustento del software libre como tal. A causa de este es que se puede adjuntar licencias particulares (documentos legales) a las piezas de software. Eso lo puede hacer unicamente el autor ya que por defecto los derechos son asignados a este.</div>
<div><br></div><div>Por otro lado, el software libre es que es construido con trabajo colectivo, casi en la totalidad de los casos, ya sea usando librerias, usando herramientas, o codigo de terceros que sin ellos seria imposible la existencia del proyecto.</div>
<div>El software libre se construye, generalmente, con el esfuerzo de varios y siempre es reconocida la labor de los que los contribuyen, ya sea implicitamente (mediante uso de software de terceros con licencias libres) o explicitamente. Por lo general, la comunidad de SoL siempre es muy correcta a la hora de reconocer esfuerzos e ideas ya que de eso se nutre. </div>
<div><br></div><div>Tener una idea es solo una parte del todo, se requiere mucho trabajo para formalizar y realizar una pieza de software de calidad. Pienso que en ultima instancia los que lo ejecutan son los que deberian mantener el ownership, primero por merito, y segundo por motivos de proteccion legal (no estoy hablando de empresas que emplean gente) ya que no es lo mismo defender la autoria de algo mediante pruebas feacientes a un "la idea fue mia". Segun como lo veo el ownership se deberia aplicar sobre resultados, no sobre conceptos o ideas (la eterna discusion sobre patentes).</div>
<div><br></div><div>Remarcar que un proyecto es unicamente de una persona en el ambiente SoL no solo esta mal visto, sino que efectivamente es -en la mayoria de los casos- erroneo, una manera poco "abierta" de trabajar en comunidad. Hay pocos ejemplos del efecto que esto produce, y lo que termina ocurriendo muchas veces es lo que se llama un "fork". Se toma el codigo y se arma un proyecto paralelo por las personas que difieren con el autor inicial y/o no estan recibiendo el merito que corresponde. </div>
<div><br></div><div>En el caso que tu planteas de la tesis, tambien existen reglamentaciones para controlar que los meritos sean dados a quien se lo merece. No citar una fuente y pasar trabajo de otro como propio en una tesis es una falta grave.</div>
<div><br></div><div>La ingenieria de software y la programacion es un trabajo que consiste en relevar una realidad, y solucionar problemas creando una herramienta. Tu hiciste gran parte, que fue el relevo inicial, ahora formalizar eso en requerimientos tecnicos, crear un programa informatico y mantenerlo va bastante mas alla. Segun como lo veo ese proyecto va a ser tan tuyo como el/los que lo ejecutan. Si no reconoces el trabajo del que lo ejecuta tanto como él debe reconocer el tuyo, dificil que vea la luz o termine en buen puerto. </div>
<div><br></div><div>Todas las piezas son importantes, pero por sobre todo, hacerlo colectivamente, en un ambiente positivo es lo prioritario.</div><div><br></div><div><br></div><div><br></div><div>P.D: Disculpen el largo, me extendi mas de lo sano.</div>
<div><br></div><div><br></div><div>Saludos,</div><div><br></div><div>Miguel Paolino</div><div><br></div><div><br></div><div><br></div></div>