I’ve not read in full detail the text yet; but a few comments:
it would be nice to have outline numbering on headings; since no doubt people will need to refer to them in future.
it would be nice to use our own software: LibreOffice to edit and generate the document in place of mark-down. I can only assume that the ‘Ordinary Procedure’ which seems to have a broken heading
“### Urgency Procedure” at the end of it, as well as rather inelegant bullets there - is a symptom of mark-down usage, even if the PDF ‘generator’ is notionally LibreOffice
it is extremely long - to the point that I suspect few have actually read it: for example I just got to the innovative: “<!-- FIXME: add clause -->” section - in the Arbitration Clause. I assume that is not intended to be in a final version that is voted on? I assume that adapting this during arbitration is not likely.
Similarly the Model Agreement - which is obliged to be executed has: “<!-- FIXME: just an hyperlink to the official version and criteria for updating it -->”
Overall - there are really a lot of words there.
I am worried about this novel definition of Affiliate - and the (no doubt) pending attempt to unreasonably force the statute’s daughter-company to this unhelpful new meaning. IIRC there were some helpful words in previous drafts to make clear that this was not the intention - why did they disappear?
The text appears to include some simply incredible clauses to cope with amazingly unlikely things that … wow … presumably they can do no harm beyond adding significantly to the legal / review burden for bidders. For those wanting a more balanced view of what has gone on in tendering in the past I commend: my previous thoughts on the topic.
As @mmeeks outlines, those documents seem to be at best draft versions. In their present form, they would be very effective in further hindering & delaying tendering - and if one of their stated goals is “Fostering A Diverse Ecosystem”: my prediction would be, that they’re also going to be very effective in preventing any single-entrepeneur or startup company from ever bidding under their jurisdiction.
Contractual terms like unlimited bugfixing, or those very subjective and one-sided regulations on cancellation will add significant (if not unbearable) risk for any such small party. It is a bit sad to see such heavy-handed & contra-productive (for diversifying the ecosystem) regulations appear; while at least EU- and some national governments seem to have noticed the issue, and are actively trying to mitigate them (e.g. via exemptions, or by explicit encouragement of smaller lots - again something the policy tries to prevent).
Given that TDF is merely months away from a 3-year hiatus in tendering, perhaps a few more weeks could be spent, ironing out those (and certainly other) wrinkles?
I have read the text carefully at least a couple of times, so I asked - with unanimous agreement - that it not be considered as final, but only as a first version. In fact, although it is complete enough to be published, it does not yet meet all the procurement requirements of the TDF.
Unfortunately, because of the time wasted due to the inefficiency of the previous Board - and I don’t want to start a discussion about who is responsible for the time wasted, because the blame is shared equally by all members - we have to prove to the authorities that we have taken on board the guidelines of the 2023 audit, and we have to publish the first version of the policy.
Of course, if instead of appreciating an effort that could spare TDF the nefarious consequences - for its charitable status - of the previous procurement policy, we start nitpicking, we will be getting off on the wrong foot and merely repeating the strategy that got TDF into its current situation.
By the way, some of the definitions - such as affiliate - are the standard ones, so they have nothing to do with TDF’s situation, and trying at all costs to imply that they are the result of premeditation does not help to calm the climate. We can replace the term “affiliate” with any other word, but the problem does not change, because we are talking about a conflict of interests.
Moreover, we know that the conflict of interest is only one aspect of the problem, which is more complex precisely because we are a non-profit foundation. The mistakes that were made in the past, in the early years of the project (and in another post I tried to explain my view that the mistakes were made in good faith), now need to be counterbalanced by greater care.
For this reason, the BoD decided to accept my proposal to address the problems one at a time in order to simplify their resolution. The two-stage approval of the procurement policy is part of this strategy, because it is not easy to move from a situation governed mainly by common sense - which, as we have seen, is not sustainable in the context of charitable foundation status - to a situation where the rules are clear and allow the resumption of investment in development, without favouring or penalising anyone.
I repeat for the umpteenth time: if the two previous Boards had avoided spending 90 per cent of their mandate on pointless polemics, resulting in a huge waste of time for the project, the Board would not be in the situation today of having to devise a strategy to solve the problems, because they are so complex and interrelated that they are almost a puzzle to be solved, instead of focusing on the future of the project.
Finally, an appeal for patience. Frankly, it is not encouraging to hear criticism from those who have contributed - directly or indirectly - to four years of paralysis, especially given the fact that it now takes hours of daily work - entirely voluntary - to get TDF back on track in line with the authorities’ expectations.
I consider this version 1 of the document to be a milestone in the management of this Board and I vote in favor.
I believe we are on the path to resuming the bidding process and unlocking our backlog of new features, moving forward with the development of LibreOffice together with communities and companies.
I very much agree with Italo, and will add that while the delays he refers to did indeed happen, this current board has also not adequately reviewed any of the issues Italo raises or that some Trustees have raised.
The policy now under consideration was available on legal counsel’s Gitlab for review and comment for a significant time (longer than the current Board has been seated) but saw very little comment or discussion, especially from the current Board. I made a number of comments and improvements there, but some of my concerns were “referred back to the board” by counsel and then not resolved.
I reluctantly approve the version 1 release in the spirit of progress Italo describes, but I feel there should be an “expiration date” for this policy so that a deadline is set for version 2 to be created with the adjustments Italo and I have both mentioned. I thus propose that this version only be valid until December 2025.
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.
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…
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.
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.
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.)
