Questo sito utilizza cookie per le proprie funzionalità e per inviarti pubblicità e servizi in linea con le tue preferenze. Chiudendo questo banner, scorrendo questa pagina o cliccando qualunque suo elemento acconsenti all’uso dei cookie.

Accedendo al link http://www.odoo-italia.org/index.php/home/cookie-policy puoi leggere in dettaglio le modalità di trattamento dei cookie da parte dell'Associazione Odoo Italia.

Benvenuto, Ospite
Nome utente: Password: Ricordami
Siete i Benventi, fatevi conoscere con un bel saluto e una breve presentazione di Voi stessi. Sarà più facile aiutarvi.
  • Pagina:
  • 1
  • 2
  • 3

ARGOMENTO: Buongiono

Buongiono 1 Anno 8 Mesi fa #28266

  • gigidn
  • Avatar di gigidn
  • Offline
  • Platinum Boarder
  • Messaggi: 1925
  • Ringraziamenti ricevuti 446
  • Karma: 22
Ho sempre considerato AGPL piu' un limite che un vantaggio tranne forse in contesti specifici.

Faccio un esempio pratico cosi' si capisce il problema. Mi è stato commissionato un modulo per esportare i dati verso TeamSystem sulla V8 (AGPL). Fortunatamente la componente gira su server privati quindi non scatta l'obbligo di pubblicazione ma questa è facoltativa, il cliente potrebbe farlo ma lo fa lui a suo rischio e pericolo.

Il punto è semplice, distribuendo il software andrei a distribuire il protocollo TeamSystem e non ho nessuna autorizzazione per farlo, dovrei chiedere a TS apposita delega e non è detto che me la concedano.

Per ovviare a tele limite potrei scrivermi un mio protocollo che poi passo ad una componente completamente sganciata da odoo che a sua colta comunica con TS. In questo modo la licenza AGPL è soddisfatta ma il risultato è del codice inutile per la community ed una complicazione architetturale altrettanto inutile.

Come questo esistono migliaia di casi in cui non è che non si voglia ma proprio non si puo' pubblicare il codice.

Altro esempio: sto lavorando (a passatempo :D) ad un corveritore NMEA2000 ed ho dovuto scartare diversi librerie AGPL perchè si sarebbe creato un casino assurdo visto che il protocollo è blindatissimo, badate bene è il protocollo ad essere blindato non la sua implementazione quindi divulgare una sua implementazione è come divulgare la specifica e questo non è permesso.

E' altresi' vero che AGPL ha anche diversi vantaggi ma non è tutto oro quel che luccica.

Su "matura", "produttiva" etc etc è questione di lana caprina ... odoo è un framework ed il cliente "tipo" lo sceglie perchè l'insieme di funzioni disponibili minimizza l'attività di sviluppo. Se voglian usare la sigla ERP non ho mai visto un progetto che non abbia richiesto personalizzazione (si chiama progetto non a caso). Se poi con "produttiva" intentiamo lo prendo lo installo e lo uso allora nessuna implementazione di odoo è produttiva IMHO.

Sul fiscale stendiamo un velo pietoso, con le specifiche che cambia dall'oggi al domani che garanzia ho sul corretto funzionamento tra 1,2,5 mesi? bhe nessuna ... l'unica soluzione è un team interno in grado di intervenire ed adeguare o esternalizzare tale attività. Qualche esempio?

1) FatturaPA modificato il primo gennaio di questo anno
2) Lettere di Intenti: marzo di questo anno
3) Liquidazione IVA: maggio / forse meta' giugno
4) Spesometro: settembre (forse e se finalizzano le specifiche)

Ma in tutto questo odoo ha un grosso vantaggio ... vi potete scrivere le scritture a mano e poi lasciare che siano i software di AdE a convertire nei formati che voglino.

Se non ho la "lettera di intenti" posso comunque continua ad usare Odoo? .... SI, è un casino dover gestirlo a mano? ... SI
Senza il modulo della fatturazione di servizi ExtraEU posso usare Odoo? ... SI, è un casino dover gestirlo a mano? ... SI

my 2 cents
@KTec
www.ktec.it
L\'Amministratore ha disattivato l\'accesso in scrittura al pubblico.
  • Pagina:
  • 1
  • 2
  • 3
Tempo creazione pagina: 0.118 secondi

Odoo Italia Associazione - C.F: 94200470485 - Sede: Viale dei Cadorna, 83 - Firenze - Italy

Protected by R Antispam