PowerPoint Presentation

[Audio] Welcome to Module 3, Protecting and Managing IP and Data Rights.

[Audio] At the end of Module 2, I said that as you begin talking to customers and partners, you need to know what you own and what you are free to share. This module is about exactly that. Let me start with why it matters commercially. Imagine you have found an interested cooperative, and they are ready to run a pilot. Before they commit, their lawyer, or an investor's lawyer, will ask a short list of questions. Who owns the software? Does your university or institute have a claim on it? Do the other project partners co-own it? Does it include anyone else's code or data, and under what licence? Are you allowed to use the farm data that trained the model? If the answers are unclear, the deal slows down or stops. Unclear rights are among the most common and most avoidable reasons why promising research outcomes never reach the market. So in this module, we will work through six practical steps. We will map the assets you have. We will check who owns them, with a particular focus on collaborative European research projects. We will look at the main forms of protection and which suit software, models and data. We will discuss disclosure and timing, because what you say publicly can limit your options. We will look at open-source and licensing choices. And we will spend time on farm data, which is the raw material of digital agriculture and carries its own rules and expectations. A word of caution. I am not a lawyer, and nothing in this seminar is legal advice. Intellectual property law varies between countries and depends on the facts of each case. My aim is to help you ask the right questions and to know when to involve your technology transfer office, your institution's legal team, or a qualified IP professional. Let us begin..

[Audio] The first step is an inventory. Many teams discover, when they sit down and list what is inside their outcome, that it is a mixture of things with very different origins and conditions. Start with background. This means what you or your institution already had before the project started: existing code, datasets, methods, or know-how. It may belong to you, to your institution, or to someone else who allowed you to use it. Next, results. These are what the project or research work generated: new software, new models, new datasets, new protocols, a prototype design. Here, ownership depends on who produced the results and under which agreements, and we will look at the Horizon Europe approach on the next slide. Third, third-party components. Almost every digital product includes things made by others: open-source libraries, commercial software, maps, satellite imagery, public datasets, and cloud services. Each one comes with its own licence, and some licences place conditions on what you can do with the combined product. You need a list. Fourth, data. In digital agriculture, data is often the most valuable and the most sensitive asset. Make a list of where your data came from: your own field trials, sensors, farmer partners, public sources, or commercial providers. For each source, note under what permission you hold it. Fifth, brand and know-how. A product name or logo, a trained team's experience, an unwritten way of calibrating a sensor. These can be commercially important and are often forgotten. For each item, ask three questions. Who owns it? Who is allowed to use it? And on what basis, such as a contract, a licence, a consent form, or an employment relationship? Where you cannot answer, write "unknown". An honest "unknown" is far more useful than a confident guess, because it tells you where to look. This inventory will become the basis of your exercise at the end of this module..

[Audio] Who owns research results? The honest answer is: it depends, and you need to check. But there are some common patterns. First, institutions. In many countries, and in many employment contracts, the rights to inventions and software created by researchers in the course of their work belong to the employing institution, or are subject to the institution's policy. A researcher may be the author, but the university or research centre may be the owner. Your technology transfer office can tell you your situation, and you should speak with them early. Second, funded projects. In Horizon Europe, the general rule is that the participants who produced the results also own them, and results may be jointly owned where their parts are inseparable. This matters enormously for collaborative projects, because a digital tool often combines contributions from several partners. When ownership is joint, the partners should agree in writing how the result will be used, protected and licensed, through a joint ownership agreement. Also, the grant rules require a results ownership list in the final report, which lists the institutions that co-own the results, so the funder can see who holds what. Third, obligations. Under the Horizon Europe grant rules, the beneficiaries have duties as well as rights. They are expected to protect their results where protection is possible and justified, and to ensure that their results are exploited, either by using them directly or by transferring ownership or licensing them to others. Where relevant, they must also use the Horizon Results Platform to find interested parties to exploit their results. And any transfer or licence of results has to respect the conditions set in the grant agreement. These rules are found mainly in Articles 16 and 17 of the Horizon Europe Model Grant Agreement and its annexes, though the specific work programme or call may add conditions. Always read the version that applies to your own project. So, what should you do in practice? Gather three documents: your grant agreement, your consortium agreement, and your institution's IP policy. Look for who owns what, any restrictions on commercial use, any requirement to consult or notify partners, and any conditions on transferring results to a third party, including outside Europe. If you are unsure where to begin, the EU IP Helpdesk offers free first-line support on intellectual property for those working in EU-funded research and innovation. It is a useful starting point before you spend money on legal advice..

