<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Fernando, <br>
si el software libre es igualmente apto para la tarea, entonces en
los OP<br>
tendrán que invertir en recapacitar a su gente, porque hay una
decisión <br>
política de preferir el SL. Es así.<br>
<br>
No se puede inferir de eso que deba hacerse a las 24 horas de
promulgada <br>
la ley. La propia ley establece la salvaguarda de "razones
fundadas" y una <br>
razón fundada para demorar una migración es la recapacitación de
personal<br>
y la permanencia de los servicios. Los OP cambian de aplicativos
mas seguido<br>
de lo que pensamos y a veces eso supone dificultades y tiempos de
migración<br>
(ejemplos sobran en Antel, BPS, UTE, etc). ¿Por qué eso no es un
problema<br>
cuando se pasa de un software privativo a otro privativo, y en
cambio parece <br>
tan problemático cuando es SL? Yo creo que no es otra cosa que
prejuicios,<br>
ignorancia, miedo al cambio y viento en contra por intereses
comerciales.<br>
<br>
De todas formas, aunque la ley no incluyera la salvaguarda de
razones <br>
fundadas, si la ley no establece plazos, el administrador tiene
cierta<br>
discrecionalidad para adecuarse a la norma y aún cuando haya
plazos,<br>
estos son siempre flexibles en razón de buena administración. El
pasaje a<br>
SL se irá haciendo gradualmente porque nadie querrá hacerse cargo
de<br>
una avalancha de recursos administrativos que pueden dejarlo sin
trabajo.<br>
<br>
Para cualquier migración el organismo deberá preparar un plan
razonable y fijarse <br>
plazos. No hay nada raro ni dramático en eso, sucede todo el
tiempo también <br>
en el ámbito privado cuando se decide cambiar de plataforma y se
planifica la <br>
migración.<br>
<br>
Eso es lo interesante de obligar a fundamentar las razones, pues
de esta<br>
forma se compromete al responsable informático a pensar, explicar
y proponer<br>
caminos para adecuarse a la ley. También se transparentan las
dificultades -que<br>
pueden ser ciertas y serias- y se abre la cancha para permitir que
otros puedan<br>
aportar ideas y soluciones a esas dificultades. Es una forma en la
que también <br>
todos aprendemos.<br>
<br>
Gabriel.<br>
<br>
<br>
El 28/01/13 14:16, Fernando Da Rosa escribió:<br>
</div>
<blockquote
cite="mid:CAAeuT1sedeB7M2ZrYoMqp2V9J89zUHqvqdmfGyd_smky1gL4hQ@mail.gmail.com"
type="cite">Gabriel:<br>
<br>
También se puede dar el caso de que tengan AUTOCAD, por seguir con
tu ejemplo y exista una muy buena aplicación libre, creo que si
existen. Pero el organismo en cuestión gasto X dinero durante años
en capacitar a los arquitectos y ayudantes en el uso de AUTOCAD y
no puede pasar rápidamente de un programa al otro. <br>
<br>
No es una excepción técnica pero es probable que se genere un gran
problema si no se les da tiempo para capacitar al personal y luego
poner en funcionamiento el software libre correspondiente. ¿Se
entiende mi planteo?. Acá existen ambos paquetes de software pero
por un tema de capacitación se debería hacer una excepción por x
tiempo.<br>
<br>
El tema es el siguiente, si yo quiero ir al norte y tengo una
buena brújula, se donde esta el norte, pero si voy directo al
norte me voy a chocar con una gran cantidad de obstáculos, de todo
tipo, tengo que tener la posibilidad de consultar el mapa e ir
cambiando el curso, siempre con la meta de ir al norte, pero en
algunos momentos voy a tener que virar al este o al oeste,
inclusive nuevamente al sur si encuentro un obstáculo insalvable.
¿Se entiende? por eso en la redacción original las excepciones se
debían fundamentar y punto, luego en la reglamentación se
instrumentaría la forma de evaluar si dichas excepciones estaban
bien fundadas o no. Usando el ejemplo anterior, si estaba o no
fundamentado cambiar momentáneamente de curso para evitar un
obstáculo y llegar mejor y más rápido a la meta final. <br>
<br>
Los problemas de software que se pueden encontrar en el Estado no
son solo técnicos, son casi imprevisibles a priori, por eso creo
que lo mejor es dejar la opción de fundamentar las razones,
seguramente vamos a encontrar fundamentaciones que nos van a
sorprender. <br>
<br>
Por otra parte con ese texto estamos aceptando que el software
libre hay aspectos técnicos que no puede resolver, lo cual es
claramente falso. Pero lo van a usar en nuestra contra. Es un
grave error, que nos genera ataduras varias. <br>
<br>
Otro problema legal que tiene la ley es que no define que es
software privativo, lo nombre y no dice que es. Me parece bien
haber agregado una capítulo de definiciones, antes las mismas
estaban en la fundamentación, pero si se agrega un capítulo
expresamente para las definiciones hay que incluirlas. De lo
contrario alguien se puede preguntar ¿qué es software privativo
para esa ley?.<br>
<br>
Y podría seguir con otros temas de los agregados realizados, como
por ejemplo, el tema de incluir un texto dedicado casi
exclusivamente a una empresa uruguaya. En fin, tiene muchas
desprolijidades, por decir algo suave, la modificación del
proyecto. Por suerte lo peor, haber incluido el tema patentes se
puedo arreglar el día de la votación. Lo cual llevo a legisladores
que pocos días antes habían votado dicho inciso a tener que
votarlo en contra pocos días después, lo cual no es nada bueno
para la imagen de la bancada que presento el proyecto. <br>
<br>
Saludos<br>
Fernando<br>
<br>
<div class="gmail_quote">El 28 de enero de 2013 12:10, Gabriel
Sere <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:gabriel@internet.com.uy" target="_blank">gabriel@internet.com.uy</a>></span>
escribió:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
"En caso de que se opte por software privativo se deberá
fundamentar<br>
la razón basada en aspectos técnicos que no puedan ser
resueltos con<br>
software libre."<br>
<br>
</div>
[...] podría darse el caso en que no sea posible
<div class="im"><br>
"fundamentar la razón basada en aspectos técnicos que no
puedan ser<br>
resueltos con software libre." para el mantenimiento de AP
en<br>
funcionamiento, dado que, por ejemplo, el tiempo necesario
para su<br>
desarrollo en software libre no es un "aspecto técnico".<br>
<br>
</div>
</blockquote>
<br>
No entiendo de dónde se infiere que el tiempo de desarrollo de
una<br>
aplicación en SL no es un aspecto técnico determinante para<br>
descartarla entra las opciones disponibles.<br>
<br>
No se puede comparar realidad con humo y buenos deseos.<br>
Si la aplicación no existe, o está mal implementada y no puede
ser<br>
usada para el fin que se requiere, entonces no compite con una<br>
aplicación existente y adecuada basada en software privativo.<br>
<br>
Es simple: si la aplicación existe y cumple con las
funcionalidades<br>
requeridas, se toma en consideración y se compara con otras
que<br>
haya. Si todavía no existe, entonces es ciencia ficción, y se
tendrá<br>
en cuenta cuando exista y sea necesario renovar las licencias
de<br>
las privativas.<br>
<br>
Dicho de otro modo: supongamos que no exista alternativa
adecuada<br>
al Autocad (digo "supongamos"). No se puede descartar su
compra<br>
basados en que hay algo parecido en SL que con el tiempo va a
mejorar<br>
y va a poder sustituirlo. Eso es software-ficción. Sin duda
que se<br>
compra el autocad y listo.<br>
<br>
En todo caso la situación puede incentivar a acelerar el
desarrollo de<br>
una solución competitiva en SL, de manera que cuando haya que<br>
renovar las licencias de autocad, esta nueva aplicación pueda
ser<br>
tenida en cuenta.<span class="HOEnZb"><font color="#888888"><br>
<br>
Gabriel.</font></span>
<div class="HOEnZb">
<div class="h5"><br>
<br>
<br>
_______________________________________________<br>
Uylug-varios mailing list<br>
<a moz-do-not-send="true"
href="mailto:Uylug-varios@listas.uylug.org.uy"
target="_blank">Uylug-varios@listas.uylug.org.uy</a><br>
<a moz-do-not-send="true"
href="http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy"
target="_blank">http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Fernando da Rosa<br>
<a moz-do-not-send="true" href="mailto:fernando.darosa@gmail.com"
target="_blank">fernando.darosa@gmail.com</a><br>
<a moz-do-not-send="true" href="http://www.fedaro.info"
target="_blank">http://www.fedaro.info</a>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Uylug-varios mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Uylug-varios@listas.uylug.org.uy">Uylug-varios@listas.uylug.org.uy</a>
<a class="moz-txt-link-freetext" href="http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy">http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy</a>
</pre>
</blockquote>
<br>
</body>
</html>