Caso Astrolabe, il Sole sorge senza copyright

Astrolabe annuncia la dismissione della causa intentata contro i gestori del database dei fusi orari, si scusa e promette di non peccare più. Nel mentre il database era già stato messo al sicuro da ICANN

Roma – Si conclude in maniera positiva la questione Time Zone Database (TZD), l’archivio online aggiornato dei fusi orari mondiali finito in tribunale a seguito della denuncia di Astrolabe : la società specializzata in software astrologico ha ritirato le accuse, promettendo inoltre di non farlo più e chiudendo la faccenda una volta per tutte.

David Olson e Paul Eggert, storici manutentori del database in costante aggiornamento e ampiamente usato da sistemi operativi (Unix, Linux) e siti web in tutto il mondo, erano stati denunciati da Astrolabe con l’accusa di violazione di copyright: il database dei fusi orari conteneva materiale incluso nel software della società e non sarebbe pertanto potuto essere riprodotto senza l’opportuna autorizzazione.

Olson e Eggert avevano dunque chiesto assistenza legale alla Electronic Frontier Foundation (EFF), ed è proprio la EFF ad annunciare ora la resa incondizionata di Astrolabe su tutti i fronti: si è convinta che “fatti storici” come gli orari in cui sorge il Sole “non sono proprietà di qualcuno”, dice di aver male interpretato la legge e promette formalmente di non denunciare più nessuno per la stessa questione.

Per i manutentori del progetto TZD finisce una brutta avventura, mentre il database vero è proprio era già stato messo in sicurezza con l’ intervento diretto di IANA : l’authority si era detta disposta ad affrontare le questioni legali sollevate in merito al database, ma evidentemente non sarà più necessario passare per le armi le bellicose richieste di royalty di Astrolabe.

Alfonso Maruccia

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • uno nessuno scrive:
    novità
    L'articolo ci dice essenzialmente che ci sono delle novità, ma non dice quali.Essenzialmente:* Moduli multiproXXXXX: c'erano già, ma ora sono stabili. Questo ottimizza l'uso della CPU, soprattutto su Windows (sigh).* Una moltitudine di nuovi moduli (andate a vedervi la lista sul sito, personalmente trovo molto interessante il modulo Lua, che per esempio potrebbe essere utile per scrivere dei test per applicazioni web...)* Nella configurazione, è ora possibile inserire istruzioni condizionali che vengano valutate ad ogni sessione.Saluto Mariuccia, che avrebbe dovuto scrivere queste cose al mio posto, e in maniera più approfondita.
    • iome scrive:
      Re: novità
      - Scritto da: uno nessuno
      L'articolo ci dice essenzialmente che ci sono
      delle novità, ma non dice
      quali.

      Essenzialmente:
      * Moduli multiproXXXXX: c'erano già, ma ora sono
      stabili. Questo ottimizza l'uso della CPU,
      soprattutto su Windows
      (sigh).
      * Una moltitudine di nuovi moduli (andate a
      vedervi la lista sul sito, personalmente trovo
      molto interessante il modulo Lua, che per esempio
      potrebbe essere utile per scrivere dei test per
      applicazioni
      web...)
      * Nella configurazione, è ora possibile inserire
      istruzioni condizionali che vengano valutate ad
      ogni
      sessione.

      Saluto Mariuccia, che avrebbe dovuto scrivere
      queste cose al mio posto, e in maniera più
      approfondita.*cuogh* cialtrone *coff coff* copia e incolla *coff coff*
  • Nome e cognome scrive:
    meglio tardi che mai..
    La concorrenza fa bene anche all'open source!
  • Vault Dweller scrive:
    Sarà...
    ...ma nginx è assolutamente inutile per le pagine dinamiche, o meglio è più lento di diversi ordini di grandezza rispetto ad apache (figuriamoci lighttpd); per questo dubito che l'attenzione di apache verso le prestazioni siano dovute a nginx anche perché nginx è solitamente usato come reverse proxy per gestire il carico indirizzato a pagine e contenuti dinamici su uno o più server performanti in tali ambiti ( nginx+lighttpd || nginx+httpd(apache) )
    • Cherokee Fan scrive:
      Re: Sarà...
      Guarda che il grosso del traffico viene consumato dalle immagini, dalla grafica, dai file esterni css, js, ecc... e tutti questi file elencati sono contenuti statici!!!!Per questo motivo ci sono diversi siti grossi che utilizzano un doppio server, uno per i file dinamici (lato server) e uno per quelli statici (lato client).
      • collione scrive:
        Re: Sarà...
        ma poi è una vecchia leggenda metropolitana che nginx è lento con le pagine dinamichegià nel 2009 apache+modphp e nginx+php/fastcgi, si vedeva un minimo vantaggio per apache e le cose sono migliorate ulteriormentepersonalmente, da quando ho sostituito apache con nginx, ho visto netti miglioramenti sui miei siti
        • Confuso scrive:
          Re: Sarà...
          - Scritto da: collione
          ma poi è una vecchia leggenda metropolitana che
          nginx è lento con le pagine
          dinamiche

          già nel 2009 apache+modphp e nginx+php/fastcgi,
          si vedeva un minimo vantaggio per apache e le
          cose sono migliorate
          ulteriormente

          personalmente, da quando ho sostituito apache con
          nginx, ho visto netti miglioramenti sui miei
          sitiAzzo, in 3 commenti avete detto tutto ed il contrario di tutto, ed adesso io a chi devo credere???? da noi un nostro fornitore monta rh enterprise + apache2 per far girare applicazione java, per una pagina che non fa più di 4 (dico 4!) accessi contemporanei (semplice visualizzazione dati da un db) mi chiede un server da 4gb di ramMa a voi pare normale? non è che l'applicazione è scritta da cani?scusate l'ot
          • Bidon Bidon scrive:
            Re: Sarà...

            Ma a voi pare normale? non è che l'applicazione è
            scritta da cani?La seconda che hai detto.. :-)
          • Nome e cognome scrive:
            Re: Sarà...
            Te lo faccio io in python + flask + gunicon con 60MB di RAM.
          • Confuso scrive:
            Re: Sarà...
            - Scritto da: Nome e cognome
            Te lo faccio io in python + flask + gunicon con
            60MB di
            RAM.Grazie, sei molto gentile (anche se immagino avrai voluto un compenso), il problema è come al solito che il fornitore detiene tutta la documentazione su come accedere al suo DB.Comunque i fornitori da me si dividono in due rami: da una parte chi macchine linux e db oracle che poi hanno l'applicazione java su apache (sempre sotto linux).Dall'altra server windows con db sql express che poi mettono l'applicazione web su IIS + asp, vedo che usano librerie comprate che si somigliano tutte ma adesso non ho tempo di trovare il link.Non so, non vedo ottimizzazione. Zimbra invece ha una bella interfaccia web, reattiva e tutto sommato leggera mi sembra.
Chiudi i commenti