Hi Thorsten,

On 12/01/2022 09:24, Thorsten Behrens wrote:

It is notoriously hard to separate commercial from non-commercial
activities.

It may be hard but to simplify things, as a first step, I would ask the submitter of a new project if they do it on behalf of a commercial entity or as a single contributor.

The past could give us some hints. Eg. TDF hosted a project called LOOL to which a few individuals contributed, when noticing that contributions were mostly coming from a commercial entity then that should tell us we need to look into it and evaluate risks and benefits for our community.

I believe putting up more barriers to entry for people
wanting to contribute to TDF projects is not smart.

I believe that leaving things unchecked isn't that smart either and we have seen the results.

I would not think it's smart to let me contribute to LibreOffice code unchecked as I haven't developed complex applications for the past 2 decades. That's why even for individual contributors we have "barriers" that do automated checks and other developers that review the code submitted.

Companies would understand some "barriers" as they are used to do due diligence checks even before starting to contribute with new projects and code. The point of those "barriers" are not only to make sure that TDF's ensure it protects LibreOffice and its community but to allow organisations to understand that by contributing they are engaging with an entity that has duties and objectives it has to fulfil.

"This agreement, to be drafted by our legal team in collaboration with TDF's
counsel, should be added to the proposal before voting as it should be part
of the on-boarding process for projects we intend to support."

That is the same agreement we should prepare, and eventually adapt, for
"atticisided", current and new projects hosted by TDF.

Instead, the board can always decide on a case-by-case basis that more
formalities are needed.
Unfortunately it seems like the board didn't realise that a big issue was brewing for quite a few years as clear rules were not set.

True that while a project is being developed most focus on making it work and successful but then there must also be some non developers that look at the situation and raise a red flag when they see eventual issues forming.

This is what I did as my second serious warning in regards to activities that I believed needed some corrections just a month after I joined the board.

Now we have a case that clearly tell us that the board should set a rule where projects that are controlled for more than 50% by a single commercial organisation need to be reviewed and we need to evaluate what risks it may pose for our community and our investments and implement eventual corrective actions which could include the drafting of a clear agreement.

Putting this burden on everyone **up-front** and **by default** (with
the added twist that people need to prove their contribution is not
commercial), I believe is a terrible idea. TDF would be well-advised
to have fewer, not more, hurdles for code contribution.
You may have missed that in my previous emails I clearly stated that the "burden" is not up-front, is not by default and people do not need to prove their contribution is not commercial.

I actually said: "I'm not even suggesting that each individual proposing a project should sign it, only when the project is being proposed by or it becomes controlled mostly by a single company."

I've also mentioned 2 clear examples:

1) A great contributor to LibreOffice, and incidentally one of TDF's founders, presented a potentially great project in 2011. Excellent! Let's support the project, host it on our infrastructure and promote it as it seems a great contribution to LibreOffice and it will surely deliver great new features to our community.

In 2013 the contributor incorporates a company and most of the contributions started to come from there. Great! We are all very pleased that LibreOffice and its community enabled a contributor to find a business model that helps delivering more innovation but... how will at this point the need to generate revenue affect the project that we host? I suppose nobody thought of that question.

I understand that back then it was seen as a non issue because every one was working with the same goal of making LibreOffice the best Open Source office suite but not having clear rules for corporate contributions led to the current situation.

2) Another great contributor to LibreOffice, and incidentally one of TDF's founders, had another brilliant idea that has been presented as a potential alternative way to have LibreOffice in a browser back in 2015. That same great contributor, which has been merging his code to LibreOffice core, is now presenting this technology through his new company.

I'm sure that the company has fully evaluated the implications of working with TDF, which has duties in relation to it own investments and clear objectives, also in light of issue 1 above but AFAIK there is still no clear definition of the relationship between TDF, the company in question and what the community can expect to receive "for use by anyone free of charge".

I'm also sure that we don't want to find ourselves having the same arguments we had in relation to LOOL because there was no clear agreement in regards to what our community can freely use and what the company considers to be essential differentiations that allows them to be commercially successful.

I hope is now clear to you that the proposal shows that there is no intention to burden anyone with anything that doesn't go beyond protecting each parties interests and investments.
Let's discuss on Friday, all the best,

-- Thorsten
Happy to discuss that in the public part of the meeting and to get feedback from both individuals and corporate contributors.

Ciao

Paolo

--
Paolo Vecchi - Deputy Member of the Board of Directors
The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE
Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts
Legal details: https://www.documentfoundation.org/imprint


Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to