[uylug-varios] no lo había pensado

Mon Jan 28 11:51:38 PST 2013

Gabriel:

Estoy de acuerdo contigo, pero la ley modificada no dice eso. Las razones
fundadas serán solo aceptables, de acuerdo a dicha modificacion, cuando
haya aspectos técnicos no solucionables con software libre.

Por otra parte siempre existio un plazo de 180 días. Lee en detalle el
proyecto de ley.

Saludos
Fernando

El 28 de enero de 2013 16:52, Gabriel Sere <gabriel at internet.com.uy>escribió:

>  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>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
>> http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy
>>
>
>
>
> --
> Fernando da Rosa
> fernando.darosa at gmail.com
> http://www.fedaro.info
>
> _______________________________________________
> Uylug-varios mailing listUylug-varios at listas.uylug.org.uyhttp://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy
>
>
>
> _______________________________________________
> Uylug-varios mailing list
> 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
http://www.fedaro.info
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.uylug.org.uy/pipermail/uylug-varios-uylug.org.uy/attachments/20130128/4222f928/attachment-0002.htm>