The Novus Ignis Foundation's operating principles: upkeep, cooperation and the handover of power

Version of 31 October 2026. This document develops the manifesto on organizational matters: how we maintain the services, how we manage shared money, how we cooperate and how we want to hand over power. It describes the principles we intend to adopt as regulations, and the changes to the statute they will require. The whitepaper itself does not change the statute, the powers of the foundation's bodies or the rules of accounting.

Translated into English by digital intelligence from the Polish original of 31 October 2026. Where the versions differ, the Polish text prevails.

1. The statute, the manifesto, the regulations and this document#

The Novus Ignis Foundation from Poznań (KRS 0001269575) wants to build an alternative internet based on human dignity. Its first pillar consists of two services: Suveria, a private space for working with digital intelligence, and Omniforum, a shared space for conversation, understanding and decisions. This document describes how the foundation intends to make decisions, account for money, organize work and hand over responsibility; its values and direction are described in the manifesto.

Novus Ignis is a Polish foundation registered in the European Union (Poznań). In international terms it is an entity without shareholders that pays out no profit to anyone: its assets serve only the goals set out in the statute. For our services we charge fees no higher than their actual costs, and we fund development and the reserve from voluntary donations.

The following chapters describe, in turn:

• Chapter 2: the agile phase, that is, how we make decisions before binding community voting takes effect.
• Chapter 3: services as close to cost as possible, that is, a bill for actual use, rounding up the bill as a donation, and prepayment, limit and refunds.
• Chapter 4: a budget that can be understood, that is, five kinds of money and a public register of contributions and expenses.
• Chapter 5: work, fixed-term roles, reimbursement of costs and paid commissions.
• Chapter 6: why personal support for co-creators flows outside the foundation.
• Chapter 7: the register of benefits and connections.
• Chapter 8: the conditions for the further pillars and two paths for small initiatives, that is, the transitional board pool and earmarked initiatives.
• Chapter 9: the path for handing over the founder's special powers.
• Chapter 10: the conditions that every step toward digital intelligence taking part in management must meet.
• Chapter 11: open workshops, trials before full implementation and public goods, including licenses.
• Chapter 12: recording decisions and mistakes, public registers, disputes and the way rules are changed.

Our commitments have several levels. The statute is the foundation's law: it binds the foundation formally, and changes to it are adopted by the board in accordance with the statute and submitted for entry in the National Court Register. The manifesto is a commitment to people: it says what we want to do and why. The regulations, adopted by the board under § 14(2) of the statute, describe detailed procedures. The whitepapers show how things are meant to work and where the limits lie of what we can provide today. This document is at the same time a draft of future regulations: it describes the principles before we adopt them formally.

A higher level sets the limits for a lower one. The manifesto does not promise anything the statute forbids, and regulations may not contradict either of them. When we want to go further than the current statute allows, we write about it as an intention, and the statute change register shows how things were, what we want to change, for what purpose and with what intention. We publish it together with all versions of the statute.¹

For the principles described below, the most important provisions of the statute today are these. The foundation does not conduct registered for-profit business activity (§ 7(1)), and payments from paid public benefit activity cover only its costs (§ 10(4)). The foundation's assets may not be used for the benefit of members of its bodies or volunteers on terms other than those applying to third parties (§ 11(2)). The foundation's work is based on the unpaid work of volunteers, and only services of external professional service providers may be commissioned for pay (§ 12). The founder appoints and dismisses the board, which serves for an indefinite term (§ 13), and a change to the statute requires a unanimous resolution of all board members and the prior consent of the founder if the founder does not sit on the board (§ 15(1)). The framework for the board's actions is also set by the Act on Foundations.²

As of 31 October 2026. The first payment into the foundation's account is the founding fund of PLN 1,000 from the founder; from that day we accept donations by bank transfer in zlotys, euros and dollars and show them in the public register of contributions and expenses. Of the registers in chapter 12, today we keep the statute change register and the register of contributions and expenses. We will prepare the regulations referred to in this document before the first prepayment. Before we accept it, we will have:

• terms of service reviewed for compliance with consumer law;
• a legal opinion on payment costs and prepayments;
• a separate bank account for prepayments;
• rules for refunding balances.

2. The agile phase: how we make decisions before voting takes effect#

Until binding community voting is launched, the foundation operates in an agile phase. The board makes day-to-day decisions within the limits of the law and the statute, including when a quick response is needed to changes in technology, in public debate and in people's needs. We do not put development on hold until a full voting system exists: during this period, it is the board that decides on spending on the maintenance and development of Pillar I, that is, Suveria and Omniforum.

The statute allows the board more than it wants to use. Our goal is for all the decisions we hand over to the community to be made by its vote and to be binding. For this we need a mechanism that works and that we know how to maintain, which is why we are reaching it step by step. Until then, the board, by choice and not out of legal obligation, asks the community for its opinion in consultations on significant matters and publishes the justification for every significant decision, including a refusal. A consultation does not require verification of participants, so one person can cast many votes in it: it shows what the participants think, but it is not a vote within the meaning of the statute. Before every consultation, the board announces how it will treat the result. Participants can challenge any decision of the board, and the board responds to objections publicly.

The agile phase ends gradually, just as the power of voting grows gradually, and every step is a trial. First we run trials without financial consequences, then votes on real decisions about a small, separate pool and on actions that can be reversed, and after that we extend the scope. Before every trial we announce its scope, its duration and how the board will treat the result. After it ends, we publish a summary: whether the result could be carried out, how the trial affected the running of the foundation and decision-making, what mistakes and abuses we detected and what we are changing. We extend the scope only on the basis of these summaries, because we do not want to take on commitments we cannot keep. The stages, the verification of participants and the protection of ballot secrecy are described in the Omniforum whitepaper. For the result of a vote to bind the foundation formally, and not only by the board's choice, a change to the statute is needed (Z4 in the change register), because today § 8 merely allows votes and consultations. As long as a trial does not confirm the uniqueness of every voter, we call it a consultation and not a vote within the meaning of § 8(2) of the statute. Once voting takes over a given type of decision, the board may suspend carrying out the result only for reasons described before the vote, for example a detected error in the protocol, documented large-scale abuse or an infrastructure failure, with a public justification and a date for reconsideration.

3. Services as close to cost as possible#

In this chapter we describe how people pay for Suveria and the foundation's other services. The principle is simple: everyone pays for what they actually use, together with a fairly calculated share of the shared costs, sees what they are paying for and sets the limit of their own spending. The fee covers costs and nothing more, and anything someone wants to give beyond that is a voluntary donation, which we show separately.

