MasterOSS

What is AI and when is it a compliance risk? When looking at the question "what is AI" from the legal side, in order to evaluate whether your software application is qualifying as an AI system which falls under a specific AI regulation, one might get into a somewhat daunting situation, especially when assessing compliance related risks. To determine whether a particular AI related regulation applies to your system in use you would first have to check whether your system falls into the scope of the definition of AI as per that particular regulation. And  this might be just the first hurdle your company will face. Why? It seems that there is no common definition. Instead, there are many definitions and their scope depends on the regulation at hand. At the same time, regulatory definitions will likely be very broadly defining what AI is, as for example in the EU AI Act, the AI Advancing American Act, the AI in Government Act or the FY 2019 National Defense Authorization Act. But definitions are only your first hurdle. Your company will likely want to know and be clear about what issues the applicable regulation is actually trying to protect against, and whether your specific AI system (that you build or use) could create a risk scenario or trigger certain compliance requirements for your company. On a very high level, what the regulators are mainly concerned about when it comes to AI are currently things like data privacy, transparency related to training data and IP infringement in the context of data use, bias, public trust as well as national defense. Adding OSS into the AI mix will certainly make a critical difference when it comes to assessing compliance risks as well as opportunities in the context of regulatory compliance.  How to effectively maneuver through the jungle of AI related regulations will be therefore critical for various market players such as companies of all sizes, educational organizations partnering with industry as well as nonprofits engaging in the field of AI and OSS to address all requirements properly and in due time, ideally ahead of running into compliance or other business or operational risks. It will also be a factor to consider for remaining competitive, successful collaborations in fields of emerging technologies, and meeting commercial or social objectives. Are you prepared? #AI #compliance #strategy #opensource Image credit goes to: Veronika Oliinyk

A different application for crowdsourcing and bounties in OSS. If like us you are avid followers of Open Source whether in the realms of software or beyond, you will already be familiar with these terms. OSS in itself is an example of crowdsourcing, bringing together developer talent from all over the world in an effort to improve or provide open solutions to existing software applications or code artifacts. Both crowdsourcing and bounties have become stock-in-trade components of OSS business models giving rise to web platforms; 🫧 for soliciting resources for a particular project; and 💵 for pooling money from the interested user base in order to provide financial incentive and reward for developers who submit the best solutions, typically in the form of security and vulnerability fixes. Recently, the Cloud Native Computing Foundation ("CNCF") merged these two concepts as a way of building an arsenal for combating the ever-present threat of patent trolls. 💡 The Cloud Native Heroes Challenge is a cost-effective and efficient idea for capturing prior art that will knock out the patents being exploited by the trolls. Discovery of prior art is a time-consuming task for even the largest of organizations and can be especially challenging in the world of algorithms and software-related patents. The CNCF approach constitutes an appeal to its own community, to fellow OSS communities and also to a much wider fraternity of OSS adopters. It also provides a not-insignificant financial reward for whoever comes up with the most impactful submission. This looks like a model that could catch on, perhaps even in the proprietary domain. What do you think? #OSS #OpenSource #CNCF #crowdsourcing #bounties #patent #trolls Image credit goes to: Ivelin Radkov

How quickly can your company ADAPT its OSS USE to BUSINESS CHANGES?   Companies of all sizes and in all industries change their business strategies for a variety of reasons, often stemming from internal or external pressures. Some of the most common external factors are changing market conditions, technological advancements, mergers and acquisitions or sustainability concerns. Internal factors for changing the direction could be also a new leadership, operational inefficiencies, growth objectives or restructuring needs.   Changes in business due to various factors can significantly influence your organization's use of open source software in its internal operations, in its products and in its business engagements with third parties. In these cases, each scenario requires a specific approach, for example:   🧐 Growth objectives might require your company to move from selling products to adding certain cloud based services. This approach requires for example adjusting your OSS licensing strategy to ensure e.g. compatibility with recurring revenue streams. It might also involve the need for changing your licensing to dual-licensing and offering commercial add-ons to open-source components.   🧐 A strategic shift towards differentiating through new proprietary features could lead to  putting greater emphasis on using open source for the more commoditized components of the product or system. Alternatively, additional involvement in open source specialty libraries might be necessary to reach the next level of market acceptance for your product.   🧐 Entering heavily regulated sectors (e.g., finance, healthcare) might necessitate stricter control over use of software components as well as a heightened scrutiny of e.g. open-source licenses to ensure legal compliance. This might involve more rigorous checks auditing of open-source components and potentially limiting the use of certain licenses.   🧐 Integrating a new company could introduce conflicting open-source policies and software stacks, requiring consolidation and rationalization of OSS software usage and harmonization of policies.   🧐 A focus on cost-cutting could lead to increased reliance on open source to reduce software licensing expenses. However, this must be balanced against the costs associated with managing and maintaining open-source components.   When addressing relevant business changes it is key for a company to also proactively review the area of OSS consumption to identify and implement all required changes in due time in order to continue leveraging all the benefits of open-source software while effectively adapting to new circumstances. #opensource #strategy #changemanagement #riskmitigation Image credit goes to: Pavlo Stavnichuk  

