A Philippine government employee may be allowed to build, own, and earn from a private software project, but “I developed it after office hours” does not settle the issue. The important questions are whether the employee obtained written authority for outside work, whether the project conflicts with official duties, whether government resources or confidential information were used, and whether the software was created as part of the employee’s assigned government work.
These questions must be examined separately. An employee may own the copyright to privately written code yet still face an administrative case for using a government laptop. A project may be developed entirely at home but still create a conflict because the employee’s office regulates the client, approves the client’s permits, or may later purchase the software.
Can a government employee legally develop private software?
Generally, yes—but only when the project complies with civil service, ethics, anti-graft, intellectual property, data privacy, procurement, and agency-specific rules.
Under the current Civil Service Commission rules, a government officer or employee who wants to engage directly or indirectly in private business or the practice of a profession must generally obtain written permission from the head of the agency. The authority must be renewed annually, the outside activity must not impair the employee’s efficiency or create a conflict of interest, and government facilities, equipment, and supplies must not be used. These requirements appear in the 2025 Omnibus Rules on Appointments and Other Human Resource Actions. (Civil Service Commission)
The risk level depends heavily on the facts:
| Private software activity | General risk level | Main concern |
|---|---|---|
| An unrelated mobile game developed at home using personal equipment | Lower | Written authority and proper separation from government work |
| Freelance programming for businesses regulated by the employee’s office | High | Conflict of interest and prohibited outside employment |
| Software based on systems the employee was assigned to develop for the government | Very high | Government-work rules, confidentiality, and possible misappropriation |
| A startup bidding to sell software to the employee’s own agency | Very high | Anti-graft, procurement, financial-interest, and intervention issues |
| Software arising from government-funded university research | Specialized | RA 10055, institutional IP policy, and technology-transfer rules |
| A private app using government databases or citizen records | Very high | Confidentiality, cybersecurity, and data privacy violations |
Some agencies, government-owned or controlled corporations, state universities, uniformed services, and positions governed by special laws or charters may impose stricter conditions. The employee must therefore check both the general civil service rules and the rules applicable to the particular office.
The four legal questions that must be answered separately
A proper legal review should not ask only, “Who owns the code?” It should answer four different questions.
1. Is the outside activity permitted?
Private software development can amount to outside employment, consultancy, professional practice, or participation in a private business. Written authority may therefore be required even when the project is done outside office hours.
2. Does the project create a conflict of interest?
A conflict can exist when the employee’s private financial interests may be affected by the faithful performance of official duties. It can arise even without proof that the employee actually favored the private business.
3. Who owns the intellectual property?
Ownership depends on whether the code was created as part of regularly assigned duties, under a private commission, with co-developers, or through government-funded research.
4. Were government resources, information, or influence used?
Government time, laptops, servers, software subscriptions, email accounts, datasets, credentials, office contacts, and nonpublic information must not be treated as personal startup resources.
Passing one test does not automatically mean the project passes the others.
Conflict of interest under RA 6713
The principal ethics law is Republic Act No. 6713, the Code of Conduct and Ethical Standards for Public Officials and Employees.
RA 6713 defines a conflict of interest as a situation in which a public official or employee is an officer, director, substantial stockholder, owner, or holder of a substantial interest in a business, and the business interest may be opposed to or affected by the faithful performance of official duties.
The law requires public employees to place public interest above personal interest and to use government resources honestly and efficiently. It prohibits several activities directly relevant to private software ventures:
- Having a direct or indirect financial or material interest in a transaction that requires the approval of the employee’s office.
- Owning, controlling, managing, or working for a private enterprise that is regulated, supervised, or licensed by the employee’s office, unless expressly allowed by law.
- Engaging in private professional practice when it conflicts or tends to conflict with official functions.
- Recommending a person for employment in a private enterprise that has a regular or pending official transaction with the employee’s office.
- Using or disclosing confidential or classified information to advance private interests or give another person an undue advantage.
- Soliciting or accepting gifts or benefits connected with official functions or regulated transactions. (Lawphil)
Examples of conflicts involving software projects
A conflict may exist where:
- An employee of a licensing agency develops compliance software and sells subscriptions to entities that the employee helps regulate.
- An information technology officer develops a private product based on internal government system specifications.
- A local government employee owns a software company that bids for a contract with the same city or municipality.
- A procurement employee privately advises a bidder on how to satisfy technical specifications.
- An employee uses advance knowledge of a planned government digitalization project to launch a competing private product.
- A government cybersecurity employee performs paid penetration testing for contractors whose systems the employee reviews officially.
Changing the registered owner to a spouse, sibling, friend, or nominee does not necessarily remove the problem. RA 6713 and anti-graft laws cover direct and indirect interests.
Written authority for outside business or professional work
The 2025 civil service rules require annual written permission for covered private business or professional activities. Approval should be obtained before the employee begins accepting clients, collecting fees, signing commercial contracts, serving as a company officer, or actively managing the venture.
A permission letter should ordinarily state:
- The name and nature of the software project.
- Whether the project is a hobby, open-source initiative, freelance service, sole proprietorship, partnership, or corporation.
- The employee’s ownership interest, management role, and expected compensation.
- The intended users, customers, or industries.
- The working hours and place of development.
- The devices, accounts, cloud services, and funds that will be used.
- Whether the agency regulates, licenses, supervises, purchases from, or otherwise deals with the intended customers.
- An undertaking not to use government time, equipment, data, personnel, branding, or confidential information.
- A commitment to disclose future conflicts and recuse from affected official matters.
- Any proposed safeguards, such as excluding government agencies and regulated entities from the customer base.
The request is commonly routed through the immediate supervisor, human resources office, legal office, ethics committee, or agency head, depending on internal procedure. There is no single nationwide processing period or fee. As a practical matter, the request should be submitted well before commercial launch because an office may require clarification, a revised project scope, or additional conflict safeguards.
Approval should be kept in writing. An informal statement such as “My supervisor knows about it” is weak protection if an administrative complaint is later filed.
Administrative liability under the current civil service rules
The 2025 Rules on Administrative Cases in the Civil Service, effective August 4, 2025, classify various conflict-related acts as administrative offenses.
Depending on the conduct, the employee may be charged for:
- Engaging in private business, vocation, or professional activity without the required permission.
- Private practice without authority.
- Having a financial or material interest in a transaction requiring the office’s approval.
- Working for or managing a private enterprise regulated, supervised, or licensed by the employee’s office.
- Misusing confidential information.
- Failing to resign from a private position or divest a conflicting interest within the applicable period.
Under the rules, a conflict requiring resignation or divestment can trigger a duty to resign from the private position within 30 days and/or divest the interest within 60 days, counted from assumption of office or from the time the conflict arises. Administrative sanctions may range from reprimand or suspension to dismissal, depending on the classification, circumstances, and repetition of the offense.
When a private software project may become an anti-graft case
A conflict of interest is not automatically a criminal offense. Criminal liability requires the elements of a specific penal law. However, certain arrangements can fall under Republic Act No. 3019, the Anti-Graft and Corrupt Practices Act.
Relevant prohibited acts include:
- Receiving a benefit in connection with a government contract or transaction in which the public officer intervenes.
- Accepting employment in a private enterprise with pending official business before the officer, during the pendency of that business or within the statutory post-employment period.
- Causing undue injury or giving an unwarranted benefit, advantage, or preference through manifest partiality, evident bad faith, or gross inexcusable negligence.
- Entering into a contract that is manifestly and grossly disadvantageous to the government.
- Having a direct or indirect financial interest in a transaction in which the officer intervenes officially or is legally prohibited from holding an interest.
- Acquiring a material interest in a transaction requiring the approval of a board or panel of which the officer is a member.
- Divulging valuable confidential information obtained through public office. (Lawphil)
The Supreme Court has explained that Section 3(h) of RA 3019 covers two distinct situations: intervention in an official transaction in which the officer has a financial interest, and possession of an interest that the Constitution or another law prohibits. (Lawphil)
For example, an employee who owns a software company should not draft specifications, determine the budget, identify suppliers, sit on an evaluation committee, approve a purchase request, inspect deliverables, certify completion, or process payment for a contract involving that company.
Recusal is important, but it does not automatically cure a legal prohibition on holding the financial interest itself.
Who owns software created by a government employee?
Computer programs are protected as literary and artistic works under Republic Act No. 8293, the Intellectual Property Code of the Philippines. Copyright protection generally arises automatically when original source code is created and fixed in a file or other tangible medium. Registration is not required for protection. (Lawphil)
Ownership depends on how and why the software was created.
| How the software was created | General copyright rule |
|---|---|
| Created outside the employee’s regularly assigned duties | The employee generally owns the copyright, even if employer time, facilities, or materials were used |
| Created as a result of regularly assigned duties for a private employer | The employer generally owns the copyright, unless an agreement provides otherwise |
| Created as part of regularly prescribed government duties | It is generally a “work of the Government of the Philippines,” to which the special government-work rule applies |
| Privately commissioned by a customer | The customer owns the physical or delivered work product, but copyright remains with the creator unless a written agreement transfers it |
| Jointly developed by several people | The contributors may become joint owners unless their rights are allocated by agreement |
| Developed from government-funded research | RA 10055 and the research institution’s IP policy may determine ownership and commercialization rights |
Software developed outside regular duties
Section 178.3 of the IP Code generally gives the employee copyright when creating the work is not part of the employee’s regular duties, even if the employee used the employer’s time, facilities, or materials.
For a government employee, however, this ownership rule must not be confused with civil service compliance. The employee might own the copyright but still commit an administrative violation by using a government computer, paid working time, office internet, government software licenses, or other public resources for the private venture.
Software created as part of official duties
A “work of the Government of the Philippines” is a work created by a government officer or employee as part of regularly prescribed official duties.
Section 176 of the IP Code provides that copyright does not subsist in a government work. Prior approval from the government agency is generally required for exploitation of the work for profit, and the agency may impose conditions, including payment of royalties. (Lawphil)
This means an employee ordinarily cannot take source code developed for an official government system, place it in a private repository, rebrand it, and sell it as a personal product. The issue is not avoided merely because the employee was the person who wrote the code.
Privately commissioned software
Paying a programmer does not always transfer copyright automatically.
For commissioned work, the person commissioning the project generally owns the delivered work or material object, but copyright remains with the creator unless the parties agree otherwise in writing. An assignment of copyright must clearly show a written intention to transfer the rights. (Lawphil)
A private software contract should therefore address:
- Ownership of pre-existing libraries, templates, and tools.
- Ownership of new source code and documentation.
- Whether rights are assigned or merely licensed.
- Rights to modify, distribute, sublicense, and commercialize the software.
- Open-source and third-party components.
- Ownership of databases, interface designs, domain names, and trademarks.
- Rights after resignation, termination, or withdrawal from the project.
- Confidentiality and treatment of customer data.
Notarization is not always what makes an intellectual property assignment valid, but a notarized agreement can strengthen proof of execution and authenticity.
Copyright does not protect the general idea
Copyright protects the original expression found in source code, documentation, graphics, and other creative elements. It does not give exclusive ownership over an idea, procedure, system, method of operation, concept, principle, discovery, or mere data. (Lawphil)
Two developers may therefore create competing applications based on the same general concept, provided one does not copy the other’s protected code or other original expression and does not misuse confidential information.
Patent rights in employee-created technology
A software-related invention may, in limited circumstances, involve patentable technical subject matter. For employee inventions, Section 30.2 of the IP Code generally gives the patent right to the employee when inventive activity is not part of regular duties, even if employer resources were used. The employer generally owns the patent when the invention results from regularly assigned duties, unless an agreement provides otherwise. (Lawphil)
Patentability is separate from copyright. Ordinary business logic, abstract ideas, and source code are not automatically patentable merely because they are new.
Government-funded research and state university software projects
Software produced through government-funded research may be governed by Republic Act No. 10055, the Philippine Technology Transfer Act of 2009.
RA 10055 generally places intellectual property arising from government-funded research in the research and development institution that performed the research, subject to statutory exceptions, funding agreements, institutional policies, and employee rights under the IP Code.
The law also allows a researcher-employee, in meritorious cases and under institutional rules, to establish or participate in a spin-off company. This may involve an approved leave arrangement and written terms governing access to laboratories, equipment, personnel, technology, and intellectual property.
A researcher with a financial interest in a spin-off must not represent the research institution in transactions involving that company. Conflict arrangements and technology-transfer agreements should be formal, written, and properly disclosed. (Lawphil)
A faculty member, researcher, programmer, or student working on a state university project should check with the institution’s technology licensing, innovation, research, or legal office before:
- Publishing source code.
- Filing an IP application.
- Bringing in private investors.
- Assigning rights to a startup.
- Licensing the software commercially.
- Using university laboratories, servers, datasets, or personnel.
- Offering the technology to outside clients.
Government data and confidential information must remain separate
A private software project must not use nonpublic government information without lawful authority.
Prohibited or high-risk materials include:
- Citizen records and personal information.
- Internal source code or system architecture.
- Government credentials, API keys, and security configurations.
- Unreleased procurement plans or technical specifications.
- Pending regulatory applications.
- Internal legal opinions and audit findings.
- Nonpublic maps, registries, reports, or datasets.
- Production database copies used as test data.
- Lists of regulated entities obtained through official access.
RA 6713 and RA 3019 prohibit the misuse or disclosure of confidential government information for private advantage. The Data Privacy Act of 2012 also requires lawful, transparent, and proportionate processing of personal information and appropriate organizational, physical, and technical security measures. Government personnel cannot simply move protected data into a personal laptop, private cloud account, or startup development environment. (National Privacy Commission)
Even information described as “anonymized” can remain sensitive when individuals can reasonably be reidentified by combining fields or matching the dataset with other sources.
Publicly accessible government data is not automatically free of all restrictions. The developer should still check:
- The portal’s terms of use and license.
- Whether personal or confidential information is included.
- Whether commercial reuse is allowed.
- Attribution requirements.
- API rate limits and security conditions.
- Whether the data was lawfully published by the proper agency.
Step-by-step guide before launching the private project
1. Review the employee’s official role
Collect and examine:
- Appointment papers.
- Position description form.
- Performance commitments and assigned deliverables.
- Employment or service contract.
- Agency code of conduct.
- Information security and acceptable-use policies.
- Intellectual property and research policies.
- Special laws or charters applicable to the office.
Identify whether software development, systems analysis, data processing, cybersecurity, procurement, licensing, or technology policy forms part of the employee’s official work.
2. Prepare a written project description
Document the proposed product, intended customers, revenue model, ownership structure, development schedule, technology stack, equipment, datasets, and expected role of the employee.
A clear description helps the agency evaluate the actual project rather than a vague request to “do freelance work.”
3. Map possible conflicts
Ask:
- Does the agency regulate, license, supervise, audit, accredit, investigate, or fund the project’s customers?
- Could the employee influence a permit, assessment, inspection, procurement, payment, or policy affecting the business?
- Does the project overlap with a government system the employee develops or manages?
- Is nonpublic information useful to the product?
- Could the employee’s official title create a commercial advantage?
- Might clients believe the product is endorsed by the government?
A “yes” does not always make the project impossible, but it requires closer review and stronger safeguards. Some conflicts cannot be solved merely by recusal.
4. Obtain annual written authority
Submit the request through the agency’s prescribed channel. Do not rely on silence, verbal permission, or the absence of an express prohibition.
If the project materially changes—for example, it begins serving regulated businesses or bidding for public contracts—the employee should disclose the change and obtain a fresh determination.
5. Create a strict operational separation
Use:
- Personal devices purchased with private funds.
- Personal internet and mobile accounts.
- Separate source-code repositories.
- Separate cloud subscriptions and email addresses.
- Private development hours.
- Independent software licenses.
- Separate accounting and business records.
Do not use government logos, seals, email signatures, office addresses, staff, vehicles, meeting rooms, or official titles in marketing unless formally authorized.
6. Put ownership agreements in writing
Before development becomes substantial, sign clear agreements with co-founders, investors, employees, contractors, and customers.
Maintain a contribution log showing who wrote each major component, when it was created, and whether it was based on pre-existing code. Keep copies of repository histories, specifications, invoices, contracts, and software-license records.
7. Update required disclosures
RA 6713 requires public officials and employees to disclose business interests and financial connections in the required statements. The Statement of Assets, Liabilities and Net Worth is generally filed within 30 days after assumption of office, on or before April 30 each year, and within 30 days after separation from service. (Lawphil)
Equity in a software company, a sole proprietorship, partnership interests, directorships, and similar financial relationships should be reviewed for proper disclosure.
8. Protect the software appropriately
Copyright exists automatically, but voluntary registration and deposit with the Intellectual Property Office of the Philippines can provide useful evidence of authorship and the date of deposit.
IPOPHL offers an online copyright deposit process. Its published fee schedule currently distinguishes between small and large entities and between filings in the National Capital Region and regional offices. Applicants should verify the latest amount through the IPOPHL copyright registration and deposit portal and official copyright fee schedule before filing. (IPOPHL)
The product name, logo, and other brand identifiers may require separate trademark protection. Copyright registration for the source code does not register the brand as a trademark.
Selling software to the employee’s own agency
This is one of the highest-risk arrangements.
The employee or employee-owned company should not participate in:
- Identifying the procurement need.
- Preparing specifications or terms of reference.
- Conducting market research or price estimates.
- Recommending a procurement method.
- Preparing or approving the budget.
- Evaluating bids.
- Inspecting or accepting deliverables.
- Approving invoices or processing payment.
- Managing the resulting contract.
The New Government Procurement Act, RA 12009, and its current implementing rules contain conflict-of-interest and beneficial-ownership requirements. Legal entities participating in government procurement must make required beneficial-ownership disclosures, and false or missing disclosures can result in disqualification or blacklisting. (GPPB-TSO)
Even when the employee completely recuses, RA 6713 or RA 3019 may independently prohibit the financial interest. The legality cannot be decided solely by the Bids and Awards Committee’s willingness to accept the bid.
Common real-life scenarios
A public school employee builds an unrelated game
A teacher or administrative employee who develops a game at home using personal equipment is generally in a lower-risk position when the work is unrelated to official duties. Annual written permission may still be required once the employee operates it as a business, accepts paid work, or actively manages commercial operations.
A government IT officer develops an attendance platform
If the officer’s assigned duties include building attendance, payroll, personnel, or school-management systems, a private attendance platform may overlap with regularly prescribed work. The officer should document which components were independently created and obtain an agency determination before commercialization.
Copying an official repository and rewriting the interface will not necessarily make the resulting product private property.
A regulatory employee creates a compliance application
An employee of a tax, licensing, customs, health, environmental, or financial regulator faces a heightened conflict risk. Customers may be entities whose applications, audits, assessments, or permits are handled by the office.
The employee must not market insider access, advance interpretations, faster approvals, or influence over government personnel.
An LGU employee’s startup wants to sell to the LGU
The employee’s ownership must be disclosed. The employee must not participate in any stage of the transaction, but recusal alone may be insufficient if the employee is legally prohibited from holding the interest. The arrangement requires review under RA 6713, RA 3019, RA 12009, local rules, and the employee’s actual authority.
A state university researcher forms a startup
When the product arose from funded research, university facilities, or an institutional research program, ownership and licensing should be processed through the university’s technology-transfer and IP system under RA 10055. A private incorporation document cannot by itself transfer rights belonging to the institution.
An employee publishes government-related code as open source
Open-source release is still a form of distribution. The employee should confirm that the repository contains no government work, restricted code, licensed third-party components, security-sensitive material, or personal data.
Calling a project “open source” does not eliminate government ownership, confidentiality, or authorization requirements.
Documents worth keeping
| Document | Why it matters |
|---|---|
| Written annual authority for outside work | Proves the agency approved the disclosed activity |
| Position description and appointment papers | Helps determine whether software creation is part of regular duties |
| Project scope and conflict assessment | Shows what was disclosed and how conflicts were evaluated |
| Recusal memorandum | Records withdrawal from affected official matters |
| SALN and business-interest disclosures | Demonstrates compliance with statutory disclosure duties |
| Cofounder, contractor, and employee IP agreements | Allocates ownership of source code and other assets |
| Repository history and contribution records | Helps prove authorship, timing, and independent development |
| Open-source license inventory or software bill of materials | Identifies third-party code and license obligations |
| Equipment and subscription receipts | Supports proof that private resources were used |
| Data-use, sharing, or API authority | Shows lawful access to information used by the software |
| IPOPHL deposit certificate | Provides additional evidence concerning the deposited work |
For documents executed abroad, a written IP assignment remains essential. When a foreign-notarized document must be presented to a Philippine government office or used as formal evidence, an apostille may be required, depending on the receiving office and the document’s country of origin.
Foreign developers and cofounders can generally own or share copyright in Philippine software, subject to applicable treaty and reciprocity rules. A nonresident applying for a Philippine patent must appoint a resident agent or representative in the Philippines. (Lawphil)
Frequently Asked Questions
Can a Philippine government employee code after office hours?
Yes, but working after hours is only one factor. The employee may still need annual written authority and must avoid conflicts, government resources, confidential information, and projects connected with regulated or official transactions.
Do I need permission if the software is only a hobby?
A purely personal, noncommercial hobby may not yet amount to private business or professional practice. The issue changes when the employee accepts clients, receives advertising income, sells subscriptions, incorporates a company, manages commercial operations, or regularly provides paid services. Early written clearance is prudent when commercialization is planned.
Who owns code written on a government laptop?
If the code was not part of regular duties, the employee may have a copyright claim under Section 178.3 of the IP Code. However, using a government laptop for private business can separately violate civil service and ethics rules. Ownership does not excuse misuse of public property.
Can the agency claim an unrelated app I created at home?
Ordinarily, an unrelated app created outside regularly assigned duties belongs to the employee, subject to any valid agreement, special law, institutional policy, or government-funded research arrangement. The employee should maintain records proving independent development.
Can I sell my software to the government agency where I work?
This is legally high risk. Financial-interest, intervention, anti-graft, procurement, and beneficial-ownership rules may apply. Recusal does not automatically cure a statutory prohibition. The employee should not take part in specifications, budgeting, evaluation, approval, inspection, or payment.
Can I use a government dataset in my private application?
Only when the data was lawfully made available for that use and the applicable terms, privacy rules, security requirements, and licensing conditions are followed. Internal databases, citizen records, credentials, and nonpublic datasets must not be copied into a private project.
Must I register my source code with IPOPHL?
No. Copyright generally exists from creation. Voluntary deposit can nevertheless provide useful evidence of authorship and the deposited version of the work.
Does paying a freelance developer mean I own the copyright?
Not necessarily. Under the IP Code’s commissioned-work rules, the developer may retain copyright unless a written agreement transfers it. The contract should contain an express assignment or a sufficiently broad license.
What if my software came from government-funded research?
RA 10055 and the institution’s intellectual property policy may give ownership or commercialization authority to the research institution. Disclosure to the technology-transfer, research, or legal office should occur before incorporation, licensing, publication, or investor negotiations.
Can a foreign cofounder own part of the software?
Generally, yes. The parties should use a written agreement covering ownership, assignments, licensing, governing law, dispute resolution, confidentiality, and cross-border data handling. Formal documents signed abroad may require apostille or other authentication when presented to Philippine authorities.
Key Takeaways
- A government employee may develop private software, but after-hours work alone does not make the project permissible.
- Annual written permission from the agency head is generally required for private business or professional activity covered by civil service rules.
- The employee must avoid clients, transactions, and businesses regulated, supervised, licensed, or approved by the employee’s office.
- Copyright ownership and administrative compliance are separate issues.
- Code created outside regular duties generally belongs to the employee, while code created as part of official duties is subject to the special rules for government works.
- Government equipment, time, data, credentials, personnel, and confidential information must not be used for a private project.
- Selling software to the employee’s own agency creates serious anti-graft and procurement risks that recusal may not cure.
- Government-funded research and state university projects may be governed by RA 10055 and institutional technology-transfer policies.
- Written permissions, conflict disclosures, IP assignments, contribution records, and strict separation of resources provide the strongest practical protection.