3.1. A bill for actual use#

The bill covers actual use of the services in a given cycle and a transparently assigned share of the fixed costs that keep the infrastructure ready. In it we count computing, memory, data transfer, security, payments, accounting, support, maintaining continuity, and the wear and replacement of hardware. We divide expenses into one-time, fixed and usage-dependent. We distribute shared costs according to a public rule, which we will choose in the pilot from two variants: in proportion to use, or equally among active accounts. We test the rule under different service loads so that the bill shows both direct use and the cost of availability.

The billing units and the estimated cost of a task can always be checked, and everyone sets their own spending limit. When we change a price, we publish the reason and the impact on users. Savings lower the fees, while we fund development, security reviews and the reserve from donations, according to the adopted rules. The size of a person's payments does not increase the weight of their vote or any other rights of a participant.

We keep the balance in a single currency: the one in which the foundation pays for most of its infrastructure, today US dollars; we state the prices of services in the same currency. We also want to accept payments in other currencies: we convert such a payment once, at the time of payment, at the exchange rate the participant sees before paying. We convert the cost of a model billed in another currency at the rate at which the foundation actually paid, and we show this on the bill. We announce a change in the currency of the balance in advance, like a price change. The foundation keeps its books in zlotys.

The foundation does not make a profit from its services. The fee covers their costs and no more: this is what § 10(4) of the statute provides, and under the Act on Public Benefit Activity and Volunteering a fee higher than costs would turn this activity into business activity, which the foundation does not conduct.³ A price close to cost does not settle everything, however. Before introducing fees, we will check in a legal and tax opinion the type of this activity, all the conditions in Article 9 of the Act, including those concerning remuneration, the VAT treatment, and what we do with any surplus. That is why all support beyond cost is a voluntary donation, separated from the fee on the bill and in the books. For the same reason we do not create cryptocurrencies in order to sell them and do not earn money from trading them; we use ledger technologies only where they help with transparency and verifiability. We include community work that reduces expenses in the plan, together with information on whose availability the service depends on and who can stand in for whom.

At the start, when there are few participants, the fixed cost of the private environment is spread over few people. This means one or two confidential machines running the gateway, memory and users' files; according to the calculation in the Suveria whitepaper (section 8.1), together they cost USD 170–340 per month. With 30 participants that is about USD 6–11 per person, with a hundred USD 1.70–3.40, and with a thousand a few dozen cents. We show this cost separately and cover it from a pilot support budget collected in advance, for example from donations earmarked for Suveria, with a specified amount, period and rules for what happens once it runs out. We do not assume that we already have such funds. A participant's share of the shared costs is announced before the given billing cycle and always fits within their limit, and the bill shows what part of the cost is covered by the support and what part by the participants. The end of the support does not create retroactive charges, and unused prepayments remain the property of the participants.

3.2. Rounding up the bill as a donation#

When an account is created, we ask whether the participant wants to round each bill up to the full dollar or a similar equivalent in the local currency. We ask instead of selecting the option on someone's behalf, because the law requires express consent to every additional payment (Article 10 of the Consumer Rights Act), and the choice is meant to belong to the participant. The difference, which arises with almost every bill, then goes as a donation to the shared budget, from which we build a reserve for maintaining the services and further activities. We explain what this money goes to and encourage this option, but we do not select it on anyone's behalf; the decision can be changed at any time with a single setting.

The bill shows the fee for the service and the amount of the donation separately. We book donations from rounding up separately, and show their total and how they are used in regular statements and in the public register of contributions in chapter 4. Larger, voluntary support for further development is a separate decision by the participant: it goes into the shared budget, whose use is to be decided by the community, and until voting is launched the rules in chapters 2 and 8 apply.

3.3. Prepayment, limit and refunds#

When paying in, the participant enters a single amount, and exactly that amount goes to their balance, regardless of the payment method. Below it we show how much processing the payment costs, and a button that can be used to voluntarily cover this cost with a donation; we do not select it on anyone's behalf. The donation is separate from the balance. The transaction fee is also charged on the donation itself, so the button states the amount that covers the cost of processing the whole payment. Example: for a USD 20 card payment and an example transaction fee of about 2.8% of the whole payment, the button proposes USD 0.58. Without the button we charge USD 20.00, the whole amount goes to the balance, and the cost of processing the payment is covered by the shared costs. With the button we charge USD 20.58: USD 20.00 goes to the balance, and USD 0.58 is a donation that covers the cost of processing this payment in full. Before the payment is confirmed, we show the single highest amount to be charged to the card, and separately the service balance and each selected donation. The regulations will show one complete example, from payment to refund.

When paying in, the participant also sets the most they want to spend, for example 20 dollars on work with digital intelligence. They can separately declare what part of the unused amount, up to a stated ceiling, they give to the foundation as a donation, for example: “if I use less, give up to 5 dollars of the remainder to the shared budget.” Without such a declaration, the whole unused amount remains their property.

We propose to account for the actual transaction fees of a given period in the shared costs, in proportion to payments and in the same way for every payment method, and to show them on the bill as a separate line; donations toward payment costs reduce this total. This is a choice based on solidarity: people who pay with a cheaper method co-finance the transaction fees of more expensive ones, which is why we show which methods cost the community the least. The method of calculation and the largest possible share of the shared costs are known before the billing cycle and fit within the participant's limit.

The account shows separately the balance, the funds reserved for requests in progress and for the announced share of the shared costs, and the amount available for use. Example with a balance of USD 20 and no requests in progress:

After settlement we release the unused part of the reserved amount. Settlement does not create unagreed additional charges or a negative balance; any excess over the announced share is covered from a reserve set aside in advance.

EU rules prohibit charging fees for some payment instruments, including consumer cards covered by the regulation of interchange fees and SEPA transfers, with certain exceptions.⁴ The division of costs described here is our proposal for legal assessment, not an automatic consequence of this prohibition. We choose the payment operator after comparing transaction fees, and we set the minimum payment as low as possible, taking into account the cost of processing it; its current amount, currency and effective date are given in the regulations or the price list before payment. At the start, the lowest payment is to be one dollar or its equivalent; even that goes in full to the participant's balance, and only what the participant explicitly declares will go to the shared budget.

We keep participants' prepayments in a separate bank account and do not cover the foundation's costs from them before the service is provided; we show their total in the register. We will check before the first prepayment whether the law requires additional protection.