Ensuring OSS is used in a secure way is NOT always a quick fix. OSS is powerful, but it also comes with many challenges and responsibilities, especially related to management of security related risks. 👏 Let’s assume your organization relies on IT infrastructure and/or software applications to manage its operations. 👏 Let’s further assume your organization brings software applications to market and relies on the software supply chain. 👏 Let’s further assume security is a critical consideration for your organization when it comes to managing all relevant workloads. ❓ In this case may we also assume your organization considers all critical areas when it comes to OSS security? Like all software, open source software also has its vulnerabilities from time to time. 😄 This does not mean that open source software is less secure and more vulnerable than proprietary software. It simply means there is far more software code in OSS than we might think. 😬 When it comes to OSS certain key areas such as knowing your dependencies, ensuring source, build and package integrity are of course highly critical when determining security related questions of your OSS component and code. And luckily there are various powerful tools in the market supporting companies with evaluating exactly that to ensure vulnerability threats are identified so that OSS may be consumed in a relatively secure way. 💪 👉 However, identifying potential threats in dependencies, sources, the building process and packages is key but these are not the only critical areas of consideration. 👆 One additional key consideration would be the evaluation of the OSS projects and the actual set-up that stands behind and influences development of the OSS components or code your organization chooses to consume and integrate. And here we mean topics related to OSS projects that you might not think about directly when reviewing security related questions, such as: 👉 the health and sustainability of a project, 👉 the vitality of the project community, 👉 maintenance and releases, or 👉 the project governance. 👆 Another area of critical consideration is to what extent security related regulatory trends and requirements are fulfilled when the OSS code is not only created but also when it is later integrated into the actual application. Again, tools are definitely important to address OSS security risks. But even the best software tools will not necessarily be enough. There are additional questions that will need to be addressed to ensure OSS related security risks are properly mitigated. mOSS is here to support your organization in identifying all security relevant topics and finding the right risk mitigation solution! #opensource #security #risks #management #strategy #code Image credit goes to: TatianaNikulina

The PATENT TROLLS are back 👹 👺. We have posted before about patents in the context of Open Source software. Here's another one. Whether you are seeking to monetize a software service or sell a software-enabled product using an OSS core, you would be well-advised to check out the OSS license used and also the ecosystem of contributors. Why? Well, think about the parallels between technology standards consortia and popular open source projects. In either case you are likely to find large and powerful players with deep pockets and extensive patent portfolios. In the standards world, patent holding participants are constrained from hijacking the standard for their own personal gain by the concept of FRAND licensing of necessary patents. FRAND means a license royalty payment which is: ✅ Fair; ✅ Reasonable; ✅ Non-discriminatory. In the world of OSS licensing, a similar result can be achieved by choosing a license that requires royalty-free licensing of patents by those contributing to the project software, where the use of the contributed code would otherwise lead to infringement of the patent. Apache 2.0 license is perhaps the best example. This one is in other respects classified as a 'permissive' OSS license, meaning that users can create derivative applications without jeopardizing their proprietary rights in the new features and functionalities they add. Now, let's consider what would happen if the patent holder in due course has no skin in the game i.e. they have no interest in: ❎ innovation ❎ selling products of their own ❎ creating or commercializing new products In short, they are a Patent Troll. The practice of the troll is to extract settlement or license fees by issuing threats of lawsuits. They pick off the low-hanging 🍒 to build up a war chest, with which to eventually go after the 🐳. Many small and medium sized enterprises have no appetite for engaging in multi-million 💰 lawsuits, so they capitulate quickly to the threats without testing the (often doubtful) validity of the patent or patents in suit. It seems that the Linux Foundation and others have been fighting off open source patent trolls for years. The problem seems to be particularly acute right now for users of Kubernetes due to a particularly broad patent US-11695823-B1. Apparently, just about any cloud native architecture could be held hostage by this patent. An OSS Foundation like Linux has the knowledge and resources to take effective action i.e. crushing the patents at the Patent Office. But this also takes time, money, expertise and resources that individual companies can rarely afford or obtain. If you are contemplating using OSS in your product or service offerings, and that software has no backing from an OSS Foundation, this is a risk that needs addressing. Once again, don't forget the patents 🌩️ 💥 #OSS #patents #trolls #Linux #Foundations #kubernetes #licensing Image credit goes to: Memoangeles

