1. Mailing Lists
  2. Contributors
  3. Re: New module derived from Odoo CE licensing/credits question

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: New module derived from Odoo CE licensing/credits question

Avatar

Re: New module derived from Odoo CE licensing/credits question

by
MoaHub, Graeme Gellatly
- 31/07/2021 21:07:53
Hi,

A couple things from what happens in practice.

Firstly in this case it seems unnecessary. So it is better not to. It is always preferable not to.

Secondly, the purpose of that clause in CLA is mostly 3 fold. 

1 it allows us to change a license to another OSI approved license without having to gain approval of all copyright holders.
2 it allows us to defend the copyrights in court (in many jurisdictions including the US you must have a 100% claim to be able to take a court case).
3 it gives us protection over the history of the copyright and licence (e.g. that the code isn't "stolen" from a private code base, basically that it is licensed correctly)

For Odoo SA derived code, of which we have quite a bit, not just OCB, we effectively have option 1 off the table. We just notate the README as such for those modules that we cannot change license without Odoo SA approval. In practice, this is a minor concern. If Odoo SA relicenses, and the module is still current, then we can relicense to the same to be compatible. Otherwise, we might need to ask their permission, which is in their interest. 

For the second case, in any such action, Odoo SA is a) going to take action themselves, b) we'd have to join them in court action and it is likely to be in their interest, c) it isn't worth it.

It is kind of 1 of the 2 exceptions for pragmatic purposes to the CLA. And in large part it is because in any enforcement we either don't care or our interests are aligned. The other exception is where 3rd party content is bundled, such as js libs. But again, we don't care, because we wouldn't want to defend or change license.

The 3rd case doesn't matter, as Odoo SA has an upstream CLA and we can check the license.



On Sat, Jul 31, 2021 at 9:37 PM Frederik Kramer <frederik.kramer@initos.com> wrote:
Am Freitag, den 30.07.2021, 18:29 +0200 schrieb Radovan Skolnik:


> Frederik,

HI Radovan,



> 


> it will be interesting to hear on this licensing-vise. Regarding


> this:


> > but they also inheretly hand over rights (that they


> > don't own) to the OCA in the first place.


> From my understanding you can fork/modify all you want provided you


> keep the 


> original author and license as well and distribute such work further.

yes for the LGPL that is perfectly fine.



> For me 


> this seems like this scenario: someone (in this case S.A.) publishes


> module 


> under LGPLv3. Someone else (in this case me) takes it, modifies its 


> functionality retaining original copyright as well and submits it to


> be 


> included in some other project (OCA) with the same licensing. I fail


> to see 


> where a problem could be in this scenario. But I am not alawyer ;-)

The problem here is 

https://raw.githubusercontent.com/OCA/odoo-community.org/master/the-association/ICLA.pdf

Section 3.b:

"You own the Copyright and patent claims covering the Contribution
which are required to grant
the rights under Section 2."

As you "own" only your contribution but the code that you contribute
is, as you said 90% done elsewere and by somebody else not filling this
ICLA (i.e. S.A.), this paragraph is simply not applying. 

Anyway as i said this is the very same problem (as Holger pointed out)
with the OCB code, so i wonder how we as a community deal with that.
Thats why am loudly asking for others' opinion. 

Disclaimer: I am no lawyer mayself either but i have dealt with these 
matters in my scientific carreer quite a bit.

Best and have a nice weekend 

Frederik  




> 


> However what Holger suggested is probably much better approach. My


> module 


> will:


> 1) depend on the Odoo one


> 2) only modify stuff that is different


> 3) disable what is not needed from the original one


> 


> This will provide pretty simple/dense module.


> 


> Best regards


> 


> 	Radovan


> 


> On piatok 30. júla 2021 18:17:04 CEST Frederik Kramer wrote:


> > Hi Radovan,


> > i tend to agree to what Holger just said, but you hit a general


> > problem


> > that to me is somewhat unsolved. This is as follows:


> > OCA is requiring (and checking) if contributions are made by


> > contributors that have signed the ICLA / CLA. By signing these


> > documents one claims that the code he or she add to he baseline is


> > his


> > / her own in its entirety.


> > Now afaik S.A. itself (though publishing its core code in LGPLv3)


> > isn't


> > officially contributing to the OCA but other OCA contributors do.


> > This


> > means by pushing the OCB code these contributors already work in a


> > grey


> > zone because what they do is legally absolutely fine (i.e.


> > contributing


> > to LGPLed code) but they also inheretly hand over rights (that they


> > don't own) to the OCA in the first place.


> > I might be wrong but OCB is a special case and your contribution


> > would


> > be like OCB (as Holger just said) but it cannot be treated an


> > ordinary


> > contribution to an arbitrary OCA repo, at least if we as the


> > community


> > would retain the right to defend the IPR of the entire set of code


> > against uncompliant use (example Flectra).


> > With that having said, i kindly ask you to wait pushing the code


> > until


> > some other (prefierably long term contributors and members have


> > added


> > their interpretation of the legal case). Ususally our vice


> > president


> > Graeme has some nice and valuable thoughts on these matters.


> > Best and have a nice weekend


> > Frederik


> > 


> > Am Freitag, den 30.07.2021, 15:56 +0000 schrieb Radovan Skolnik:


> > > Holger,


> > > 


> > > thanx for an input. I initially thought to make it in a way so


> > > that


> > > both modules can work side-by-side. But that is probably pretty


> > > useless so your idea is actually pretty good and would make the


> > > module really small.


> > > 


> > > The code and templates I removed are for


> > > product.attribute.category


> > > for product.attribute to group them. I think I cannot (can I?)


> > > disable the code so the additional object/table/column will be


> > > there.


> > > However I would like to disable the templates relating to these


> > > so


> > > they do not confuse the user. According to a Google search it can


> > > be


> > > done in this way:


> > > 


> > > <record id="full_external_id_of_the_template" model="ir.ui.view">


> > > 


> > >     <field name="active" eval="False"/>


> > > 


> > > </record>


> > > 


> > > If I uninstall my module will the active statu return to its


> > > previous


> > > state? Should I use anything like that or just document in the


> > > readme


> > > that the product.attribute.category is useless while using


> > > custom.info?


> > > 


> > > Best regards


> > > 


> > > Radovan


> > > 


> > > On piatok 30. júla 2021 13:47:19 CEST Holger Brunn wrote:


> > > > > Would such module be acceptable for OCA? Any comments


> > > > > are welcome. Best regards


> > > > 


> > > > shouldn't be very different than backporting an Odoo SA module,


> > > 


> > > right?


> > > 


> > > https://github.com/OCA/odoo-community.org/blob/master/website/Contribution


> > > /


> > > 


> > > > CONTRIBUTING.rst#backporting-odoo-modules


> > > > But if there's so little changes, why can't you just depend on


> > > > the


> > > 


> > > module


> > > 


> > > > and change what's to be changed in your code?


> > > > _______________________________________________


> > > > Mailing-List: https://odoo-community.org/groups/contributors-15


> > > >  [1]


> > > > Post to: mailto:contributors@odoo-community.org


> > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [2]


> > > > 


> > > > 


> > > > 


> > > > [1] https://odoo-community.org/groups/contributors-15


> > > > [2] https://odoo-community.org/groups?unsubscribe


> > > 


> > > _______________________________________________


> > > Mailing-List: https://odoo-community.org/groups/contributors-15


> > > Post to: mailto:contributors@odoo-community.org


> > > Unsubscribe: https://odoo-community.org/groups?unsubscribe


> > 


> > --


> > Dr.-Ing. Frederik Kramer


> > Geschäftsführer


> > initOS GmbH


> > An der Eisenbahn 1


> > 21224 Rosengarten


> > Phone: +49 4105 56156-12


> > Fax:  +49 4105 56156-10


> > Mobil: +49 179 3901819


> > Email: frederik.kramer@initos.com


> > Web:  www.initos.com


> > Geschäftsführung:


> > Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke


> > Sitz der Gesellschaft: Rosengarten – Klecken


> > Amtsgericht Tostedt, HRB 205226


> > Steuer-Nr: 15/200/53247


> > USt-IdNr.: DE815580155


> > 


> > _______________________________________________


> > Mailing-List: https://odoo-community.org/groups/contributors-15 [1]


> > Post to: mailto:contributors@odoo-community.org


> > Unsubscribe: https://odoo-community.org/groups?unsubscribe [2]


> > 


> > 


> > 


> > [1] https://odoo-community.org/groups/contributors-15


> > [2] https://odoo-community.org/groups?unsubscribe


> 


> 


> 


-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer
        
initOS GmbH
An der Eisenbahn 1
21224 Rosengarten
        
Phone:  +49 4105 56156-12
Fax:    +49 4105 56156-10
Mobil:  +49 179 3901819
        
Email: frederik.kramer@initos.com
Web:   www.initos.com
        
Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Rosengarten – Klecken
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

Reference