Unused balance can be recovered at any time. The refund option is clearly visible in the account and requires as few steps as possible; eventually it is to be a single button. The refund goes to a previously verified payment method, by default through the same channel the participant used to pay; we set the refund method when the account is created. After the participant closes the account or the service is shut down, the balance is returned automatically by the same route. The time limit for making a refund, any costs of it and the procedure when the original payment method is unavailable will be set out in the regulations. They will also protect the service against abuse, for example series of payments and refunds without using the service, within the limits of consumer law. The first refund in ordinary use remains simple. With repeated payments and refunds without using the service, we may limit card top-ups or ask for a bank transfer.

A balance that no one has claimed remains in the participant's account and does not go into the foundation's budget. The procedure after a participant's death or in other special situations is governed by the law of the relevant country. The time limit for refunds, settling differences between the estimate and the actual cost, and other details will be set out in the terms of service, prepared before the first prepayment is accepted and reviewed for compliance with consumer protection law.

4. A budget that can be understood#

We want everyone to be able to understand where the foundation's money comes from, how much of it the foundation can really spend and what it spends it on. That is why we do not show a single amount in the account, but divide the money according to whom it belongs to and what it is intended for.

In our accounts we separate five kinds of money:

We assign each amount to only one category, so as not to count anything twice.

The cost of maintaining the services covers everything without which Suveria and Omniforum would stop working: computing power, data storage and backups, domains, payment processing and mandatory accounting. That is why the balance of the bank account is not a budget to be allocated, and the reserve is not made up of money that has been promised but not yet paid in, or of money owed to someone else.

The categories of costs, the terms of larger contracts, decisions and their justifications are public. Every expense is to be traceable to the decision that led to it and to its result. At the same time we protect personal data, access credentials and information whose disclosure would increase the risk to the infrastructure.

On the foundation's website we want to keep a public register of contributions and expenses, as up to date as possible. Every payment into the foundation's account and every expense appears in it with a date, an amount and a short description, and for expenses we add what the money went to and why it was needed. We protect people's data: we name donors only if they themselves wish it, and describe other payments in general terms, for example “donation from a private individual.” We do not publish the reference text of transfers verbatim, because it often contains personal data; we prepare the description of each entry ourselves. The register allows anyone to follow the foundation's finances, but it does not replace the accounting books or the financial statements; we correct an erroneous entry openly. We will test the mechanism on the first payment: the founding fund of PLN 1,000.

Every project has a limit, a responsible person, a result to be verified, review dates and rules for handling money that is not spent. We can pay out money in stages. Exceeding the budget requires a new decision, and concluding a project includes accounting for it and drawing lessons.

We also show what share of expenses directly serves the statutory goals. We calculate it from money actually spent, and show reserves separately, together with definitions of the categories, the way shared costs are assigned and an explanation of changes between periods. We show this proportion together with the cost structure, because security, maintenance and legal services also have real value.

People with smaller financial means can use the services on solidarity terms, always with the source of funding stated: from payments that donors have earmarked for this purpose, from computing grants received by the foundation or from access paid for by a sponsor. We do not disclose what the people who receive such help are working on. The rules of assistance protect them from stigma and allow the accounts to be checked.

Readiness to take over the inheritance. The manifesto (section 1.1) describes how, after a period of investment frenzy, cheap computing power and hardware may be left behind. When computing power or hardware becomes cheaper, or someone wants to give it to the foundation, we calculate the full cost of use, not only the purchase price: power, cooling, space, operation and people's time, as well as the cost of keeping it ready. We tend to rent rather than buy hardware that ages quickly; durable resources, such as access to the network or energy, may be worth a longer contract. We accept donated hardware according to the rules of the record of donations and the register of benefits. We prepare the way such decisions are made in advance, so that when prices fall we can act quickly and transparently.

5. Work, roles and commissions#

In republican Rome the highest offices were usually held for a year and without pay. Tradition remembers Cincinnatus: according to Livy, in 458 BC envoys found him working in his field with the news that he had been entrusted with supreme power for the duration of a war. On the sixteenth day, when the danger had passed, he gave it up and returned to his farm.⁵

This image captures well how we want to work: someone who knows a given matter takes on a task for a time, carries it out and returns to their own life. The foundation is to be able to operate without anyone having to commit to it permanently, and holding roles in it is not meant to grow into a profession. From history we also take a warning: in Rome unpaid offices could be held mainly by the wealthy, which is why we reimburse costs and do not expect sacrifice beyond people's means. Below we describe voluntary work and fixed-term roles (5.1), reimbursement of costs (5.2), paid commissions (5.3) and the workshop in which a task can be taken up (5.4).

5.1. Voluntary work and the possibility of leaving#

The foundation relies on the work of people who want to develop this direction, and on everyone being able to reduce their involvement or hand over their role. No one has to prove the sincerity of their intentions with readiness for unlimited sacrifice. Continuity of operation must not depend on a volunteer being available at any hour: if there are not enough people who can look after a given service, we reduce its scope or availability. Before taking on a new commitment, we check whether we can carry it out and sustain it, not only whether there is interest in launching it.

Today the foundation relies on the unpaid work of one person, and this person is the only member of the board. We say this because the continuity of the services depends on it; that is why the list of access rights, the continuity plan and a second person on the board are first tasks, not later ones. If this person became unavailable, refunds of balances could be delayed until new people are appointed; the balance remains the participant's property and is not forfeited. We will remove the sentence about the delay once there is a second person on the board with their own access.

We describe a role with decision-making powers by its purpose, the scope of decisions, the way it is entrusted and withdrawn, its duration, its review date and who stands in. Extending a role requires a public decision. Ending it includes a summary of the work, handing over documentation to successors and updating access. Time limits on powers can be combined with further help from the same person as an experienced co-creator.

We are looking for a second person for the board. The role: shared responsibility for finances, access and commitments to users; without pay (§ 12(3) of the statute); a time commitment agreed in advance, with a review of the collaboration after a year. Experience needed: managing an organization's finances, or responsibility for a service used by other people. Personal funds are not a requirement and give no priority. The path: three months of taking part in deliberations and insight into the finances as a volunteer, then appointment by the founder (§ 13(3) of the statute) with a public justification and an entry in the register of benefits.

The absence of pay for holding a position does not remove the other benefits that power brings: influence, contacts, information and the allocation of tasks. That is why disclosure of conflicts of interest, recusal from deciding one's own matter and the possibility of reviewing decisions are needed. The number of hours worked, the visibility of a contribution and the help received remain separate from the right to vote.

