Problema di licenza #1383
Comments
|
Forse è meglio passare il modulo a LGPL chiedendo ai vari contributor? Mi pare sia quella più in linea, o vedi controindicazioni? |
|
Come licenza preferirei LGPL, però, dovendo coinvolgere altri moduli e contributors OCA, il cambio potrebbe essere difficile. |
|
Però l10n_it_account è già AGPL |
Sì penso convenga seguire questa strada.
Ogni autore è libero di scgliere la licenza (OSI-certified) che preferisce, vedi |
|
odoo spinge per la LGPL, non viene firmata un CLA anche per OCA? |
|
Sì: https://odoo-community.org/page/cla @sherpya quindi saresti per passare |
|
Il giorno mar 10 set 2019 alle ore 03:41 Gianluigi Tiesi <
notifications@github.com> ha scritto:
odoo spinge per la LGPL, non viene firmata un CLA anche per OCA?
Si, ma direi che non c'entra con il tipo di licenza (AGPL o LGPL) che poi
uno decide di utilizzare.
Personalmente tra le due preferirei la AGPL, in questo caso sembra anche
essere la strada meno complicata.
|
|
@eLBati come dice @primes2h è più semplice, e soprattuto ho notato che i moduli OCA sono quasi tutti AGPL, cosa che sarebbe in teoria adeguata per i moduli di odoo, nella pratica ti trovi a fare moduli che non possono essere dati sorgente perché ci sono cose riservate, o comunque al cliente gliene può fregare di meno di avere i sorgenti. |
|
Però il campo |
;( |
|
AGPL rompe le scatole ma protegge la natura OS del codice impedendo di fatto ad odoo s.a. di usarlo nel proprio codice o in alcuni casi nello store ... LGPL ha meno rogne ... la scelta e' individuale ... bisogna decidere tra purismo e buon senso (piu' buon viso a cattivo gioco) .. ma bisogna far i conti con i precedenti contributor che potrebbero non esser facili da raggiungere e/o ottenerne il consenso. EDIT: |
|
Non ho seguito approfonditamente tutta la querelle ma perche' mai dovrebbe
essere rilevante il consenso dei precedenti contributors?
Cioe' se un autore ha rilasciato illo tempore un'opera con una licenza ha
un qualche effetto "raggiungerlo" e chiedergli qualcosa?
A mio parere forse bisognerebbe riaggiornare il problema e renderlo chiaro,
a prescindere dagli interessi e dai problemi dei vari soggetti in gioco.
Marco
Il giorno sab 13 giu 2020 alle ore 00:13 Luigi Di Naro <
notifications@github.com> ha scritto:
… AGPL rompe le scatole ma protegge la natura OS del codice impedendo di
fatto ad odoo s.a. di usarlo nel proprio codice o in alcuni casi nello
store ... LGPL ha meno rogne ... la scelta e' individuale ...
Odoo S.A. spinge per lgpl per ragioni proprie ovviamente
OCA prima si voleva opporre poi ha deciso di cedere ....
bisogna decidere tra purismo e buon senso (piu' buon viso a cattivo gioco)
.. ma bisogna far i conti con i precedenti contributor che potrebbero non
esser facili da raggiungere e/o ottenerne il consenso.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1383 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHP246VBQABC4MMEQ5QXYP3RWKR67ANCNFSM4IHMPJMQ>
.
--
M a r c o M a r c h i o r i
consulente funzionale
dottore commercialista, revisore legale
Via Stazione 12, 30035 MIRANO (VE); telefono e fax 041 488195
codice fiscale MRCMRC67H11F241M; partita IVA 03813290271
--
*This e-mail may contain information that is confidential, privileged or
otherwise protected from disclosure. Use of such information is exclusively
reserved for the recipient of this e-mail.*
--
|
|
@marco-marchiori a meno di non avere un agreement come quello che chiede OCA o Odoo ai contributor non puoi variare la licenza senza specifica autorizzazione dei contributor altrimenti licenze come AGPL sarebbero inutili ... prendo, copio il codice gli cambio la licenza in quel che mi pare ed ho fatto. OCA o Odoo (o diverse altre community OS governate) possono farlo perche' chiedono esplicitamente ed ottengono autorizzazione preliminare dei contributor. |
|
@luigidinaro
io ponevo un problema molto piu' semplice: nel senso potrei "cambiare" la
licenza anche CON l'autorizzazione dei contributor?
Ma adesso che mi poni la questione sono andato a vedermi il CLA individuale
per capire cosa succede ora.
Bene ora un contributor associato ad OCA una licenza "totale" entro quali
limiti? Avete capito voi?
Il giorno sab 13 giu 2020 alle ore 12:01 Luigi Di Naro <
notifications@github.com> ha scritto:
… @marco-marchiori <https://github.com/marco-marchiori> a meno di non avere
un agreement come quello che chiede OCA o Odoo ai contributor non puoi
variare la licenza senza specifica autorizzazione dei contributor
altrimenti licenze come AGPL sarebbero inutili ... prendo, copio il codice
gli cambio la licenza in quel che mi pare ed ho fatto. OCA o Odoo (o
diverse altre community OS governate) possono farlo perche' chiedono
esplicitamente ed ottengono autorizzazione preliminare dei contributor.
La soluzione piu' semplice potrebbe essere far cambiare ad OCA la licenza
dei moduli, se ha le CLA, e portar tutto in LGPL visto che ormai molto
moduli son LGPL. In ogni caso il presidente ha sollevato un problema
spinoso.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1383 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHP246SI5BLPPEESGPRXPDLRWNE7NANCNFSM4IHMPJMQ>
.
--
M a r c o M a r c h i o r i
consulente funzionale
dottore commercialista, revisore legale
Via Stazione 12, 30035 MIRANO (VE); telefono e fax 041 488195
codice fiscale MRCMRC67H11F241M; partita IVA 03813290271
--
*This e-mail may contain information that is confidential, privileged or
otherwise protected from disclosure. Use of such information is exclusively
reserved for the recipient of this e-mail.*
--
|
|
Suggerisco di portare a AGPL tutti i moduli che dipendono da Solo in seconda battuta eventualmente valuterei il passaggio a LGPL di In questo caso bisogna avere il consenso di tutti i contributori di tutti i moduli coinvolti, in quanto detentori del copyright. Questo vale per qualunque operazione di re-licensing, indipendentemente dal CLA di OCA. Il CLA di OCA serve a dare anche a OCA il copyright sul codice che si sottopone a OCA. |
|
ma se ieri uno he ha firmato il CLA avesse contribuito a l10n_it_account
quale licenza si applicherebbe?
Il giorno sab 13 giu 2020 alle ore 17:05 Lorenzo Battistini <
notifications@github.com> ha scritto:
… Suggerisco di portare a AGPL tutti i moduli che dipendono da
l10n_it_account.
Per fare questo non è necessaria l'atuorizzazione di nessuno in quanto
l'utilizzo della licenza LGPL è stato illegittimo.
Solo in seconda battuta eventualmente valuterei il passaggio a LGPL di
l10n_it_account, quindi anche di account_tax_balance ed eventuali altre
dipendenze.
In questo caso bisogna avere il consenso di tutti i contributori di tutti
i moduli coinvolti, in quanto detentori del copyright. Questo vale per
qualunque operazione di re-licensing, indipendentemente dal CLA di OCA.
Il CLA di OCA serve a dare anche a OCA il copyright sul codice che si
sottopone a OCA.
Quindi anche a OCA bisogna chiedere il permesso per il cambio di licenza.
Il CLA è stato messo apposta per evitare che qualche autore possa in
futuro cambiare autonomanente licenza ai moduli OCA che ha scritto,
rendendoli ad esempio improvvisamente proprietari.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1383 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHP246RUYQNWHGTV5KXZCBDRWOIUJANCNFSM4IHMPJMQ>
.
--
M a r c o M a r c h i o r i
consulente funzionale
dottore commercialista, revisore legale
Via Stazione 12, 30035 MIRANO (VE); telefono e fax 041 488195
codice fiscale MRCMRC67H11F241M; partita IVA 03813290271
--
*This e-mail may contain information that is confidential, privileged or
otherwise protected from disclosure. Use of such information is exclusively
reserved for the recipient of this e-mail.*
--
|
Concordo con tutto.
|
|
Sara' che non sono un esperto, o non sviluppo, magari nello specifico
concordo con voi ma vi vedo un po' veloci nell'andare alle conclusioni.
Nel senso, non sarebbe il caso di analizzare piu' approfonditamente e
casomai non prendersi la briga di risolvere problemi creati da altri?
Inoltre quando leggo:
Il CLA è stato messo apposta per evitare che qualche autore possa in
futuro cambiare autonomanente licenza ai moduli OCA che ha scritto,
rendendoli ad esempio improvvisamente proprietari.
o
il CLA di OCA serve anche a proteggere gli sviluppatori in caso di dispute
legali riguardo il software sviluppato.
per forma mentis (scetticismo professionale) tendo a discostarmi da questi
approcci.
OCA si e' riservata una licenza, punto. Chiedo, quale?
Marco
Il giorno sab 13 giu 2020 alle ore 17:52 Sergio Zanchetta <
notifications@github.com> ha scritto:
… Suggerisco di portare a AGPL tutti i moduli che dipendono da
l10n_it_account.
Per fare questo non è necessaria l'atuorizzazione di nessuno in quanto
l'utilizzo della licenza LGPL è stato illegittimo.
Solo in seconda battuta eventualmente valuterei il passaggio a LGPL di
l10n_it_account, quindi anche di account_tax_balance ed eventuali altre
dipendenze.
In questo caso bisogna avere il consenso di tutti i contributori di tutti
i moduli coinvolti, in quanto detentori del copyright. Questo vale per
qualunque operazione di re-licensing, indipendentemente dal CLA di OCA.
Il CLA di OCA serve a dare anche a OCA il copyright sul codice che si
sottopone a OCA.
Quindi anche a OCA bisogna chiedere il permesso per il cambio di licenza.
Il CLA è stato messo apposta per evitare che qualche autore possa in
futuro cambiare autonomanente licenza ai moduli OCA che ha scritto,
rendendoli ad esempio improvvisamente proprietari.
Concordo con tutto.
Aggiungo solo che il CLA di OCA serve anche a proteggere gli sviluppatori
in caso di dispute legali riguardo il software sviluppato.
...and thereby allows us to defend the project should there be a legal
dispute regarding the software at some future time.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1383 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHP246TIIKKFMDYUTVLSGYLRWOOFDANCNFSM4IHMPJMQ>
.
--
M a r c o M a r c h i o r i
consulente funzionale
dottore commercialista, revisore legale
Via Stazione 12, 30035 MIRANO (VE); telefono e fax 041 488195
codice fiscale MRCMRC67H11F241M; partita IVA 03813290271
--
*This e-mail may contain information that is confidential, privileged or
otherwise protected from disclosure. Use of such information is exclusively
reserved for the recipient of this e-mail.*
--
|
Non una in particolare:
|
|
Dobbiamo intervenire su questi: l10n_it_fiscal_document_type: The license LGPL-3 conflicts with one of its dependencies. Please make sure that you comply with the licenses compatibility. See our FAQ at https://apps.odoo.com/apps/faq#maintainer_faq_04 . |
|
@eLBati faccio una pr |
Visto che |
|
è necessario intervenire anche qui |
|
@scigghia non ti risultano altri moduli da modificare oltre a l10n_it_fiscal_document_type ? |
|
fatto! ho aggiornato la PR 2360 |
|
non avevamo deciso di portare tutto in AGPL ? |
|
Non che io sappia, almeno sulla 12 non è così |
|
10 e 11 interessano o chiudo? |
|
There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. |
github-actions
bot
added
the
stale
l10n-italy/l10n_it_account_tax_kind/__manifest__.py
Line 14 in 98f3fb5
come indicato qui: https://apps.odoo.com/apps/faq#maintainer_faq_04 la licenza LGPL è compatibile solo con dipendenze LGPL, mentre questo modulo eredita l10n_it_account che è AGPL
dovremmo portare tutti i moduli sotto AGPL, perchè in questo caso odoo apps blocca l'indicizzazione del repository e quindi eventuali app che ne ereditano moduli
[12.0]change license to AGPL-3 #1643sostituita da [12.0] FIX license compatibility #1872, in aggiuntafix manifests to AGPL licenses #1891[12.0] FIX license LGPL-3 conflicts #1892The text was updated successfully, but these errors were encountered: