Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Hi Thorsten, On 12/01/2022 15:34, Thorsten Behrens wrote: Hi Paolo, Paolo Vecchi wrote: On 12/01/2022 12:44, Thorsten Behrens wrote: That seems unlikely to repeat itself? You think no other commercial organisations are or will be hosting any LibreOffice related projects with TDF or you think that the board in future will surely spot that a project hosted at TDF with contributions mostly from one organisation could create issues without having some rules set? The latter. As board members change there is a risk that some may not think to look at the issue, as it happened in the past, so I do think we have to set this rule/reminder. I haven't yet evaluated where to write this rule but it should be clearly stated somewhere and be valid for all current and future projects, meaning that we have to have a clear view of what we are hosting at all times. I've discovered only the other day that the Android Viewer is still maintained and that caught both me and Emiliano by surprise as we didn't have an up to date status of it. Your proposed text for the policy _does_ constitute a default, up-front requirement. Perhaps it needs rewording then, to better carry your intended meaning? I'm not sure if there is a language barrier here and/or I haven't yet expressed the concept clearly enough. The point is that the letter of your proposal does not match what you say. For a final policy, it doesn't matter what people state in an email discussion; what counts is what's in the policy text. So please update that text, for this conversation to remain effective. I stand by the text I wrote and that apparently you didn't find contradicting what I previously stated: "> That should be added in the "## De-atticization requirements. The form could > be along the line of: > > - If the parties involved in the development of the project are commercial > entities an agreement must be signed to make clear the final scope, the > benefits to the community and the eventual limitations in publishing it > following TDF's objectives. > Thanks for the crisp write-up! That's indeed something I can work and interact with." Maybe we can improve the text but to me it still means that people/individual contributors don't have any particular burden but clearly commercial entities must sign an agreement and that has been my point from the beginning and during the whole thread. As stated a few times it should be a welcome improvement also for corporate contributors as at least they have clear guidelines to plan long term while we know we invest in a project that will leave a value for the community to benefit from. Best, -- Thorsten 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 OpenPGP_signature Description: OpenPGP digital signature
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Hi Paolo, Paolo Vecchi wrote: > On 12/01/2022 12:44, Thorsten Behrens wrote: > > That seems unlikely to repeat itself? > > You think no other commercial organisations are or will be hosting any > LibreOffice related projects with TDF or you think that the board in future > will surely spot that a project hosted at TDF with contributions mostly from > one organisation could create issues without having some rules set? > The latter. > > Your proposed text for the policy _does_ constitute a default, > > up-front requirement. Perhaps it needs rewording then, to better carry > > your intended meaning? > > I'm not sure if there is a language barrier here and/or I haven't yet > expressed the concept clearly enough. > The point is that the letter of your proposal does not match what you say. For a final policy, it doesn't matter what people state in an email discussion; what counts is what's in the policy text. So please update that text, for this conversation to remain effective. Best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Hi all, On 12/01/2022 12:44, Thorsten Behrens wrote: Hi Paolo, Paolo Vecchi wrote: 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. That seems unlikely to repeat itself? You think no other commercial organisations are or will be hosting any LibreOffice related projects with TDF or you think that the board in future will surely spot that a project hosted at TDF with contributions mostly from one organisation could create issues without having some rules set? 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." Great. So why do you want it in the policy then? As you point out, most projects start as individual initiatives. Your proposed text for the policy _does_ constitute a default, up-front requirement. Perhaps it needs rewording then, to better carry your intended meaning? I'm not sure if there is a language barrier here and/or I haven't yet expressed the concept clearly enough. I wrote: "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." So it does not constitute a default for people but, as I wrote, it does when "the project is being proposed by or it becomes controlled mostly by a single company." Then I gave you 2 examples that should clarify the concept further. I do want it in the policy because, as an example, LOOL is a complex project which may attract interest from individual developers but also from commercial organisations with which the rules should be made clear to avoid having another organisation getting supported by TDF and its community and then fork when convenient for them leaving nothing much to the foundation and the community that helped in making the project successful. Best, -- Thorsten I hope these further explanations and a re-read of the thread help in clearing your doubts. 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 OpenPGP_signature Description: OpenPGP digital signature
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Hi Paolo, Paolo Vecchi wrote: > 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. > That seems unlikely to repeat itself? > > 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." > Great. So why do you want it in the policy then? As you point out, most projects start as individual initiatives. Your proposed text for the policy _does_ constitute a default, up-front requirement. Perhaps it needs rewording then, to better carry your intended meaning? Best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
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 i
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Hi *, Paolo Vecchi wrote: > That should be added in the "## De-atticization requirements. The form could > be along the line of: > > - If the parties involved in the development of the project are commercial > entities an agreement must be signed to make clear the final scope, the > benefits to the community and the eventual limitations in publishing it > following TDF's objectives. > It is notoriously hard to separate commercial from non-commercial activities. I believe putting up more barriers to entry for people wanting to contribute to TDF projects is not smart. But lets hear others' opinion on that on Friday. > "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. 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. Let's discuss on Friday, all the best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
I wrote: > So I'd like to call for a vote soon, unless there's concrete input for > edits. Let's give this two more days. > There were two concrete proposals to amend the policy, that we'll discuss during the board call on Friday. Thus, holding the vote for the moment. All the best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
About the severity to overrule the ESC we are on the same side, a board should think twice or even more if doing so. But without clarification these two sentences set the expectations that an ESC have a blocking decision which is in fact wrong as you say by your own. And in such a case to lean on exchanging the ESC afterwards is a questionable move then, isn‘t it? So lets discuss on Friday as it is already on the board meeting agenda. Perhaps with a little clarification as I proposed we could improve this text of the procedure. Thanks Lothar Von meinem iPhone gesendet > Am 10.01.2022 um 16:16 schrieb Michael Meeks : > > >> On 09/01/2022 17:27, Lothar K. Becker wrote: >> Both sentences imply that the ESC have in praxis a blocking veto, >> independent of the decision by a board, for both procedures. > >In general, I think it is wise when (re-)starting an engineering project > to get input from the engineering community who are represented in the ESC. > >Of course, the board is not obliged to do so, and it also appoints the ESC > itself. If necessary it can stack it with yes-people. > >However, I would really suggest that making engineering decisions against > the advice of the leaders of the teams that do the work is something that > should give very serious pause for thought & consideration by a board. > >> Or something like this. I am not sure if it is good to vote on it without >> clarification of this item in any case. What do you think? > >Clearly the board as the ultimately authority has many avenues to ensure > its will is done: changing the policy, changing the ESC composition, etc. > >But as a general scheme of action for a peaceful and sensible approach to > the problem, I think the policy as proposed is fine. > >Regards, > >Michael. > > -- > michael.me...@collabora.com <><, GM Collabora Productivity > Hangout: mejme...@gmail.com, Skype: mmeeks > (M) +44 7795 666 147 - timezone usually UK / Europe > > -- > To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org > Problems? > https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ > Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette > List archive: https://listarchives.documentfoundation.org/www/board-discuss/ > Privacy Policy: https://www.documentfoundation.org/privacy >
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Hi Thorsten, On 10/01/2022 16:48, Thorsten Behrens wrote: Again, for this to be constructive, could you please suggest concrete changes to the proposed policy? I did propose a concrete change which sparked this conversation. Here it is in case you missed it: https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00029.html "1) Creating clear agreements with the projects we support/promote so that, even if a team/company writes the majority of the code, we will have clear indications of the benefits we can together bring to the community and the relevant expectations from both sides." That should be added in the "## De-atticization requirements. The form could be along the line of: - If the parties involved in the development of the project are commercial entities an agreement must be signed to make clear the final scope, the benefits to the community and the eventual limitations in publishing it following TDF's objectives. Then, as explained in the same email: "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. The rationale should have been extensively explained in the thread. 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 OpenPGP_signature Description: OpenPGP digital signature
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Hi Paolo, Paolo Vecchi wrote: > > Can I see the adjustments/changes to the proposal then please? > > The proposal, as stated in my previous emails, is related to the eventual > "de-atticisation" of the project. > Again, for this to be constructive, could you please suggest concrete changes to the proposed policy? > The proposal was meant to ask if your project would benefit from being > supported by TDF and in which ways. > Thanks. That is good to know. > Having articles stating "The LibreOffice team has been working on a > port to browser-hosted WebAssembly"(1) or the page you created on > TDF's wiki describing the WASM project(2) without specifying who > leads it and what could be the eventual distribution limitations, > may suggest to some that the project is hosted and developed by/for > TDF, that's the reading some may have of the "LibreOffice > team/developers/other variants", and that will be bound to TDF's > objective to make it "available for use by anyone free of charge". > Let's please finally decouple this discussion, Paolo. I'll refrain from answering in this thread, that repeatedly conflates many things. On the above: are you asking me to remove public documentation on how to build the WASM port, and what it is? A private answer is fine, and then we can continue this discussion (if there's anything left to clarify) else-thread. This really has nothing to do with the atticisation proposal. Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
On 09/01/2022 17:27, Lothar K. Becker wrote: Both sentences imply that the ESC have in praxis a blocking veto, independent of the decision by a board, for both procedures. In general, I think it is wise when (re-)starting an engineering project to get input from the engineering community who are represented in the ESC. Of course, the board is not obliged to do so, and it also appoints the ESC itself. If necessary it can stack it with yes-people. However, I would really suggest that making engineering decisions against the advice of the leaders of the teams that do the work is something that should give very serious pause for thought & consideration by a board. Or something like this. I am not sure if it is good to vote on it without clarification of this item in any case. What do you think? Clearly the board as the ultimately authority has many avenues to ensure its will is done: changing the policy, changing the ESC composition, etc. But as a general scheme of action for a peaceful and sensible approach to the problem, I think the policy as proposed is fine. Regards, Michael. -- michael.me...@collabora.com <><, GM Collabora Productivity Hangout: mejme...@gmail.com, Skype: mmeeks (M) +44 7795 666 147 - timezone usually UK / Europe -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.documentfoundation.org/www/board-discuss/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Hi Thorsten, see below. On 10/01/2022 12:46, Thorsten Behrens wrote: Hi Paolo, let's stay focused - Paolo Vecchi wrote: Do you have concrete suggestions on changing the actual proposal? Well, yes. That's what the rest of the email you replied to was about. Can I see the adjustments/changes to the proposal then please? The proposal, as stated in my previous emails, is related to the eventual "de-atticisation" of the project. 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. That then seems entirely unrelated to a putative attic process? It is if we want to move a project like LOOL, of in future other projects, from the "attic" into a TDF hosted and promoted project as we should have in place checks that avoid the repeat of the LOOL issue. The original proposal with "three different developers ...ideally not all of them affiliated to the same entity" does not fully exclude that the proposal could come from an organisation, which in principle would be fine for me, but in this situation the proposed agreement should be in place before welcoming the project back. Another example could be LOWA (LibreOffice WebAssembly), which is a promising project developed mostly by Allotropia AFAIK. That's why months ago I've asked you to lead by example by officially present the project to TDF in a couple of pages stating the objectives and what TDF could expect to deliver to the community while Allotropia pursues, rightly, its commercial interests. If you followed up we would have had already a document on which to base the agreement we need to welcome other projects. Let's discuss that else-thread please. Again, new projects are a different area entirely. And as one of the people funding LOWA, I find it irritating that my contributions are met with demands, instead of gratitude. I'm not really sure why you feel irritated. Of course your company's contributions are more than welcome and, as written quite a few times, TDF should facilitate and, if seen as beneficial by the corporate contributor, help in supporting and promoting the project. The proposal was meant to ask if your project would benefit from being supported by TDF and in which ways. It is important to set the right expectations for the community to avoid the repeat of the issues we had with LOOL once LOWA is production and market ready. That's why I believe that the proposal for both the "de-atticisation" process and new projects are linked to the same need to have an agreement in place if the main player is a company. As both a company director and a member of TDF's board I'm sure you have a clear understanding of the need from one side to protect your investments and on the other side to do what is best for TDF and the LibreOffice community. Having articles stating "The LibreOffice team has been working on a port to browser-hosted WebAssembly"(1) or the page you created on TDF's wiki describing the WASM project(2) without specifying who leads it and what could be the eventual distribution limitations, may suggest to some that the project is hosted and developed by/for TDF, that's the reading some may have of the "LibreOffice team/developers/other variants", and that will be bound to TDF's objective to make it "available for use by anyone free of charge". If TDF's objectives are not fully compatible with your company's plan for the LibreOffice based project that is leading, then it would great to work on the proposed document that will be eventually used for LOOL's "de-atticisation" process if the interested party is a company and by your own company to set clear expectations for the community and to protect your investments. I've not yet asked TDF anything in return. Once again I express my sincere gratitude for the contributions you personally and your company provided to the LibreOffice project and community. There are other companies that develop LibreOffice based products which never asked for anything in return, which in some cases may have chosen to use their own brands and host projects in their own infrastructures and I don't see a issue with that even if it would be nice to work all together under clear rules. Please do evaluate the above if you think TDF could contribute in making your LibreOffice based project suitable for use under TDF's objectives and a great success for your company. Cheers, -- Thorsten Ciao Paolo 1) https://www.theregister.com/2021/02/16/libreoffice_team_working_on_port/ 2) https://wiki.documentfoundation.org/Development/WASM NOTE: the link leading to build instructions on TDF's wiki page comes up with a "Secure Connection Failed" -- 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 Rec
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Hi Paolo, let's stay focused - Paolo Vecchi wrote: > > Do you have concrete suggestions on changing the actual > > proposal? > > Well, yes. That's what the rest of the email you replied to was about. > Can I see the adjustments/changes to the proposal then please? > 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. > That then seems entirely unrelated to a putative attic process? > Another example could be LOWA (LibreOffice WebAssembly), which is a > promising project developed mostly by Allotropia AFAIK. > > That's why months ago I've asked you to lead by example by officially > present the project to TDF in a couple of pages stating the objectives and > what TDF could expect to deliver to the community while Allotropia pursues, > rightly, its commercial interests. If you followed up we would have had > already a document on which to base the agreement we need to welcome other > projects. > Let's discuss that else-thread please. Again, new projects are a different area entirely. And as one of the people funding LOWA, I find it irritating that my contributions are met with demands, instead of gratitude. I've not yet asked TDF anything in return. Meanwhile, I'd be most happy if people interested in LOWA would come & join our FOSDEM talk about it: https://fosdem.org/2022/schedule/event/lowa/ Cheers, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
+1 on Lothar's proposal. Paolo On 09/01/2022 18:27, Lothar K. Becker wrote: Hi Thorsten, Emiliano, all, thanks for the reminder Thorsten, as the discussion goes on in different areas of using this status of attic, my feedback is more on the procedural aspect of it. It says, Quote: " ... **snip** ## Atticization process That proposal will have to be voted on successfully by both the ESC and the Board of Directors. **snipp** ... **snipp** ## De-atticization procedure If the vote turns out affirmative, the implementation part will be handed over to Infra team, which can, based on common sense: **snipp** ... " End of Quote Both sentences imply that the ESC have in praxis a blocking veto, independent of the decision by a board, for both procedures. First of all let me ask, if this was intended and is a correct understanding or if I understood it wrong? So, in case I understood it right, then - in reflecting our Statutes and RoP and its construction of the foundation, that the "last" ruling body is the board in an appropriate case of conflict and if needed in supervision of the meritocratic organisation* - I would propose to add for a better understanding: "The last and ruling decision for the Atticization or De-atticization of a project in TDF is certainly by the board. If it is in contradiction to a preliminary vote of the ESC, it should be at least heard by the board for its arguments and it should be reflected from the board with an answer why the decision of the board is not following the ESC vote. " Or something like this. I am not sure if it is good to vote on it without clarification of this item in any case. What do you think? Best Lothar * beside some very seldom things where the MC or at last the membership comes into the game, but here we are upon normal activities inside the foundation Am 08.01.2022 um 17:50 schrieb Thorsten Behrens: Dear board, dear TDF members, all, this proposal has sparked interesting discussions, that we should continue. For the proposal at hand though, we've not received much if any actionable feedback. So I'd like to call for a vote soon, unless there's concrete input for edits. Let's give this two more days. All the best, Thorsten I wrote: Dear board, dear TDF members, all, as mentioned a few times during board calls, Emiliano and me have been drafting a proposal what to do with no-longer-active projects at TDF. Here's the draft we're both happy with: -%<-- ## Introduction It can happen, with a huge project like LibreOffice, that parts of the project worked on by the community will become obsolete or superseded by other projects. The following proposal will cope with the need to let the code (and/or other form of text related to the code) to be publicly available, while setting the correct expectations around its availability, suitability for a production environment, quality and security. ## What is the “attic”? The “attic” is a special area of TDF infrastructure where part of the code/documentation/translations can be parked, that is not anymore actively developed. This will help setting the correct expectations on its status of development, while not losing its fundamental trait of being open source (so its code must be publicly available). In the present proposal, the “attic” would be a single host inside TDF infrastructure, available in HTTP/HTTPS protocols, responding to a URI similar to: https://attic.documentfoundation.org ## Specificity of the “attic” This “attic” space will have, at minimum, the following characteristics: • It is supported by git – the well known CVS developed by Linus Torvalds initally and used to share the sources of the Linux kernel. Being supported by git will ease the forking of the code contained there; • Any repositories inside it will be made “read only”, so no “push” or “pull request” mechanisms will be available: this allows changes to the code to be shared as it was the last time it was “atticisized”; • Anonymous access to the repositories has to be made the default access method: we want the code present in the “attic” to be always available to everyone; • It should have a recognizable URL – or internet address, less technically: this allows for the code present to be clearly separated by other actively developed code; • A specific text explaining the nature of the code, its “de-atticization” requirements and how to get support on the code inside the repository to be present in the README of every repository. The text of these disclaimer, the de-atticization requirements will be discussed further on in the proposal. Regarding contacts to get support, the idea is to provide quick and ready information on who/where to ask for anything related to the code in the repository. The proposed implementation of this space is by using git-http-backend1. The proposal has already bee
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Hi Thorsten, On 09/01/2022 17:45, Thorsten Behrens wrote: Hi Paolo, Paolo Vecchi wrote: I would wait for an eventual vote until a few weeks after FOSDEM just in case more questions and/or interest about the future of LOOL come up. The attic proposal is only incidentally related to LibreOffice Online. The attic proposal, isn't only incidental, you and Emiliano volunteered to put together such proposal to deal with LibreOffice OnLine issue. The fact that it may then be used for other projects in future is an added bonus. Do you have concrete suggestions on changing the actual proposal? Well, yes. That's what the rest of the email you replied to was about. 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. I very strongly suggest to *not* make that mandatory for every kind of project we'd be interested in adopting. It would otherwise completely kill the onboarding of that kind of small-but-useful tools we've taken up in the years past (cppunit, libcmis, odf toolkit etc). This is not about components but entire projects like LOOL which have been, or will be, hosted and promoted by TDF. 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. Eg. I wouldn't have asked the person that presented a prototype of LOOL in 2011 to sign the agreement but I would have started proposing it when in 2013 that same person incorporated the company that became LOOL's main contributor. Another example could be LOWA (LibreOffice WebAssembly), which is a promising project developed mostly by Allotropia AFAIK. That's why months ago I've asked you to lead by example by officially present the project to TDF in a couple of pages stating the objectives and what TDF could expect to deliver to the community while Allotropia pursues, rightly, its commercial interests. If you followed up we would have had already a document on which to base the agreement we need to welcome other projects. It is great that companies invest in complex projects based on LibreOffice but, if those projects are to be hosted, promoted or even economically sponsored by TDF, we have to set the right expectations for the community and have a mutually beneficial agreement in place. Failing to do so will lead exactly to the same outcome we have seen with LOOL. No volunteer in her right mind would sign binding, legal agreements of that kind. You may have missed a bit of the email where I say: "The agreement should not be an extremely long and complex legal document, which in some cases could be very difficult to enforce, but at least should also clarify the expectations from both parties and make it clear to the contributors what TDF's objectives are so that there will be no surprises for anyone." Once again, as clarified above, this would apply only to companies or when the project previously run by volunteers becomes controlled by a legal entity. Instead, it can be left to the discretion of the board to ask for more formal commitments, if it sees a need. If a rule is in place it will be easier for the board to spot when they have to act. As a generic rule of thumb we could set a threshold of 50% (?) of the contributions to the project by a single company at which point the board should start negotiations with the company. That would also help TDF understanding if the contributor is really interested in delivering the project following TDF's objectives or it's just interested in benefiting from TDF's infrastructure and LibreOffice's brand. Best, -- Thorsten 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 OpenPGP_signature Description: OpenPGP digital signature
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Hi Thorsten, Emiliano, all, thanks for the reminder Thorsten, as the discussion goes on in different areas of using this status of attic, my feedback is more on the procedural aspect of it. It says, Quote: " ... **snip** ## Atticization process That proposal will have to be voted on successfully by both the ESC and the Board of Directors. **snipp** ... **snipp** ## De-atticization procedure If the vote turns out affirmative, the implementation part will be handed over to Infra team, which can, based on common sense: **snipp** ... " End of Quote Both sentences imply that the ESC have in praxis a blocking veto, independent of the decision by a board, for both procedures. First of all let me ask, if this was intended and is a correct understanding or if I understood it wrong? So, in case I understood it right, then - in reflecting our Statutes and RoP and its construction of the foundation, that the "last" ruling body is the board in an appropriate case of conflict and if needed in supervision of the meritocratic organisation* - I would propose to add for a better understanding: "The last and ruling decision for the Atticization or De-atticization of a project in TDF is certainly by the board. If it is in contradiction to a preliminary vote of the ESC, it should be at least heard by the board for its arguments and it should be reflected from the board with an answer why the decision of the board is not following the ESC vote. " Or something like this. I am not sure if it is good to vote on it without clarification of this item in any case. What do you think? Best Lothar * beside some very seldom things where the MC or at last the membership comes into the game, but here we are upon normal activities inside the foundation Am 08.01.2022 um 17:50 schrieb Thorsten Behrens: Dear board, dear TDF members, all, this proposal has sparked interesting discussions, that we should continue. For the proposal at hand though, we've not received much if any actionable feedback. So I'd like to call for a vote soon, unless there's concrete input for edits. Let's give this two more days. All the best, Thorsten I wrote: Dear board, dear TDF members, all, as mentioned a few times during board calls, Emiliano and me have been drafting a proposal what to do with no-longer-active projects at TDF. Here's the draft we're both happy with: -%<-- ## Introduction It can happen, with a huge project like LibreOffice, that parts of the project worked on by the community will become obsolete or superseded by other projects. The following proposal will cope with the need to let the code (and/or other form of text related to the code) to be publicly available, while setting the correct expectations around its availability, suitability for a production environment, quality and security. ## What is the “attic”? The “attic” is a special area of TDF infrastructure where part of the code/documentation/translations can be parked, that is not anymore actively developed. This will help setting the correct expectations on its status of development, while not losing its fundamental trait of being open source (so its code must be publicly available). In the present proposal, the “attic” would be a single host inside TDF infrastructure, available in HTTP/HTTPS protocols, responding to a URI similar to: https://attic.documentfoundation.org ## Specificity of the “attic” This “attic” space will have, at minimum, the following characteristics: • It is supported by git – the well known CVS developed by Linus Torvalds initally and used to share the sources of the Linux kernel. Being supported by git will ease the forking of the code contained there; • Any repositories inside it will be made “read only”, so no “push” or “pull request” mechanisms will be available: this allows changes to the code to be shared as it was the last time it was “atticisized”; • Anonymous access to the repositories has to be made the default access method: we want the code present in the “attic” to be always available to everyone; • It should have a recognizable URL – or internet address, less technically: this allows for the code present to be clearly separated by other actively developed code; • A specific text explaining the nature of the code, its “de-atticization” requirements and how to get support on the code inside the repository to be present in the README of every repository. The text of these disclaimer, the de-atticization requirements will be discussed further on in the proposal. Regarding contacts to get support, the idea is to provide quick and ready information on who/where to ask for anything relate
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Hi Paolo, Paolo Vecchi wrote: > I would wait for an eventual vote until a few weeks after FOSDEM just in > case more questions and/or interest about the future of LOOL come up. > The attic proposal is only incidentally related to LibreOffice Online. Do you have concrete suggestions on changing the actual proposal? > 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. > I very strongly suggest to *not* make that mandatory for every kind of project we'd be interested in adopting. It would otherwise completely kill the onboarding of that kind of small-but-useful tools we've taken up in the years past (cppunit, libcmis, odf toolkit etc). No volunteer in her right mind would sign binding, legal agreements of that kind. Instead, it can be left to the discretion of the board to ask for more formal commitments, if it sees a need. Best, -- Thorsten signature.asc Description: PGP signature
Re: [board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Hi all, I would wait for an eventual vote until a few weeks after FOSDEM just in case more questions and/or interest about the future of LOOL come up. That would also allow time to evaluate how an eventual "de-atticisation" or support for any additional project should be managed to avoid a repeat of this type of forks. Any project benefiting from TDF's infra and brand should be bound, at least, to a backporting agreement during a minimum period of time (1 year?) especially if it becomes clear that a single team/organisation is mostly contributing. That would show that the organisation cares about the LibreOffice community and gives enough time to evaluate if TDF should further invest in the project in terms of developers, marketing, etc. 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. The agreement should not be an extremely long and complex legal document, which in some cases could be very difficult to enforce, but at least should also clarify the expectations from both parties and make it clear to the contributors what TDF's objectives are so that there will be no surprises for anyone. Once that is in place I would agree to vote for the proposal. Ciao Paolo On 08/01/2022 17:50, Thorsten Behrens wrote: Dear board, dear TDF members, all, this proposal has sparked interesting discussions, that we should continue. For the proposal at hand though, we've not received much if any actionable feedback. So I'd like to call for a vote soon, unless there's concrete input for edits. Let's give this two more days. All the best, Thorsten I wrote: Dear board, dear TDF members, all, as mentioned a few times during board calls, Emiliano and me have been drafting a proposal what to do with no-longer-active projects at TDF. Here's the draft we're both happy with: -%<-- ## Introduction It can happen, with a huge project like LibreOffice, that parts of the project worked on by the community will become obsolete or superseded by other projects. The following proposal will cope with the need to let the code (and/or other form of text related to the code) to be publicly available, while setting the correct expectations around its availability, suitability for a production environment, quality and security. ## What is the “attic”? The “attic” is a special area of TDF infrastructure where part of the code/documentation/translations can be parked, that is not anymore actively developed. This will help setting the correct expectations on its status of development, while not losing its fundamental trait of being open source (so its code must be publicly available). In the present proposal, the “attic” would be a single host inside TDF infrastructure, available in HTTP/HTTPS protocols, responding to a URI similar to: https://attic.documentfoundation.org ## Specificity of the “attic” This “attic” space will have, at minimum, the following characteristics: • It is supported by git – the well known CVS developed by Linus Torvalds initally and used to share the sources of the Linux kernel. Being supported by git will ease the forking of the code contained there; • Any repositories inside it will be made “read only”, so no “push” or “pull request” mechanisms will be available: this allows changes to the code to be shared as it was the last time it was “atticisized”; • Anonymous access to the repositories has to be made the default access method: we want the code present in the “attic” to be always available to everyone; • It should have a recognizable URL – or internet address, less technically: this allows for the code present to be clearly separated by other actively developed code; • A specific text explaining the nature of the code, its “de-atticization” requirements and how to get support on the code inside the repository to be present in the README of every repository. The text of these disclaimer, the de-atticization requirements will be discussed further on in the proposal. Regarding contacts to get support, the idea is to provide quick and ready information on who/where to ask for anything related to the code in the repository. The proposed implementation of this space is by using git-http-backend1. The proposal has already been evaluated by the Infra team and the overhead for maintaining such a solution will be “negligible”. ## Atticization process The Engineering Steering Committee (ESC) of TDF, the Board of Directors (BoD) or one or more of its Directors can propose the “atticization” of a part of the project. That proposal will have to be voted on successfully by both the ESC and the Board of Directors. The specific code proposed (mostly, entire git-based repositories) will be then effectively attic
[board-discuss] Last call for feedback on the proposal (was: Draft text: an "attic" proposal)
Dear board, dear TDF members, all, this proposal has sparked interesting discussions, that we should continue. For the proposal at hand though, we've not received much if any actionable feedback. So I'd like to call for a vote soon, unless there's concrete input for edits. Let's give this two more days. All the best, Thorsten I wrote: > Dear board, dear TDF members, all, > > as mentioned a few times during board calls, Emiliano and me have been > drafting a proposal what to do with no-longer-active projects at TDF. > > Here's the draft we're both happy with: > > -%<-- > > ## Introduction > > It can happen, with a huge project like LibreOffice, that parts > of the project worked on by the community will become obsolete or > superseded by other projects. The following proposal will cope > with the need to let the code (and/or other form of text related > to the code) to be publicly available, while setting the correct > expectations around its availability, suitability for a > production environment, quality and security. > > ## What is the “attic”? > > The “attic” is a special area of TDF infrastructure where part of > the code/documentation/translations can be parked, that is not > anymore actively developed. This will help setting the correct > expectations on its status of development, while not losing its > fundamental trait of being open source (so its code must be > publicly available). > > In the present proposal, the “attic” would be a single host > inside TDF infrastructure, available in HTTP/HTTPS protocols, > responding to a URI similar to: > https://attic.documentfoundation.org > > ## Specificity of the “attic” > > This “attic” space will have, at minimum, the following characteristics: > > • It is supported by git – the well known CVS developed by Linus > Torvalds initally and used to share the sources of the Linux > kernel. Being supported by git will ease the forking of the code > contained there; > > • Any repositories inside it will be made “read only”, so no “push” or > “pull request” mechanisms will be available: this allows changes to > the code to be shared as it was the last time it was “atticisized”; > > • Anonymous access to the repositories has to be made the default > access method: we want the code present in the “attic” to be always > available to everyone; > > • It should have a recognizable URL – or internet address, less > technically: this allows for the code present to be clearly > separated by other actively developed code; > > • A specific text explaining the nature of the code, its > “de-atticization” requirements and how to get support on the code > inside the repository to be present in the README of every > repository. The text of these disclaimer, the de-atticization > requirements will be discussed further on in the proposal. Regarding > contacts to get support, the idea is to provide quick and ready > information on who/where to ask for anything related to the code in > the repository. > > The proposed implementation of this space is by using > git-http-backend1. The proposal has already been evaluated by the > Infra team and the overhead for maintaining such a solution will be > “negligible”. > > ## Atticization process > > The Engineering Steering Committee (ESC) of TDF, the Board of > Directors (BoD) or one or more of its Directors can propose the > “atticization” of a part of the project. That proposal will have to be > voted on successfully by both the ESC and the Board of Directors. > > The specific code proposed (mostly, entire git-based repositories) > will be then effectively atticized by the Infra team. Other than > moving the repository to the attic, these other changes will be > needed: > > • Deactivation of specific -dev or -users mailing list; > > • No new binary releases will be provided (older releases will persist > in download archive); > > • Changing eventual specific category on BugZilla to “Atticized repo – > please do not use” (ed.: needs to be checked by Infra/QA/Ilmari); > > • Possibly disable Ask/Discourse pertaining categories (ed.: needs to > be checked by Infra/Sophie). > > ## De-atticization > > A part of the project that is actually present inside the “attic” can > be moved back into active development, whenever sufficient interest > around the code emerges. > > ## De-atticization requirements > > A repository can be de-atticized when it reaches the following requirements: > > • A publicly available repository has to be present, collecting new > modifications to the initial project. This repository needs to be > based on the initial atticized repository; > > • The modified code has to be open source/free software under an > OSI-approved license; > > • At least three different developers have committed changes to the > forked repository, ideally not all of them affiliated to the same > entity;