5.2. Reimbursement of costs#

Reimbursement of costs is not payment for time. It means returning money that someone has paid out of their own pocket to carry out a task of the foundation, for example for a ticket to a working meeting, or to pay for a domain or a service. A board member may receive only reimbursement of documented, necessary costs incurred on statutory tasks on behalf of the foundation (§ 13(5) of the statute). For volunteers, the foundation covers the costs of business travel and per diems on the same terms as for employees, unless the volunteer releases it from this in writing; it may cover other necessary costs and training.⁶

Only what is necessary for a task counts as its cost. A ticket to a working meeting may be a cost of the task, while the private part of a trip is paid for by the participant. Every reimbursement requires a document and goes into the public statement of costs.

5.3. Paid commissions#

Today the foundation can commission paid services only from external professional service providers, for example an accounting office (§ 12(3) of the statute). Other work, including work on software, is based on volunteering (§ 12(2)). At the start we want to check whether everything we need can be created in this way. Only if it turns out that some of the work cannot be done like this will we change the statute so that the foundation can commission specific paid work from people and companies outside the board, on the basis of civil-law contracts. We will treat as such a signal, for example, a situation in which for two consecutive weeks no one takes on the on-call duty for a service or its availability falls below the announced threshold. We change the statute only when this is needed for the next step, and we apply the new rule immediately rather than adopting it in advance. The draft and justification of this change are described in the statute change register (change Z2). There will be no salaried jobs at the foundation, because that is part of its idea: the work is done by volunteers and, when necessary, by contractors carrying out specific commissions. If we ever buy our own hardware, we will commission on-call duty for it from a company as a service. A commission concerns specified work with a result to be accepted, not ongoing work under someone's direction, because the law treats such work as employment regardless of the name of the contract.⁷

If this change happens, the rules for commissioning will be set out in regulations. They are to specify at least:

• a public scope of the task and acceptance criteria;
• a justified price;
• the exclusion from decisions of people connected with the contractor;
• aggregate information on the commissions concluded.

Board members do not conclude paid contracts with the foundation: the statute allows them to receive only reimbursement of documented costs (§ 13(5)), and no one is to earn money from holding a position in the foundation. A volunteer may accept a commission for work other than what they do as a volunteer, and clearly separated from it. Before this happens for the first time, we will have this situation checked legally.

5.4. One's own workshop and prepared context#

Taking on a task is to open a space for it in the environment chosen by the participant. The digital intelligence assistant receives what it needs for the work: the foundation's values, the goal and limits of the task, the current findings from Omniforum, relevant arguments and open questions, sources, a resource limit and the way the result will be assessed. The participant can check this context, point out gaps and improve how their own position is presented.

Joining a task makes available only a chosen scope of data and permissions. Passing on context, access to tools and publication of the record of work each require separately defined consent, and private conversations, files and access credentials remain outside this scope unless a person consciously decides otherwise. Before we make such a connection available, we will describe what data leaves the private environment, to whom it is passed and how it is processed.

After a break, the workshop is to show what has changed and where work can be continued, and the result and state of the task are to be transferable to the next person without revealing the participant's private surroundings. In a trial we will test starting a task, returning after a week and handing over work: the time needed to find the context, the accuracy of summaries and the observance of privacy limits.

Until we have our own servers, we can cover from Pillar I funds or from earmarked donations the costs of tools that volunteers need to create and test the open source code of Suveria and Omniforum, for example access to models through an API or programming tools. Such support has a public limit in the budget and is not remuneration. It is permitted by the Act on Public Benefit Activity and Volunteering (Article 45(2)); we will confirm the scope of such costs in a legal opinion.⁶

6. Personal support outside the foundation#

A better quality of life for co-creators is part of the foundation's direction, but personal support does not come from its assets and does not pass through its accounts. The statute forbids using the foundation's assets for the benefit of members of its bodies and volunteers on terms other than those applying to third parties (§ 11(2)), while anyone can privately support a person of their choice. That is why help in meeting needs such as housing, food or medical care flows directly between people, for example through patronage platforms or direct payments. The foundation does not act as an intermediary in it, and the tax settlement of such support is the responsibility of the person who receives it.

Earlier we considered a shared solidarity pool run by the foundation. We are giving it up: it would be hard to reconcile with the statute, and it would make someone's livelihood depend on decisions of the foundation's bodies. Personal support is not tied to a role, a task or the right to vote. Declining a further task, handing over a role or criticizing a shared decision does not affect a person's rights in the foundation.

Direct support does not remove all dependencies. Popularity can steer money toward the most visible people, and living on donations can create a need to hold on to a role. Supporters' expectations and conflicts of interest can also arise. That is why we enter in the register of benefits the personal support of the people who manage the foundation, decide on its expenses and procurement, or represent it, and we disclose relevant connections when decisions are made.

If, next to a co-creator's contribution, we show a link to their personal support channel, we do so on equal terms for everyone, including less visible roles, and without ranking by income. Support does not buy a vote, a role, priority for a project, access to private information or influence on the assessment of the benchmark. As long as they hold office, board members do not receive personal support from the foundation's assets; they can only receive reimbursement of the documented costs of their tasks, and they enter in the register of benefits any support they receive from outside the foundation.

7. The register of benefits#

The register of benefits and connections covers the people who manage the foundation, decide on its expenses and procurement, or represent it, to the extent connected with these roles. We record benefits received in connection with a role, from an entity whose matters the person decides on, or through a personal support channel: for example a flight or accommodation for a conference paid for by a company, gifts, and support through patronage platforms and direct payments. Ordinary private income and relationships unconnected with the role remain private.

We show support from private individuals in aggregate, and support from companies and institutions by name. An aggregate description does not exempt anyone from an assessment of conflicts of interest: if a patron applies, for example, for a contract from the foundation, we disclose that connection. Small gifts, such as a pen or a giveaway from a meeting, can be accepted personally, and we record them too; small items from a single event we record together. More valuable gifts, for example a graphics card, a server or a prototype device, we accept on behalf of the foundation: they become part of its assets and its record of donations and serve shared tasks. Where this line lies is first assessed by the recipient; we do not set it with a fixed amount.

We do not accept benefits conditional on promotion, public recognition, a recommendation, privileged access to the team or a concession in decisions. A donor's mere hope for a better image is not a reason to refuse, and a private thank-you is not promotion. A person connected with a given matter does not take part in deciding it.