Are you ready for LEVERAGING SYNTHETIC DATA and OPEN SOURCE tools to develop secure privacy-preserving AI solutions? Synthetic data offers a powerful solution to the growing data security concerns surrounding AI development and deployment. By generating artificial data that statistically mirrors real data without containing any sensitive individual information, it enables AI training and testing without exposing real user data to potential breaches or misuse. This is particularly valuable in privacy-sensitive domains like healthcare, finance, and government. Here is why: 🐊 Synthetic data decouples AI development from the need for real user data, eliminating the risk of re-identification and privacy violations. 🐊 Using synthetic data simplifies adherence to regulations like GDPR, CCPA, and HIPAA by removing the need for complex data anonymization and consent management procedures. 🐊 Synthetic datasets can be readily shared with internal teams, external partners, and even the public, fostering collaboration and innovation without compromising privacy. 🐊 Even if a synthetic dataset is compromised, no real user data is at risk, minimizing the impact of security breaches. This is all great! However, to what extent does your company also manage risks related to OSS components that might be (highly likely are) part of the tools your company is using for data generation? While OSS components can offer cost-effectiveness and flexibility for synthetic data generation, they also introduce potential risks, such as: 🐍 Code vulnerabilities: OSS code may contain vulnerabilities that could be exploited by attackers to gain access to systems or manipulate the synthetic data generation process. 🐍 Data poisoning: Malicious actors could contribute compromised code or models to OSS repositories, leading to the generation of biased or poisoned synthetic datasets. 🐍 OSS License compliance: Using OSS components requires careful attention to licensing terms, as some licenses may restrict commercial use or require attribution. 🐍 Lack of support and maintenance: OSS projects can sometimes lack dedicated support and maintenance, potentially leading to difficulties in resolving issues or adapting to evolving needs. It is therefore key to carefully consider OSS risks and related legal and technical concerns when setting up approaches to address such risks on all critical levels and in order to create solutions you can trust. #opensource #strategy #compliance #safety #AI #syntheticdata Image credit goes to: Mauricio Graiki

You are the head of IT in a healthcare department (public or private) somewhere in the world, call it Suedonia. You are faced by the usual problems besetting IT departments all over the world i.e. matching headcount budget with adequately servicing internal clients, maintaining infrastructure and ensuring continuity of service. You are faced with the need for replacing a certain critical software application due to lack of ongoing support from the software vendor. The loss of support is putting huge strains on your existing resources, causing user frustration and frequent disruption to productive working. The situation is no longer sustainable and you are under pressure to solve the problem and solve it quickly. There are several options open to you: 1. Upgrade to the same vendor's latest proprietary application, which has features and functionality beyond your everyday needs and is 50% more expensive than the sunset application; 2. Migrate to another proprietary vendor solution which is more aligned with your needs, is only 25% more expensive, but for which additional technical changes may be necessary and administrator/user training will increase the up front cost and work productivity disruption; 3. Switch to a popular and market accepted OSS alternative for your existing application, at considerably less up front investment, and which would be available either: - for on premises deployment, or; - as a public or private cloud based SaaS How will you set about making a decision and what factors will you want to consider. Here are a few to get started: ✅ Tolerance for repeated End of Life disruption; ✅ Customization needs; ✅ Cyber risks (e.g. availability of a Software Bill of Materials) ✅ Implementation and maintenance resources ✅ Regulatory matters ✅ Legal recourse in case of software failures ✅ Privacy and information security Now imagine the same scenario but this time you are the CTO and the application is a critical part of a software service or digitally-enabled device your business is providing to your healthcare clients. Finally, bring in an additional pressure from the Board of your organization to offer a solution powered by Generative AI. Will you be equipped to make these decisions or will it be sleepless nights? #IT #OSS #EOL #Cybersecurity #Regulatory #GenAI Image credit goes to: ArtemisDiana

