[uylug-varios] no lo había pensado

Mon Jan 28 10:52:30 PST 2013

Fernando,
si el software libre es igualmente apto para la tarea, entonces en los OP
tendrán que invertir en recapacitar a su gente, porque hay una decisión
política de preferir el SL. Es así.

No se puede inferir de eso que deba hacerse a las 24 horas de promulgada
la ley. La propia ley establece la salvaguarda de "razones fundadas" y una
razón fundada para demorar una migración es la recapacitación de personal
y la permanencia de los servicios. Los OP cambian de aplicativos mas seguido
de lo que pensamos y a veces eso supone dificultades y tiempos de migración
(ejemplos sobran en Antel, BPS, UTE, etc). ¿Por qué eso no es un problema
cuando se pasa de un software privativo a otro privativo, y en cambio 
parece
tan problemático cuando es SL? Yo creo que no es otra cosa que prejuicios,
ignorancia, miedo al cambio y viento en contra por intereses comerciales.

De todas formas, aunque la ley no incluyera la salvaguarda de razones
fundadas, si la ley no establece plazos, el administrador tiene cierta
discrecionalidad para adecuarse a la norma y aún cuando haya plazos,
estos son siempre flexibles en razón de buena administración. El pasaje a
SL se irá haciendo gradualmente porque nadie querrá hacerse cargo de
una avalancha de recursos administrativos que pueden dejarlo sin trabajo.

Para cualquier migración el organismo deberá preparar un plan razonable 
y fijarse
plazos.  No hay nada raro ni dramático en eso, sucede todo el tiempo 
también
en el ámbito privado cuando se decide cambiar de plataforma y se 
planifica la
migración.

Eso es lo interesante de obligar a fundamentar las razones, pues de esta
forma se compromete al responsable informático a pensar, explicar y proponer
caminos para adecuarse a la ley. También se transparentan las 
dificultades -que
pueden ser ciertas y serias- y se abre la cancha para permitir que otros 
puedan
aportar ideas y soluciones a esas dificultades. Es una forma en la que 
también
todos aprendemos.

Gabriel.

El 28/01/13 14:16, Fernando Da Rosa escribió:
> Gabriel:
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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?.
>
> 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.
>
> Saludos
> Fernando
>
> El 28 de enero de 2013 12:10, Gabriel Sere <gabriel at internet.com.uy 
> <mailto:gabriel at internet.com.uy>> escribió:
>
>
>         "En caso de que se opte por software privativo se deberá
>         fundamentar
>         la razón basada en aspectos técnicos que no puedan ser
>         resueltos con
>         software libre."
>
>         [...] podría darse el caso en que no sea posible
>
>         "fundamentar la razón basada en aspectos técnicos que no
>         puedan ser
>         resueltos con software libre." para el mantenimiento de AP en
>         funcionamiento, dado que, por ejemplo, el tiempo necesario para su
>         desarrollo en software libre no es un "aspecto técnico".
>
>
>     No entiendo de dónde se infiere que el tiempo de desarrollo de una
>     aplicación en SL no es un aspecto técnico determinante para
>     descartarla entra las opciones disponibles.
>
>     No se puede comparar realidad con humo y buenos deseos.
>     Si la aplicación no existe, o está mal implementada y no puede ser
>     usada para el fin que se requiere, entonces no compite con una
>     aplicación existente y adecuada basada en software privativo.
>
>     Es simple: si la aplicación existe y cumple con las funcionalidades
>     requeridas, se toma en consideración y se compara con otras que
>     haya. Si todavía no existe, entonces es ciencia ficción, y se tendrá
>     en cuenta cuando exista y sea necesario renovar las licencias de
>     las privativas.
>
>     Dicho de otro modo: supongamos que no exista alternativa adecuada
>     al Autocad (digo "supongamos"). No se puede descartar su compra
>     basados en que hay algo parecido en SL que con el tiempo va a mejorar
>     y va a poder sustituirlo. Eso es software-ficción. Sin duda que se
>     compra el autocad y listo.
>
>     En todo caso la situación puede incentivar a acelerar el desarrollo de
>     una solución competitiva en SL, de manera que cuando haya que
>     renovar las licencias de autocad, esta nueva aplicación pueda ser
>     tenida en cuenta.
>
>     Gabriel.
>
>
>
>     _______________________________________________
>     Uylug-varios mailing list
>     Uylug-varios at listas.uylug.org.uy
>     <mailto:Uylug-varios at listas.uylug.org.uy>
>     http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy
>
>
>
>
> -- 
> Fernando da Rosa
> fernando.darosa at gmail.com <mailto:fernando.darosa at gmail.com>
> http://www.fedaro.info
>
>
> _______________________________________________
> Uylug-varios mailing list
> Uylug-varios at listas.uylug.org.uy
> http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.uylug.org.uy/pipermail/uylug-varios-uylug.org.uy/attachments/20130128/6351c68a/attachment-0002.htm>