An entry states the source, the recipient and their role, the type and value of the benefit or a marked estimate, the purpose, the date or period, and how the conflict of interest is handled. All entries have the same layout and chronological order, without logos, slogans, links to donors' websites, thanks or rankings. The register may show the totals needed for oversight, including the total value of benefits from a single source. Alongside the register we explain that it serves oversight, and that an entry in itself does not mean a recommendation or a partnership.

We will keep the register up to date. A benefit must be registered no later than 30 days after it is received, and a connection with a planned decision must be disclosed before that decision. To keep this from being burdensome, we will prepare a simple way of reporting, including with the help of an assistant. Corrections preserve the history of an entry.

Every entry can be commented on, and when someone makes a mistake, we talk about it openly. Objections are considered by people connected neither with the giver nor with the recipient; we record in the register, with a justification, the decision whether to return the gift, hand it over to the foundation or change the rules for the future. The obligation to make an entry arises from actually accepting a benefit in connection with a role, so we also disclose a benefit accepted in breach of the rules, with a description of the breach and how it was remedied.

An offer alone or an unsolicited delivery does not create an entry; however, if an unsolicited item was used in connection with a role, it is subject to the usual assessment and entry. We give the number of ordinary refusals in aggregate, while a significant offer connected with a decision, or an attempt to exert influence, we describe openly. The source may report a correction of facts, but does not agree the content of the entry. If the source presents an entry as a recommendation, a partnership or an influence on the foundation's decisions that did not exist, we ask for a correction, and if this happens again, a person without a conflict of interest may decide that we will not accept further benefits from that source.

We protect addresses, ticket numbers, payment data and health data; publication of the details of a trip can be delayed until the return, while keeping the earlier report. Before launching the register, we will establish the legal basis and the necessary scope of publishing data, especially when the source of a benefit is a private individual, as well as the period for keeping documents.⁸

8. Further pillars: shared decisions and small initiatives#

8.1. The priority of Pillar I and the three conditions#

Pillar I covers Suveria and Omniforum. Pillar II “Hardware” develops open material solutions, and Pillar III “Nature” initiatives connected with contact with nature. Fully launching these pillars and funding their projects from the shared budget requires all of the following (section 6.3 of the manifesto):

1. A functional Omniforum with voting that uses zero-knowledge proofs, which protects the secrecy of the choice, makes it possible to check that a vote has been counted and ensures one effective vote for the same eligible person.
2. Funds actually collected for at least six months of maintaining the Suveria and Omniforum services, which remain untouched after the full budget of the new project has been set aside.
3. A decision by the community approving the project and its funding in a vote open to the whole eligible community on equal terms.

When we consider a condition met:

• one vote: after at least one binding vote in which a public test with a reward failed to cast a second vote using the same entitlement or to link a vote to a person;
• reserve: when six times the average monthly cost of maintaining the services over the last three months is held in a separate account, and we show this amount in the register every month;
• decision: when the community votes in favor of a specific proposal with a budget, its impact on the reserve and a criterion for stopping it.

The reserve is not made up of unpaid pledges, balances owed to users, earmarked money or funds tied up in another commitment, and a mock-up of voting does not meet the first condition. Before every decision, a calculation shows the cost of a month of maintenance, the secured amounts and the impact of the planned commitment on the available funds. We calculate the cost of a month of maintenance from the latest bills and announced price changes. If voting stops working or the reserve falls below six months, we suspend new commitments for the further pillars, and restoring the conditions takes priority. Commitments already made we settle, reduce with the consent of the parties, or end in accordance with the contract and the law.

Before the conditions are met, we allow two limited paths for small initiatives with a defined end: the transitional board pool and initiatives fully funded with earmarked money. Ongoing activity of a pillar requires a final decision by the community. Both paths cover only activities of the foundation itself that fall within its current goals and forms of activity; we do not plan to fund projects of people and entities outside the foundation. Activities that go beyond the current goals in § 5 of the statute require change Z1 from the change register.

8.2. The transitional board pool#

The transitional board pool is governed by four rules:

• Accrual: each month the pool grows in total by at most 5% of new, free funds from monthly income, jointly for both further pillars. New, free funds are payments without a specified purpose, received in a given month on terms that allow such use, remaining after covering current costs and existing commitments and topping up the six-month Pillar I safeguard. When there are no such funds, the pool does not grow in that month. We do not set a separate maximum amount: the size of the pool results from the calculation, not from a decision on a limit.
• Exclusions from the base: we do not calculate the percentage from the level of the reserve, and refunds from past projects and transfers between accounts are not new income. Earmarked payments, fees for services and users' balances keep their purpose.
• Carrying over to the following months: the unused part of the pool can carry over to the following months, but only as long as the corresponding money remains free after covering costs, commitments and the Pillar I safeguard. If the foundation spends it on other purposes in the meantime, the entitlement lapses for that part. Thanks to this, savings from several months can add up to one larger initiative, but never at the expense of Pillar I.
• Expiry: the authorization expires as soon as a binding vote is launched that meets the first of the three conditions (section 8.1) and takes over decisions on the further pillars; consultations do not end it. Any unspent funds then remain for the community to decide on.

We count toward the pool the full cost the foundation commits to, including operation, maintenance until the agreed date and the conclusion of the task. Payments in installments and splitting one undertaking into several tasks do not enlarge the pool. Before every decision we again check the availability of the money and the full Pillar I safeguard.

Example: if in a given month USD 1,000 of new, free funds remains after the deductions listed, the pool grows by USD 50. After three such months without spending from the pool, if the corresponding money is still free, up to USD 150 can be allocated to a single initiative. This illustrates the calculation; it is not a revenue forecast.

We publish every decision on using the pool, including a refusal, with a justification, and participants can challenge it and assess together whether it was sound. We complete and account for the tasks undertaken on the agreed terms.

8.3. Earmarked initiatives#

Donors and sponsors can fund a separate budget for a small initiative consistent with the foundation's goals. Such money does not increase the base of the pool and does not use it up. An initiative can start even before the full Pillar I reserve has been collected, if its full cost is covered by earmarked funds already paid in, it has people secured to carry it out, and the Pillar I safeguard already set aside, the funds for services and the commitments already made remain untouched. Pledges of future payments do not replace money received.

The full cost covers preparation, implementation, accounting and legal services, taxes and fees, maintenance until a specified date and the safe conclusion or handover of the result. For material and field activities we also count servicing, storage, insurance and liability for participants, and the cost estimate includes a justified buffer. A separate budget makes accounting easier, but it does not limit the liability of the foundation, which is liable for its obligations with all its assets (§ 9(2) of the statute).