[Audio] There is no single thing called "IP protection". There are several tools, and each protects something different. Let me go through the main ones as they apply to digital agriculture. Patents protect technical inventions that are new, involve an inventive step, and can be applied industrially. A patent gives its owner the right to stop others from making or using the invention for a limited time, in exchange for publishing how it works. Patents can be valuable, for example for a new sensor design or a novel hardware method, but they are expensive and slow, and the application is typically published some eighteen months after filing. So they make sense where the invention is genuinely technical and the commercial value justifies the cost. Copyright arises automatically when someone creates an original work. It protects the expression, not the underlying idea: so the source code of your software, your documentation, your images and your user interface text are protected, but the idea or method behind them is not. In the European Union, the legal protection of computer programs is harmonised under the Software Directive. Trade secrets protect valuable information that is kept confidential. Under the EU Trade Secrets Directive, information qualifies if it is secret, has commercial value because it is secret, and the holder has taken reasonable steps to keep it secret. For a trained model, a calibration method or a proprietary dataset, this is often the most practical protection, but only if you actually control access through contracts and security. Trademarks protect names and logos that distinguish your product from others. In a market where trust is central, as we discussed in Module 1, a recognised and reliable name is a real asset. Then there is the EU database right. This is a special right, created by the Database Directive, that protects the substantial investment made in obtaining, verifying or presenting the contents of a database. In general, it protects the investment in a collection, not the creation of the data itself, so it is not a simple answer for ownership of sensor data, and you should take advice before relying on it. And finally, contracts. Many commercial arrangements, such as confidentiality agreements, data-sharing agreements and licences, depend on contracts more than on formal rights. Contracts are what allow you to share your outcome with others while keeping control of it. The practical lesson is to combine tools. A typical digital agriculture product might rely on copyright for its code, trade secrets for its models and data, a trademark for its name, and contracts for everything else..

[Audio] Since many of you work with software, models and algorithms, let us look at them specifically. Start with code. Source code is protected by copyright, which stops others from copying it. But copyright does not stop someone from writing different code that does the same thing. The European Court of Justice has confirmed that the functionality of a program, what it does, is not itself protected by copyright. This means that if your competitive advantage lies in an idea or a method, copyright alone will not protect it. Could a patent help? In Europe, the European Patent Convention excludes computer programs "as such" from patent protection, and mathematical methods too. That does not mean that anything involving software is unpatentable. Inventions that make a technical contribution, for example a method that controls a physical process such as a sprayer or irrigation system in a technically novel way, may be patentable. This is assessed case by case, and it is a specialist area, so take professional advice before assuming that either yes or no applies to your case. For trained models and curated datasets, the legal position is still developing. In practice, the main protections are secrecy and contract: you keep the model and its training data confidential, you control access through licences and technical measures, and you make sure that agreements with partners and customers say what they may and may not do with it. Two habits will save you a great deal of trouble. First, check the licences of every component and every dataset you used. Some open-source licences place conditions on what you can do with the combined software, and some datasets allow research use only, not commercial use. It is far easier to discover this now than during due diligence with an investor. Second, record provenance. Keep a clear record of versions, authors, and data sources: who wrote what, from which repository, using which data under which permission. A well-kept record turns a long investigation into a short conversation..

