I suggest asking Carlo Piana to release this approved text as Version 1 (it is currently Version 0.9) by fixing the remaining bits, in order to start working immediately at Version 2. As the current version covers only a subset of potential tenders (namely, all those where development competencies are available at all levels, which are a few in comparison with real development needs), Version 2 is quite urgent, and should be ready not later than June 30, 2025. As I am unable to work with Git and markdown, I will create a LibreOffice based version of the text, where I will add comments to existing sections and add missing sections.
hi all, directors,
Can the directors supporting this resolution please explain their view on the relation between legal advise and the boards decisions?
For reference: here are the items that the board changed compared to the lawyers version.
(Noticing that several of the mistakes are still present in the currently voted ‘Procurement Policy’…)
For future reference, it is useful to know why the word ‘affiliate’ had been replaced by ‘associate’ in the version approved by the board last year.
Despite what had been brought forward in the advice, the words ‘affiliate/affiliation’ are certainly defined by the Foundation’s statutes, and meant as a clear parent-daughter business relation. The (binding) German text is very clear: “für dieselbe Firma, Organisation oder Einheit oder einer ihrer Tochterorganisationen als Angestellte arbeiten.”
So the English version has always been interpreted in the way that is common in business (see e.g.this article and this one: ‘affiliation’ is about control, direct saying, shares.
‘Association’, on the other hand, is broader, and much more in line with what is meant in the procedure.
(Noticing NB that the currently voted ‘DEVELOPMENT AGREEMENT’ does use a different definition of ‘affiliation’, much more in line with as defined in the Statues).
So if there is any confusion in the future, please remind this information…
Really appreciated Italo. I expect there is important input to use, before any tendering can actually start again.
I agree, but felt an end-of-year end-of-validity for the current version was reasonable to allow for unforeseen delays. I would be happy to consider an earlier date such as you propose, however.
I agree on the end of the 2025 year as a final deadline, but I would really try to have version 2 ready before the summer break.
My impression was that the last board already published and voted through an adequate policy. The “not approved by the lawyers” polemic against that version seems to be pure posturing - given the description of the rather trivial changes from the lawyer approved version.
When it comes to that - I’d love to know what lawyer approved the current version complete with FIXMEs - was that really signed off !? and by whom? The board has made changes, and then apparently regressed this to a state where we do not have a functioning, bug-free policy - (the shared folder says it hasn’t changed for a month before publication).
On the plus side - one potentially positive innovation in this version is that it includes a Development Agreement template - which conceptually is not a bad thing. That can make contracts uniform, reduce the scope for complexity and reduce legal cost for whomever is in charge of that. It also helpfully has outline numbering included to aid discussion: so some good potential here:
Unfortunately - the Developer Agreement presented needs a lot more work - it seems extremely unsuitable for TDF - apparently based on some verbose and burdensome template. TDF should be aiming at something excellent - as simple and easy to understand as possible here to attract maximum interest so. Some example issues of things we should improve:
3.3 “Audit And Inspection … [of] Developer facility … discuss a nondisclosure agreement…” seem amazing - although people are welcome to visit our office.
Section 7 - Confidentiality clause language seems unhelpfully cumbersome for a transparent organization - a mutual agreement not to exchange confidential / personal information would be shorter and better.
8.2 has overly-broad licenses to existing open source work that need constraining
11.4 “Developer shall compensate FhG for all damages that result directly or indirectly from the termination of the agreement” - it would be interesting to know who this third-party FhG is and why we should compensate them(!?) - is that a natural person, how does it relate to TDF ? …
14.1 Termination on disclosure of trade & industrial secrets ? (of TDF?) !?
1 Whereas - annoyingly this seems to requires someone to sign up to the contested, and non-original translation of TDF’s purpose with this “free of charge” gratuitously added. Hopefully that was inadvertent and that is easy to improve - no-one is unsure who the contracting entity is: it is TDF - and there is no need for this.
15 Support and Bug Fixing - stands out as an apparently poorly drafted and defined year-long free bug-fixing clause new undefined terms “software bugs” or “defects” - with other open-ended and ill defined requirements. The scope of that is potentially horrifyingly expensive, (who can decide bugs vs. features?). It is unclear that staff would be able to adequately estimate that long tail risk as they select an upper bound for the tender budget. It was clearly not in the original template. An un-funded “Support Period” should go - we already have an acceptance process including testing - anything not found during that process should be not required for a fixed-cost project at least - and we should encourage the shipping of well tested features.
More generally - this pair of documents is very long on penalty clauses for suppliers eg. 4. Timely performance - is present with %age payment penalties; then we have the Irrevocability of a Bid and No show penalty - 10% of the price offered etc. More Indemnities for every kind of problem to move risk onto suppliers. If timeliness is important for TDF - why does it itself take months and years to act ?
Committing to actual payment for work done is an extremely under-developed part of the document - there is no helpful Program Description template, we are missing helpful defined terms, framework and language for enabling that - no model for pre-payment, milestone payments, etc. Getting that right in each Tender itself without a helpful template is going to be very tricky. Interestingly it seems the emphasis here is very far from fixing the problem of ensuring anyone gets paid for work well done.
The cumulative impression can appear quite negative. TDF is currently refusing to pay (for some years) for work that it ordered, was delivered, accepts was completed, and is currently selling. It does that seemingly based on under-explained, sophistry not based on the contract. Now the advertised fix is a contract that is jammed full of unhelpful language, with innumerable new opportunities for bad faith participants not to honor their commitments, it seems to be built on an inappropriate contractual base, seems to be poorly proof-read: and even more amazingly - is take-it-or-leave-it and I quote:
“No negotiation OR modification can occur. TDF and winning Bidder may only correct evident errors, resolve internal inconsistencies of the Model Agreement and fill the actual Contract with the information deriving from the conditions of the Tender and what has been offered.”
So while there are some sensible elements here - the document is unusable in its current form.
I am also missing some constructive idea sketched here to help cope with the massive deficit of trust with the ecosystem caused by TDF’s failure to perform its obligations. For example escrow of funds to a competent, internationally certified third party, with said third party performing the acceptance tests - that way never again could this situation recur. Alternatively many 1st world governments provide export insurance to cover losses associated with dealing with entities in less reliable jurisdictions: so perhaps TDF could fund and bank-roll a third party instrument to guarantee its obligations - if it could find someone to accurately assess that risk. I would also be very interested in an explicit public statement and sign-off from whatever German regulated counsel approved these documents that this process is compliant with all known regulation and not subject to further unpleasant surprises. Ideas appreciated - what creative ways are there to re-create trust when basic contracts are not honored? I don’t see any of that here.
So anyhow - the good news is this: there is a lot of room for improvement before this is fit for purpose. Thankfully people recognize that - and there is hope for a quick iteration of a new version.
It would presumably be extremely helpful for people working on that to interact with those who routinely have to review and execute similar documents - and who might be inclined to tender if their concerns could be met - before pushing a scheme that is unlikely to work. Given that such people exist in the community - and are willing to help make this fit for purpose - it might be nice to include their constructive feedback. Indeed, I like Italo’s suggestion to turn this into a LibreOffice document to allow wider comment and effective editing. It will certainly be easy to build something better.
I hope that helps.
Hi Florian, hi all,
-1
I suggest to fix the most unacceptable mistakes, i.e. if
1.4 “Developer shall compensate FhG for all damages that result directly or indirectly from the termination of the agreement”
FhG means Fraunhofer-Gesellschaft, this version is not better, than the previous one.
Thanks for your review!
Best regards,
László
Ah - so this is meant to be TDF ? Reading again it seems the intention is to demand to compensate consequential (indirect) damages that’s a huge ask - many insurers explicitly exclude consequential damages from their cover.
Which make me look at clause 12 Insurance - also unacceptable; the requirement for Policies to name TDF are incredibly burdensome in administrative time, and this is normally struck from an agreement.
Almost all agreements we sign hard limit liability at the value paid in the agreement in question; that’s a normal part of such things.
There is/was some hope that the referred to but not presented / templated:
shall maintain insurance coverage throughout the entire term of the Agreement as described in the attached Exhibit B with insurance companies acceptable to The Document Foundation. The limits set forth in Exhibit B are …
might limit liabilities - but apparently the text says the opposite - and of course Exhibit B is not present in the document.
Punch line - this looks like a pre-negotiation template contract - which is fine; ask for the sky. It doesn’t look like something that can be agreed to by a responsible person - at least not without some huge risk premium which is not in TDF’s interest.
If TDF wants people to contract for it - it should set out to treat them fairly; a take-it-or-leave-it approach is possible I guess - but not with this extreme position - lets hope it gets fixed.
P.S. The list of mistakes discovered by the public review which seems to be unacceptable also for the initial version, but they seem easy to fix:
– Missing deadline for the next version (2025-12-31?);
– Missing deadline for publishing the details of Ranking by the Community evaluation, which not covered by the previous deadline (“Details for this ranking will be published in a separate procedure or a next update of this Technical Budgeting Procedure.”);
– Bad or non-explained terms or actors: “compensate FhG for all damages” without definition of “FhG”;
– Missing parts: “attached Exhibit B” is not attached;
– Redefinition of “affiliate” with a different meaning in the same policy;
Fixing these e.g. next week, I can support the initial version to test the viability of the improved policy as soon as possible.
Otherwise I strongly agree with the other opinions: it’s worth to spend a few weeks to consider and avoid the risk that a development agreement imposing unachievable requirements on small and individual developers, or every previous successful bidder, will deprive the ESC, our oldest and most professional body to help to remove the biggest barriers to future development, also it will deprive our whole community to achieve anything by the upcoming Ranking by the Community process. (By the way, I’ve checked Linux version of WPS Office a few weeks ago, and yes, it has got a wonderful SmartArt replacement, WPSArt – otherwise it’s not a real competitor of LibreOffice yet, because of lack of language support – Hunspell is used only for en_US and en_CH spell checking, there is no hyphenation [like in Google Docs and online version of Office 365] etc.)
Best regards,
László
The Board of Directors at the time of voting consists of 7 seat holders (not including deputies). In order to be quorate, the vote needs to have 1/2 or more of the Board of Directors members, which gives 4.
A total of 6 Board of Directors members have participated in the vote.
The vote is quorate.
A quorum could be reached with a simple majority of 4 votes.
Result of vote:
6 approvals: Paolo, Italo, Eliane, Osvaldo, Sophie, Simon; deputy Mike supports the motion as well
0 abstain
0 disapprovals (Laszlo’s disapproval was sent shortly after the voting period ended.)
Decision: The proposal has been accepted.
Should there be some minor glitches in the document, I am sure the board will address them in an updated version soon.
I think it’s important to have the principles on the policy agreed and shared in public. A previous board voted for tenders worth a huge amount of money at a pace that we would have had one tender approximately every one and a half weeks. This is not a rate that TDF can sensibly handle, especially in light of the discussions during the hiring of inhouse developers and areas they should keep out of.
The ESC budgeting process failed for various reasons last year. Therefore it’s important to have proper processes and roles in place ahead of the budget to not repeat these mistakes. TDF must be in a position to verify deliverables on all it tenders, and people in the various roles must be prepared.
I second Italo’s thoughts. There is a reason why we need a sound and solid procurement policy in place, and it obviously lies in what happened during past board terms.
The discussion around the word “affiliate” is quite interesting - if the changes are rather trivial, why insist so much on having them?
Hi Florian,
Can you check that you sent a mail on 2024-11-11 15:38, containing “The vote runs 72h from now.”, please? This was the only notification about the vote, what I noticed, and I had no reason to doubt that the voting started earlier than the e-mail claimed, and then I voted within 72 hours.
Thanks,
László
Hi Laszlo,
I checked the facts within mails from the board-discuss list/forum. The mail from Florian got the time stamp Nov., 11, 15.38. Your vote mail got the time stamp Nov., 14, 15.47.
i’m not a mathematician by education but from my job-related knowledge it is obvious that the deadline ended on Nov., 14 at 15.38.
Thus your vote didn’t meet the deadline.
Regards,
Andreas
Although Laszlo email was late, it contains a few remarks which are worth considering. The same applies to other messages in the thread. Apart from the “affiliate” definition, which I do not think could be changed without incurring in legal issues, there are indeed some glitches in the text that should be corrected as soon as possible with a version 1.1.
Hi Andreas, hi all,
Thanks for checking! I was noticed by the e-mail, but I voted on the web page at Nov. 14. 3:37 PM, before the deadline. You can check the time stamp by clicking on the small gray time on the right top corner of my vote here:
Best regards,
László
Discourse does not send the e-mails in realtime, but in regular intervals, from what I remember.
If you look at the time of the posting (indeed, the small gray time on the right top corner of the message), I see:
- my vote posting: “11. Nov. um 15:28”
- your -1 reply: “14. Nov. um 15:37”
So that -1 arrived a few minutes after the voting deadline.
This is the stuff of conspiracy theory, it has been patiently explained here before.
IANAL but the name of any well defined term is not legally relevant in this context - so it should indeed be a trivial change. Also the defined term here is far from the normal meaning of Affiliation (as we now see from the far more normal Fraunhofer definition).
Why insist on an odd name & avoid a trivial change? Political reasons? Perhaps some - apparently eager to exclude even more ecosystem participants from TDF’s governance - might like to have a new, very expansive definition of Affiliate in the statutes.
Again - I think Italo’s approach of separating concerns to make progress & build consensus is a good one. Perhaps you share the view that pushing more of the ecosystem away is a good thing - but please don’t tangle that up, alongside other unnecessary & controversial statements on the foundation’s purpose by fighting simple helpful changes of these documents.
Hi Florian, hi all,
It seems for me, this is a technical problem, which was unforeseen for the previous board, when it’s decided to allow Discourse for board-discuss and voting. Discourse’s latency was the only reason, why my vote has been ignored the first time, but the validity of my vote is not affected, because the official e-mail (containing [VOTE] in its header) was about 15:38 starting time, see [VOTE] Approve procurement policy and development agreement, revoke previous technical budgeting procedure - #24 by nemeth
The previous board, including me didn’t know about any latency (it can be 10 minutes or more now?), and if I right remember, for a while, it was not possible to vote in e-mail, and if the time had been more visible in Discourse (it was only “3d”) I would have noticed, but I would have had to rely on the original e-mail notification, and voting based on that in Discourse.
The board decision was fortunately not affected by this mistake now, but in the future we should rule out any such technical problems, without creating uncertainty for voters. We can limit Discourse latency, considering also e-mail notifications about the starting time, allowing to vote in e-mail again, too (where all timestamps visible in the e-mail header and received by everyone).
Thanks,
László
I don’t know what the previous board had envisioned when the migration of the board-discuss mailing list to a Discourse forum has been decided.
What I know is that in the aftermath, during the previous board’s term, one elected board member’s postings to this forum has been edited by another board member and a posting has been hidden.
These actions confirm that, in any case, the board decided for a forum, not for a mailing list, because on a mailing list you cannot retroactively edit postings or remove an e-mail. A forum is technically different from a mailing list.
As you see from my screenshots, by a simple click on the message, the day and time is visible in our forum. This even works when you are not logged in, I just verified that.
The e-mail cannot be determining, as the vote started on a forum, not on a mailing list.