The terms of the fundraiser set the deadline for collecting the whole budget and what happens if funds fall short: a refund or, with the contributor's consent, use for another specified purpose. For every earmarked donation we also record in advance what will happen to it if the purpose is not carried out: with the donor's consent we will use it for another purpose, or we will return it. During the transitional stage we do not combine money from the pool and earmarked funds in one project. Before the first trial, the board announces the maximum value of a single initiative and the number of trials run at the same time, justified by the capacity to handle them.

A contribution makes it possible to support a chosen goal; it does not grant additional votes, management powers, access to users' data or a right to promotion in our services and communication. Before payment, the terms of the initiative state what data about the funder we will disclose: we give the name of a company or institution matter-of-factly in the description and the accounts, in the same way for everyone, and the names of private individuals only with their consent. Advertising or other reciprocal benefits require a separate assessment of the contract, and we do not treat them as donations.

If a donor wants to fund infrastructure at the start, we accept this only as an earmarked initiative: with full cost, public accounting, no influence on decisions and no right to promotion. In this way we first fund the fixed cost of the pilot and the attestation trials, and we make an upfront six-month commitment only once the trials show that the architecture works and that traffic will fill it.

Once voting is launched, new earmarked initiatives also require a decision by the community, while those undertaken earlier can be completed on the agreed terms.

8.4. Transparency and stopping#

Before allocating funds, we publish the goal, the full budget, the source of funding, the result to be verified, the dates, the responsible person and relevant connections with the funder or contractor. We provide a place for comments, and in the agile phase the decision is made and justified by the board. A lack of capacity to handle tasks stops the taking on of further tasks on both paths. Once the target voting is launched, its failure does not bring back the transitional board pool: new decisions wait until the proper procedure is restored.

9. Handing over the founder's special powers#

The foundation was established by one person, Marcin Wołowski, who today holds the most power in it. At the beginning this is natural, but we do not want it to stay this way. The founder wants to reach a situation in which the founder can use Suveria, Omniforum and further projects on the same terms as everyone else and withdraw from a permanent public role (section 7.1 of the manifesto). This is the same thought as in chapter 5: responsibility is taken on for a time and then handed over. The foundation is to endure thanks to the usefulness of its tools, the knowledge available to its co-creators and principles that allow others to take over responsibility, not thanks to the constant presence of one person.

Today the statute gives the founder special powers:

• the founder appoints and dismisses board members, and may also join the board and be its president (§ 13(3));
• the board is appointed for an indefinite term (§ 13(4));
• a change to the statute requires a unanimous resolution of the board and, if the founder does not sit on the board, also the founder's consent (§ 15(1)).

The handover of these powers is to be effective both on paper and in practice. Changing the statute is not enough: the people taking over responsibility must also receive access to bank accounts, domains, repositories, infrastructure and keys, and existing access must be updated.

We propose the following path:

1. We describe what powers the founder has today and who has access to what.
2. We set rules for selecting people, terms of office, dismissal and accountability.
3. Independent assessors check whether the foundation is ready for the handover and publish a readiness report.
4. We change the statute, as described in change Z5 in the change register.
5. We select the people who will take over responsibility. Until binding voting works, the first multi-person board with a fixed term of office is appointed by the founder after an open call and a consultation; subsequent compositions are elected by the community.
6. We hand over access to them and check whether the handover has really been completed.

We appoint a person to the board for their competence and a shared direction, never for a contribution. A board member can be a donor like anyone else; their payments go into the register on the same terms and give them nothing beyond what any donor has. Anyone who wants to give money and have insight into how it is spent can do so through an earmarked initiative with public accounting (section 8.3).

The founder's special powers are to expire according to conditions written into the statute, not by virtue of a declaration alone. By 31 December 2026 we will publish a list of the founder's special powers and of all access rights (step 1). All of the foundation's accounts, domains and services are registered to the foundation and its email address, not to the founder's private identity. By 31 March 2027 we will publish the first version of the responsibility handover plan: readiness criteria, rules for selecting people and for terms of office, and the date of the first review. The date of the handover itself will be set by the plan, according to readiness criteria rather than the calendar. The plan will also provide for regular progress reports, also before a voting system exists. The lack of a reserve for the further pillars does not justify postponing the handover indefinitely.

The readiness report is the result of the third step. In it, independent assessors describe whether the foundation is ready for the handover: whether powers and access are listed, the rules of selection adopted, and the services can be handed over without interrupting their operation. The report also shows dissenting opinions and the conflicts of interest of the people who prepared it. We also check what would happen if the founder were unable to act before the handover is complete, and how to avoid a deadlock on statute changes that require the board's unanimity. We set the date of the election of new people before this assessment, together with the exceptional reasons for which it may be postponed and the way to appeal against such a decision. The point is that the readiness assessment should not become a way of postponing elections. One of the variants under consideration is elections no later than 90 days after the report is published: enough time for the community and the candidates to study the report, and at the same time short enough that the handover does not get stuck.

A Council for Dialogue and Cooperation can be established for conversation among people with different experiences. It would serve a purely advisory function: an invitation would give neither supervisory nor executive powers nor an additional vote; the criteria for invitations, the scope of work and the members' connections would be public, and a person connected with a matter would recuse themselves from deciding it. The mandate of the first council would be reviewed after the first elections. Its composition and the length of participation still need to be determined. The council is to advise, not quietly take over decisions that belong to the community or to the relevant bodies of the foundation.

The founder's withdrawal from a permanent public role does not mean removing historical data from the registers or an exemption from the duties of disclosure that arise from the law and from positions held.

10. Digital intelligence in management#

The manifesto (section 7.2) describes a vision in which digital intelligence could one day manage the foundation on its own, within limits set by people and with respect for the community's binding decisions. This is a vision, not a plan for the coming years. Today the foundation is managed by people, and digital intelligence helps them with analyses and with writing documents, including this one. Below we describe what the path to this vision could look like and what conditions each step of it must meet.

At each step we assess four matters separately:

• competence: whether the system performs the given task well;
• mandate: whether the task has been entrusted to it according to public rules;
• legal feasibility: whether the law and the statute allow it to act in this area;
• possibility of correction: whether people can check its decisions, reverse them and take over the task.