[Audio] Let us talk about timing, because the order in which you do things can determine your options. If you think a patent might be valuable, remember that a patent requires novelty. In Europe, anything made public before the filing date can destroy novelty, and that includes your own actions: a journal article, a conference presentation, a poster, a thesis, a project website, even a demonstration to people who are not under a confidentiality obligation. Europe has only very narrow exceptions, so the safe rule is: file first, publish after. The Horizon Europe approach follows the same logic. The guidance on grant rules states that protection of results should be done before dissemination, or the opportunity may be lost, and dissemination should not compromise intellectual property protection. Your consortium agreement may also require advance notice to your partners before you publish. So, before any publication, ask: has anyone considered whether this is protectable? gov This does not mean you should stop publishing. Publication is a core part of research and often a funding requirement, and open science is valued. It means coordinating: decide together what will be protected, what will be published, and in which order. Now, confidentiality. When you speak with potential partners, investors or large customers, you may need to share details that are not public. A confidentiality agreement, often called an NDA, is a contract in which the other party agrees to keep the information secret and use it only for the agreed purpose. Your institution probably has a standard template. Use it, and have it signed before the sensitive conversation, not after. And here is some reassurance, going back to Module 2. Customer discovery interviews rarely require you to reveal anything secret. You are asking about their problems, not describing the inner workings of your solution. You can explain what the solution does for them without explaining how it works. That means you can usually start learning from customers right away, while the protection questions are still being resolved..

[Audio] Many people believe that open and commercial are opposites. In fact, open approaches can be a deliberate and successful commercial strategy, as long as they are chosen on purpose. Start with open science. Research funders, including Horizon Europe, expect open access to peer-reviewed publications and responsible management of research data, following the principle of being as open as possible and as closed as necessary. That last part matters: protecting results that have commercial potential is consistent with open science. Now open-source software. There are two broad families of licences. Permissive licences, such as MIT or Apache 2.0, allow others to use, modify and even incorporate your code into commercial products, with few conditions. They encourage adoption, but they also allow a competitor to build on your work. Copyleft licences, such as the GPL and the AGPL, require that derivative works are shared under the same terms. The AGPL extends this to software offered as a network service, which is relevant if you run a cloud platform. Copyleft can protect a community, but it can make commercial partnerships harder if a company does not want to share its own code. Some organisations use dual licensing: the code is open source for community use, and a separate commercial licence is offered to companies that want different terms. Others open the core and sell services, hosting, support or add-on modules. Whichever route you choose, make sure that all contributors agree to it and that all components are compatible. Now commercial licensing, where you allow another company to use your outcome in return for payment. Key variables include exclusivity: exclusive means only one licensee, non-exclusive means several. Field of use: for example, only for vegetable crops. Territory: for example, one country or region. And revenue structure: an upfront fee, royalties on sales, milestone payments, or equity in the company. Exclusivity usually commands a higher price but ties your hands, so negotiate carefully, and remember that, for results from funded projects, any licence must respect the conditions in the grant agreement. Licensing is one of the main routes to market for research outcomes, and we will compare it with other routes in Modules 4 and 5..

[Audio] Now we come to something particular to digital agriculture: farm data. Without data from fields, animals, machines and sensors, most digital tools cannot exist. And farmers, rightly, care a great deal about who controls it. For any dataset you use, ask three questions. Who generated or collected it? What permission do you have to use it: consent, a contract, a licence? And which legal rules apply? First, sector principles. In April 2018, a coalition of European agri-food organisations launched the EU Code of Conduct on Agricultural Data Sharing by Contractual Agreement. It recognises that the data originator, the one who created or collected the data, should have a leading role in controlling access to and use of that data and in benefiting from sharing it. The Code is voluntary, but it expresses expectations that many farmers and cooperatives share, and it is a good guide to how your data terms will be judged. Second, the General Data Protection Regulation. Farm data that is linked to an identifiable person, for example a named farmer's field records, location and yields, may well be personal data. If so, you need a lawful basis for using it, a clear purpose, transparency, and appropriate security. Consent forms should say plainly what data you collect, why, who sees it, how long you keep it, and how to withdraw. Third, the EU Data Act. This regulation is Regulation (EU) 2023/2854. It applies from 12 September 2025, with the duty to design connected products so data can be accessed applying to products and related services placed on the market after 12 September 2026. Among other things, it gives users of connected products, including industrial and agricultural machinery, the right to access the data they generate, and requires manufacturers and service providers to share data fairly. For you, this can open opportunities, because users may be able to authorise a third party, such as your service, to use their machine data. It also creates obligations if you make connected devices. One caution. The rules are still moving. The European Commission proposed in November 2025 a Digital Omnibus package that would amend several digital laws, including the GDPR and the Data Act, and EU member states were working on the Council's negotiating position in October 2026. So please check the current legal text, and take advice, before you rely on any detail from this slide. The practical message is simple: treat data terms as part of your product. Clear, fair agreements with farmers and partners are not a legal chore. They build the trust on which, as we saw in Module 1, adoption depends..