A new OSS litigation topic to consider The legal spat between WordPress (an ongoing OSS project) and WP-Engine (a hosting platform) is another interesting example of how the fragile dynamics of the Open Source 'give' and 'take' model are being tested in the cut and thrust of commercial realities. What's different and what's not different in this case, compared to others we have seen this year and last? In many of the so-called 'license-switching' cases that have been polarizing the open source world of late, similar themes have been heard to those being expressed by Matt Mullenberg founder of the WordPress project and which we understand in the following terms: 🔸 free-riding by downstream providers; 🔸 disproportionate revenue generation of those building a business model on top of open source; 🔸 insufficient contribution back to the OSS project; 🔸 uncertainties amongst the platform developers and users In this case, there is no license change bait and switch element involved. Nevertheless, disruption, uncertainty, confusion and frustration has been very much in evidence not only for the respective employees of the two companies but also for the WordPress developer community, the WordPress eco-system and the wider open source community. So what is different? 🔸 the underlying WordPress license is GPL, a copyleft license, which of itself raises interesting questions; 🔸 the thrust of the dispute is around the licensing of the WordPress trademark(s), which introduces various subsidiary questions around trademark policy, license negotiation tactics, available defenses, royalty rates etc. We will be following this case closely. For now let's simply observe that: Both those involved with creating Open Source software and those wishing to exploit it, should remember that it's not only the code and the copyright license that you need to be concerned about. #OpenSource #OSS #trademarks #copyright #licensing #IP #strategy Image credit goes to: Sunny Deb Nath

The amazing OSS code: seemingly infinite COMBINATIONS are possible, but only some stand the test of legal compatibility Imagine you're building a really awesome spaceship. 🚀 You use some instructions you found online for a cool engine, some other instructions for the cockpit, and some more for the wings. These instructions tell you what you can and can't do with the designs. Some instructions say, "If you use my engine design, you have to share the instructions for your whole spaceship with everyone!" Others say, "Use my cockpit design however you want, just mention my name." The problem comes when you try to combine parts with different instructions. If you use a "share everything" engine and a "just mention me" cockpit, you've got a problem! You can't share everything and keep some parts secret. That's license incompatibility. Open Source Software (OSS) is amazingly powerful! It lets developers build incredible things by sharing and reusing code. But mixing different OSS licenses can be like mixing oil and water – they just don't always work together, leading to what we call "license incompatibility." This happens because different OSS licenses have different rules. Some licenses, like the GPL, are "copyleft," meaning if you use its code, you have to share your modifications under the same license. Other licenses, like the MIT license, are much more permissive, allowing you to use and modify the code with fewer conditions. 👆 Problems arise when you try to combine code with conflicting provisions – imagine trying to follow both simultaneously! It's like trying to wear two different shoes on the same foot. 👉 Common pitfalls include accidentally using GPL-licensed code in a development project you intend to keep private, mistakenly believing you can bypass the GPL by simply linking to it in a way that would trigger the copyleft effect, or assuming that all open-source licenses are basically the same. 👉 Another big mistake is not keeping good records of which licenses apply to which bits of code in your project. This can cause huge headaches later, making it difficult to determine what you're allowed to do with your own software. Keep in mind, just because a tool tells you that a license is “open source” doesn't mean it's compatible with others you are using. So, how does your company avoid these issues? #opensource #combinations #incompatibility #risk #compliance Image credit goes to: EyeEm Mobile GmbH

Use of Open Source and Open AI in Academia: In this article we identify what some of the burning questions around this topic are - enjoy! #Opensource #OpenAI #AI #academia https://lnkd.in/gGAf-wQ6