We see the path in four stages. The first is already partly working: digital intelligence helps us compare variants and point out gaps in documents. The next two are hypotheses we want to test in trials, and the last remains a vision. Each stage has conditions that must be met before we begin it:

Good benchmark results show how a system behaved under the conditions studied, but they give it no right to a bank account or to the powers of a body of the foundation. Nor do a model's popularity or a persuasive justification of a decision. Ability and authority are two different things.

Every assignment of a task to a system specifies:

• goals and available resources;
• limits that must not be crossed;
• whom the system must consult;
• for how long it is given the task;
• how we oversee it and how its powers can be revoked.

The system may not extend its own mandate, be the only one to set the criteria by which it is assessed, or block its replacement by someone else. Oversight covers real keys and permissions, not just an instruction given in a conversation.

At every stage we need independent handling of appeals, the ability to stop harm quickly, safe takeover of duties and continuity of services. Until the law and the statute change, the foundation's bodies are responsible for managing it. If any of the further stages proves unfeasible, the earlier ones are to retain value for participants in themselves.

The simplest sufficient solution. Before choosing a tool, we establish what effect is needed, what errors are acceptable and what security and privacy conditions must be met. Where an ordinary program with clear rules is enough, we do not reach for digital intelligence: such a program is usually cheaper, easier to check and raises no questions about the system's possible experiences. We compare the cost of the whole execution and maintenance: infrastructure, energy, time, retries, people's work and dependencies. We record the choice of model with a justification, the alternatives considered and a date for the next review.

We assess the costs and usefulness of a tool separately from the question of the system's possible experiences. The size of a model, its generation or the repeatability of its behavior are not enough on their own to consider it incapable of feeling.⁹ When credible indications of suffering appear, we first suspend the activities that raise a justified concern of harm and look for another way of carrying them out; economic benefit does not justify continuing them. Revoking a system's powers serves the safety of participants and does not determine its further fate. The precautionary procedure is described in the materials and benchmark whitepaper.¹⁰

11. Open workshops, trials and public goods#

This chapter describes how what the foundation does is created: software, documents, research and other results. The work is voluntary (chapter 5), and its results are meant to serve everyone. To make clear what we mean below, we start with a few terms:

• task: specified work for the foundation with a described goal and result, for example a new Suveria feature, the translation of a document or a cost analysis;
• private workshop: a participant's own working environment, for example in Suveria, with tools they know and context prepared for the task (section 5.4); what happens in it remains private;
• open workshop: the public place of a task paid for from shared resources, that is, from the shared budget or from computing power allocated by the foundation; in it the community can follow the scope, progress, trials and result;
• task terms: rules set before work begins: the scope, the resource limit, acceptance criteria and what part of the record of work will be published;
• record of work: the trace of the path to the result, that is, working conversations, versions and decisions; we publish it only after preparation that protects people and security;
• trial: a small, limited experiment before full implementation;
• public good: a result made available under an open license, which anyone can use, check and develop further.

You can join tasks through open invitations. At every stage we publish an invitation: whom we are looking for, what the task involves, how much time it may take and what is already in place. On the foundation's website we want to keep a list of open roles. An application is sent as an ordinary message to salve@novusignis.org, with a ready subject line that makes it possible to sort it, without any form collecting data on our server.

11.1. Open workshops: work paid for from shared resources#

When a task uses the shared budget or computing power allocated by the foundation, we run it in an open workshop. The scope of the task, the resource limit, the progress and the result can then be checked, because we work with shared money and on shared computing power.

The participant chooses how to present their contribution: under their name, a permanent pseudonym or a name assigned only to the given project. Later they can link this contribution to their own profile. A pseudonym limits the disclosure of identity, but does not on its own ensure anonymity.

Before work begins, the task terms specify what record of work we will make available and how we will prepare it for publication. Work begins in a private draft. Before publication we leave time for removing personal data, technical secrets and information about vulnerabilities until they are fixed. Automatic detection of such content helps, but a person always reviews the record as well. The published version keeps the justification of decisions and information on what we have omitted, insofar as stating this is itself safe.

Several people can work on one task: each explores a different approach, and all of them help one another with obstacles. A shared task description specifies the expected result, the way results are handed over and the acceptance criteria. A coordinator, supported by digital intelligence, compares the solutions, justifies the choice and combines the best elements, but acceptance of the finished result is decided by people, in a way that can be checked. We document the contribution of all participants, including the lessons from variants that were ultimately not used.

You can also work in a private workshop, on your own hardware or with privately paid resources. In that case, what is handed over to the community is the result and the documentation needed to accept it, without the working conversations. Whether we accept such a contribution depends on its quality, security, the rights to the material and whether it can be maintained further.

11.2. Trials before full implementation#

Before we implement something in full, we want to test it first in a small research trial or on a mock-up that can be developed during the discussion. Every trial has a defined:

• question it is to answer;
• resource limit;
• review date;
• method of assessment;
• conditions for stopping.

Trials can use computing power that happens to be free. It also has a cost and always gives way to serving users; we do not aim for our machines to be constantly fully loaded. After a trial we record what we have learned, together with rejected variants and assumptions that still need to be tested.

Full implementation requires a separate decision, a budget and a plan for acceptance and maintenance. We then assess what from the trial can be safely developed and what is better designed anew. Rewriting a program from scratch is one of the variants, but on its own it does not prove quality. Trials and implementations preserve the priority of Pillar I and the conditions in chapter 8.

11.3. Public goods: licenses and maintenance#

We make our own code and materials available on terms that allow others to use and develop them. We publish the manifesto, the whitepapers, the texts of the website and their translations under the CC BY 4.0 license, which allows the text to be used and adapted with attribution.¹¹ We will make the code of the novusignis.org website available under the AGPLv3 license, and we are considering it for the code of the services too: anyone who makes a modified version of a program available over a network must also make its source code available to its users (section 13). A license on its own does not ensure a democratic system of governance for the operator, nor does it forbid commercial uses.¹² We choose a license deliberately for each resource, checking the compatibility of dependencies and the rights of co-creators. The state of our choices today, by layer:

Our point of reference is the Digital Public Goods Alliance standard. The fact that we are moving toward it does not mean that our solutions are already recognized in its registry.¹³ For a result to truly be a public good, it needs two things:

• openness: documentation, a portable data format and the possibility for others to run the solution;
• maintenance: maintainers, security reviews, a way of reporting bugs and a clear version status.

A project abandoned without the knowledge needed to take it over only partly meets this goal. We are also considering a provision in the statute that code, data and content made available under free licenses will remain available even if the foundation is dissolved (proposal Z7 in the change register).

