La Cámara de Comercio de Bogotá (CCB) informó recientemente sobre un conjunto de normas en el sector informático, que buscan beneficiar tanto a clientes como a proveedores de esta industria. Estas normas se conocen como costumbres mercantiles, y pretenden brindar herramientas que exijan calidad en los servicios y que eviten posibles abusos en las transacciones comerciales.
Las costumbres mercantiles no están en el Código de Comercio, y tampoco están contempladas en ningún decreto o ley, pero representan reglas que le garantizan a los clientes, por ejemplo, que un programa informático venga con garantía de buen funcionamiento por el primer año después de su compra. La Cámara de Comercio considera este tipo de prácticas como cotidianas en el comercio de bienes y servicios de un sector determinado, y así las certifica como una costumbre.
Sin embargo, para que un hábito sea reconocido como una costumbre mercantil se deben tener en cuenta algunas condiciones. Por ejemplo, esa práctica no debe ir en contra de ninguna ley o norma establecida en la regulación vigente; además, debe ser un hábito que se realice repetidamente en el sector.
Para el sector informático en Bogotá y Cundinamarca tenemos seis costumbres mercantiles que ya están certificadas por la CCB:
1. El licenciante debe entregarle al licenciatario código objeto del mismo.
2. En los contratos de licencia de software, el término de mantenimiento es distinto a soporte de software.
3. En los contratos de licenciamiento de software se debe dar a los clientes garantía de un año.
4. Todos los visitantes de un sitio en internet o una página web, por el solo hecho de estar navegando en ellas, se obligan automáticamente a respetar los términos y condiciones sobre su uso.
5. La página web o sitio web se considera como parte del establecimiento comercial.
6. El proveedor de software es responsable de hacer la actualización de los manuales, tanto de los técnicos como de usuarios, sin ningún costo adicional.
Imagen: Pixabay.
diría que en general, falso. ni son prácticas establecidas, ni se imponen ni se deben asumir.
1. lo de entregar código depende de la licencia. lo que sí debe ser práctica y el que no lo hace está pagando la novatada, es precisamente especificar las reglas de la licencia. así como existen diferentes licencias, unas de open source y entre esas también existen diferentes tipos delicencia, otras de uso exclusivo, otra cosa es desarrollo ala medida, otras como lo s sistemas operativos donde por comprar windows no le entregan el código de windows, cuando se firma el contrato debe especificarse qué es lo que se entrega. si es und esarrollo a la medida, y no una herramienta que se vende a varias compañías, es posible que en el contrato que se firma y que las partes acuerda, puedfe que vaya lo de entrega de fuentes, y así mismo, que esas fuentes no se revenderán ni se usarán por terceros ni con otros propósitos que los que se establecen en el contrato d elicencia original.
y si el contrato está bien hecho, de hecho debería tener cláusulas acerca de transferencia delicencias, como qué pasa si deciden vender el sistema a otra compañía o algo así
más bien, en vez de mencionar buenas prácticas que asíc omo están acá están bastante incompletas, mencionar que para loq ue tiene qué ver con informática, así como existenm normas iso, también existen normas que tieen qué ver con la redacción de contratos, y eso sí debería ser buena práctica, y se pyede reglamentar simplemente estableciendo la certificación. si yo hago una herramienta y la voy a vender a varios entonces entrego las fuentes, y que aunque la legislación es débila cá en uestión de informática (no existen patentes der algoritmos, todo está cubierto como derechos de autor como obra literaria, y los casos legales son como los de jsuticia penal donde uno se pregunta dónde está lña justicia, que se demuestra la derivación de algo que se entregó con acuerdo de confidencialidad y lo revenden como si lo huebiarn hehco ellos), pues si no se establece que hay qué entregar fuentes, no se entrega fuentes. por otro lado puede que contratar con ciertas entidades sea requisito entregar fuentes. los de la c´ñamara de comercio no saben de lo que están hablando, y no debefrían opinar sin haberse enterado antes
2. mantenimiento es distinto a soporte. para eso están los contratos. sí, el hecho de hacer la aplicació no implica que sehaga soporte; para eso se establece en el contrato en qué consiste lo que hacela compañía o qué eslo que entrega, y tampoco incluye operación dela herramienta si eso no está en elc ontrato, y todo contrato de desarrollo se firma en base a unos requerimientos. si no hay requerimientos acordados por las dos partes, no tiene por qué hacerse. acá no hay buenas prácticas genéricas, porque no hay aplicaciones genéricas qu eincluyan requerimientos genéricos. Por otro lado, todo trabajo que sehace tiee garantía, y eso sí es ley y está reglamentado en el código de comercio, y no sólo para aplicaciones o programas sino para todo lo que está cubierto en el código de comercio. la garantía o lo que cubre la garantía debe es`pecificarse en el contrato, y eso incluye el arreglo del programa o el soporte o la capacitación sobre los arreglos o lo que sea. lo que cubra la garantía S´´I debe estar en el contrato. y la garantía no es implícita, y sí existe como ley, pero para evitar ambiguedades debe quedar explícito de qué es lo que cubre, cómo lo cubre y por cuánto tiempo
3. igual que punto anterior, eso se debe aclarar entyre desarrollador y cliente. no es práctica estandarizada
6. actualización de manuales: uno delos graves problemas en el desarrollo es hacer algo sin requisitos o requerimientos acordados. si no, hay ambiguedad tanto por el desarrollador como el cliente en cuanto en dónde termina el desarrollo. que el desarrollador haga algo chambón y diga ya terminé. o el cliente quiera que le haganc osas que no se habían acordado y el desarrollador sia con un proyecto indefinidamente en cosas que nos e habían acordado. lo de actualización del manuales y demás. se entiende que los manuales deben corresponder a lo que hace la herramienta y si la herramienta cambia los manuales dse deben ajustar, si es que el contrato incluía manuales, porque puede que en cambio sea una capacitación al personal, y que el personal haga los manuales. pero si el desarrollo no es indefinido, y a la herramienta no se le van agregar funciones con elt iempo, ni es un proyecto indefinido sino que se desarrolla y ya, este punto no se aplicaría. ni existe la obligación de cambiar la herramienta si no fue eso lo acordado, que sería como decir que tieen actualizaciones gratis indefinidamente. si no es eso lo que se acordó, por qué toca hacerlo así. eso depende de lo acrodado
Como se nota que los que quieren implementar esto no tienen ni IDEA de que es el desarrollo de software, solo de pensar que si compro una licencia de windows me tiene que dar el código??????????????