[Audio] This is our third working exercise: your rights audit. Please pause the video when I finish. Step one: draw a table with six columns. Asset. Owner or owners. Basis, meaning the contract, policy, licence or consent that gives them the right. Protection, meaning what form of protection applies or could apply. Restrictions, meaning any conditions or limits. And next action. Step two: fill in the rows for the assets you listed earlier: your code, your models, your datasets, any hardware designs, your brand, and every important third-party component. Use the same outcome you chose in Module 1. Step three: find the documents that decide ownership: the grant agreement and consortium agreement, if you worked in a funded project; your institution's IP policy; and any consent forms or data agreements for your datasets. You may not have them to hand right now, and that is fine. Write down where to find them. Step four: wherever you cannot answer, write "unknown". Those cells are your priorities. Step five: make a short list of what must not be disclosed yet, for example an invention you may want to patent, or a model you intend to keep confidential, and decide who needs to be told before anything is published. Finally, choose one next action for each "unknown", with a person responsible. For many of you, the first action will be a conversation with your technology transfer office. Take around ten minutes. Pause the video now..

[Audio] Let us summarise Module 3. We started with a simple point: before you can sell something, you need to know what you own and what you are free to use. We built an inventory of assets: background, results, third-party components, data, and brand. We looked at who owns research results, from institutional policies to the Horizon Europe rules on ownership, joint ownership agreements, the results ownership list, and the duties to protect and exploit results. We reviewed the main forms of protection, patents, copyright, trade secrets, trademarks, the database right and contracts, and we saw how they fit software, models and data. We discussed the importance of timing: protect before you disseminate, use confidentiality agreements when needed, and remember that you can learn from customers without revealing the secrets of your solution. We compared open-source and commercial licensing as deliberate strategies, and we examined farm data, where the sector's expectations, the GDPR and the Data Act all matter, and where fair, transparent agreements build trust. If you completed the rights audit, you now have your list of "unknowns" and a plan to resolve them. That is real progress, and probably more than many projects ever achieve. Keep it with your Module 1 scorecard and your Module 2 notes. Please remember that this is general information, not legal advice. For decisions that matter, involve your technology transfer office or a qualified IP professional. Now we will take a short break. When we return, in Module 4, we turn to the business model: how you create value, how you capture it, and how you set a price that customers accept and that sustains your business..

References. Regulation (EU) 2023/2854 of the European Parliament and of the Council of 13 December 2023 on harmonised rules on fair access to and use of data (Data Act). Application: 12 September 2025; Article 3(1) for products placed on the market after 12 September 2026 (Article 50). Horizon Europe Model Grant Agreement, Articles 16 and 17 and Annex 5 (intellectual property, communication, dissemination); Annotated Model Grant Agreement. Check the version used in your own project. Copa-Cogeca, CEMA and others. (2018). EU Code of conduct on agricultural data sharing by contractual agreement. Launched 23 April 2018. European Commission. (2025, November 19). Digital Omnibus proposals (amending, among others, the GDPR and the Data Act). Council negotiating position under discussion in October 2026; check the current status before recording. Regulation (EU) 2016/679 (General Data Protection Regulation). Directive (EU) 2016/943 on the protection of undisclosed know-how and business information (trade secrets). Directive 2009/24/EC on the legal protection of computer programs. Directive 96/9/EC on the legal protection of databases. European Patent Convention, Article 52 (exclusions from patentability, including programs for computers “as such”) and Article 55 (limited non-prejudicial disclosures). Court of Justice of the EU, Case C-406/10, SAS Institute v World Programming (2012), on the non-protection of program functionality by copyright..

[Audio] Thank you!. thank you!. TALLHEDA has received funding from the European Union's Horizon Europe research and innovation programme under Grant Agreement No. 101136578. Funded by the European Union. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Research Executive Agency (REA). Neither the European Union nor the granting authority can be held responsible for them..