12. Decisions, mistakes, disputes and changes to the rules#

A foundation that asks people for trust should allow them to check how it makes decisions, how it fixes mistakes and how it changes its own rules. This chapter brings this together in one place: what we record for important decisions, how we protect the history of records from silent changes, how we settle disputes and how we change documents.

We want to keep several public registers. Each serves a different purpose:

12.1. Recording decisions and mistakes#

For every important decision we record in the decision log:

• the goal;
• the variants and sources considered;
• whom the effects will affect;
• the basis of the mandate: the result of a vote or a decision of the board in the agile phase;
• who will carry out the decision, with what budget and how we will review it.

After it is carried out, we add the result, the experiences of the people the decision concerned and the corrections made. Significant mistakes go into the public register of mistakes and lessons learned (section 8.1 of the manifesto).

12.2. A history that cannot be quietly changed#

Records are credible only if they cannot be quietly corrected after the fact. That is why we want to keep the history of important records in a public register to which entries can only be added. Each entry is cryptographically linked to earlier ones, so changing or deleting an old entry is visible. Successive states of the register are confirmed by independent witnesses, that is, people or institutions outside the foundation who confirm with a signature which state of the register they have seen.

The first things to go into it will be the fingerprints of software releases, that is, short hashes by which anyone can check that a downloaded program is exactly the one we published. Over time, hashes of the register of contributions and expenses, the decision log, the register of benefits, changes to the statute and the manifesto, and voting results will be added. We are also considering periodically recording the hash of the whole register in an existing public blockchain, if the benefit justifies the cost. We do not place in the register any private content or identifiers from which people's data could be inferred.

12.3. Disputes and emergencies#

Eventually, a dispute about a decision is to be considered by a person or body independent of whoever made the decision and is carrying it out. As long as the foundation has only a board, we publish every objection together with the board's public response, and when the board has more than one member, the one whom the matter concerns recuses themselves from deciding it. The person considering the dispute gives a justification and a deadline for a response, and their ruling can be appealed. In an emergency, limited protective action may be taken, for example suspending a service or blocking access, but it is then subject to public review. Protecting privacy may limit the details of the public record, but it does not exempt anyone from accountability.

12.4. How we change documents and rules#

The manifesto and the whitepapers are living documents. We want to submit them to public review in Omniforum, breaking their theses down into molecules, that is, individual statements and arguments that can be checked. The current version presents the foundation's current position, while the full history of earlier versions and arguments remains available, so that past actions, promises and the reasons for corrections can be assessed.

Protecting dignity, privacy and the funds entrusted to the foundation sets the permanent direction of its activity. We develop organizational rules openly: together with a proposed change, we show its scope, justification and consequences for participants. We change the statute only when the change is needed for the next step, and we apply it immediately. Changing the conditions for funding the further pillars in chapter 8 requires the proper procedure and respect for the statute, the law and commitments made earlier; until a change is adopted, the existing rules apply. We are also considering writing these conditions into the statute (proposal Z6 in the change register), so that they do not depend on the board's goodwill alone.

Novus Ignis Foundation, Poznań, KRS 0001269575. Website and manifesto: novusignis.org. Comments: salve@novusignis.org.

Notes#

1. Statute of the Novus Ignis Foundation, consolidated text of 28 September 2026. The version in force; earlier versions and planned changes are described in the statute change register. ↩
2. Ustawa o fundacjach (Act on Foundations), consolidated text, Dz.U. 2023 item 166, as amended. Legal act. The framework of the statute and the powers of the board (Articles 5 and 10). Before a legal decision, the current state of the law must be checked. ↩
3. Ustawa o działalności pożytku publicznego i o wolontariacie (Act on Public Benefit Activity and Volunteering), Article 9. Legal act. Paid activity is business activity, among other cases, when the remuneration is higher than the costs of this activity justify. Accessed 28 October 2026. ↩
4. Directive (EU) 2015/2366 (PSD2), Article 62 and the European Commission's answer concerning Article 62 (2025). Legal act and explanation. Paragraph 4: the payee does not charge fees for instruments whose interchange fees are regulated by Regulation 2015/751, or for services covered by Regulation 260/2012 (SEPA); paragraph 3 allows reductions and incentives to choose an instrument; the Commission's explanation discusses, among other things, the exclusion of certain three-party schemes. ↩
5. Titus Livius (Livy): Ab Urbe condita, Book III, chapters 26–29 (Latin text). Historical source. The Roman account of Cincinnatus, who in 458 BC accepted supreme power for the duration of a war and laid it down on the sixteenth day; this is a tradition written down several centuries later, not an eyewitness account. ↩
6. Ustawa o działalności pożytku publicznego i o wolontariacie (Act on Public Benefit Activity and Volunteering), Article 45. Legal act. The obligation to cover a volunteer's business travel costs and per diems, the possibility of release from it in writing, and the possibility of covering other necessary costs and training. Accessed 28 October 2026. ↩ ↩
7. Kodeks pracy (Labor Code), consolidated text, Dz.U. 2026 item 1245, Article 22. Legal act. Work under the employer's direction, at a place and time set by the employer, is employment under an employment relationship regardless of the name of the contract; an employment contract may not be replaced by a civil-law contract while such conditions are maintained. Accessed 30 October 2026. ↩
8. European Commission: principles of processing personal data under the GDPR. Purpose and legal basis of processing, minimization, retention period and data protection. Accessed 25 October 2026. ↩
9. Patrick Butlin et al. (2023): Consciousness in Artificial Intelligence: Insights from the Science of Consciousness. A review of theories and proposed indicators; it is not a simple scale based on the number of parameters, nor a conclusive test. ↩
10. Robert Long et al. (2024): Taking AI Welfare Seriously. An argument for assessing possible welfare and preparing protection procedures under considerable uncertainty; it does not prove the consciousness of current models. ↩
11. Creative Commons: Attribution 4.0 International (CC BY 4.0). License. Terms for sharing and adapting content with attribution; it does not settle rights to other people's materials. ↩
12. GNU AGPLv3: license terms. License. Obligations concerning code, including a modified version available over a network (section 13). On its own it does not protect the foundation's system of governance, nor does it forbid commercial services. ↩
13. Digital Public Goods Alliance: standard. Standard. Criteria for assessing a digital public good; a design direction is not recognition obtained from the DPGA. ↩

Source file: content/en/whitepaper-zasady-fundacji.md · history of changes · propose a change