In questo caso, il difficile test legale sta decidendo se l'applicazione che consuma dati può essere considerata legalmente "combinata con" l'applicazione di produzione dei dati AGPL. La FSF propone che due programmi debbano comunicare " a distanza di braccia " per essere considerati lavori separati. (Il trucco di questa regola è che nessuno è del tutto sicuro di quanto siano lunghe le braccia dei programmi.)
In primo luogo, possiamo escludere che i requisiti AGPL vengano trasferiti tramite l'output di dati, consultando le Domande frequenti sulla GPL. Esiste una domanda che affronta direttamente questo (dall'altra parte - cercando e non riuscendo a fare Le regole GPL si applicano ai dati generati):
Is there some way that I can GPL the output people get from use of my program? For example, if my program is used to develop hardware designs, can I require that these designs must be free?
In general this is legally impossible; copyright law does not give you any say in the use of the output people make from their data using your program. If the user uses your program to enter or convert his own data, the copyright on the output belongs to him, not you. More generally, when a program translates its input into some other form, the copyright status of the output inherits that of the input it was generated from.
So the only way you have a say in the use of the output is if substantial parts of the output are copied (more or less) from text in your program...
Quindi, finché il crawler AGPL non include alcun dato con licenza GPL nel suo output (e non vedo alcun motivo per cui un crawler Web lo farebbe), allora i dati generati non hanno alcun carico di responsabilità AGPL .
Tuttavia, potrebbe accadere che il codice che consuma dati possa essere considerato legalmente parte dello stesso programma del codice di produzione dei dati AGPL, nel qual caso l'AGPL si applicherebbe all'intero lavoro. Senza vedere la tua architettura (e forse senza la sentenza finale un giudice), non è possibile per me dire se i due componenti possono essere chiamati un lavoro, ma le informazioni che hai presentato suggeriscono strongmente che le due componenti sembrano essere opere separate , legalmente parlando. Ancora, dalle Domande frequenti :
Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
Sembra che scrivere e leggere da un database rientri nella stessa ampia categoria di "pipe, socket e argomenti della riga di comando". Il tuo codice che consuma dati potrebbe essere eseguito senza che il codice di produzione dei dati venga eseguito sullo stesso computer: potresti avere un sistema che genera un database e quindi passare il database a un altro sistema che lo consuma. Da questo punto di vista, mi sembra chiaro (senza certezza legale) che i programmi siano lavori separati, e un utente che interagisce con il tuo processo Web che consuma dati non interagisce anche con il tuo codice AGPL che genera dati.