MasterOSS

Here are some predictions about where Open Source is heading in 2025: 1. ????Greater focus on the reputation-building opportunities of OSS across the academic sector. 2. ?? Realization that Gen AI deployment and development for commercial use cases ,must be controlled and managed, regardless of the designated model license. 3. ?? A bold re-visioning of the 'open core' concept, restoring the balance between freedom and reciprocity in the Everything-as-a-Service era. 4. ?? Further rapid evolution of the SCA and Vulnerability Scanning industry against the backdrop of the continuing rise in both the proportion of OSS consumed and the percentage increase in components with known vulnerabilities. Do these things ring true for you? What else may be in the offing? #OSS #GenAI #Academia #opencore #SCA #vulnerabilities

OPEN SOURCE software and PATENTABLE INNOVATIONS When incorporating OSS into the R&D process, several risks can impact the patentability of the resulting innovations. ?? The “Copyleft effect” risk: Certain OSS licenses, particularly copyleft licenses like the GNU General Public License (GPL), require that any derivative works be distributed under the same license terms. This can compel the disclosure of source code and potentially undermine the exclusivity required for patent protection. ?? The “Public Disclosure” Risk: OSS is publicly available, which means it can be considered prior art. If the OSS or its functionalities are already known, this can affect the novelty and non-obviousness criteria required for patentability. ?? Risk 3 ”Integration and Dependency Issues”: Innovations that rely on OSS may face challenges in demonstrating the inventive step or non-obviousness if the OSS is seen as providing a significant portion of the functionality. ?? The “Patent Exhaustion and Licensing Restrictions” Risk: Some OSS licenses may include clauses that affect the ability to enforce patents on innovations derived from the OSS. This can limit the scope of patent protection and enforcement. If you have been running into some issues or questions around these topics, then it is time for a pulse check: Is your company's level of understanding well-rounded enough to fully exploiting OSS benefits in R&D while at the same time mitigating OSS specific risks to protect the patentability of its innovations and R&D investments? #opensource #IP #patents #innovation #riskmitigation Image: William_Potter

3 things to know about OPEN SOURCE Software and STANDARDS. It's easy to fall into the trap of making generalizations when it comes to OSS and technical standards. Certainly, they have their areas of overlap but this can also lead to misconceptions and false assumptions. ?? Standards for AI and Generative LLMs A fundamental benefit of OSS is transparency of source for research and testing purposes but it seems that so far this has not resulted in too much effort directed to creating technical standards. Standards work is happening both at US domestic level (via NIST) and internationally with ISO/IEC 42001but the focus is on ethical issues, governance and AI management. Technical standards are typically driven by the user base, and the users are still busy trying to figure out what they want. ?? Competing standards One might think that competing standards are a unique phenomenon of the proprietary world, where rival consortia work to consolidate their advantage in the wider industry. Surely the ethos of collaboration and the economics of broad public acceptance militates against the possibility of competing OSS standards. Not always it seems. Take for example OSS tools for creation and management of Software Bills of Materials . Life would surely be simpler for all if there was only one standard addressing formatting of SBOMs, yet there are at least two well-entrenched industry leaders in this niche domain. Navigating incompatibilities between them can be a major headache for users. ?? Standard creation as a driver for OSS projects Many OSS projects adopt a governance model , structure and license strategy that reflects the need for a ubiquitous technical standard. Examples may be found across the spectrum from specialty libraries to highly-customizable infrastructure stacks such as Kubernetes. However, de facto standard creation is by no means the focus for all OSS projects. For example,think of projects based on programming languages like Python and Rust. #OSS #standards #GenAI #SBOM #governance #license #strategy Image: Yahrir Maulana

The IMPACT of Open Source in R&D Collaborations between Academia and Industry ?? R&D COLLABORATIONS between US universities and industry partners in the area of software development are crucial. These partnerships combine academic innovation with market-driven industry focus. Open source software (OSS) is not necessarily always central to these collaborations but it is very likely becoming more and more a critical part of it. ?? OPEN SOURCE presents both opportunities and challenges for each of the collaboration partners, especially regarding intellectual property (IP) rights and commercial exploitation of collaboration results: ? ?? UNIVERSITIES engage in industry collaborations primarily to advance knowledge and innovation. OSS has the potential to accelerate research and foster R&D in a collaboration setting. However, universities have to navigate their expectations related to IP rights carefully to protect their academic interests and achieve their objectives. While OSS licenses allow free use and modification of OSS, universities often seek to retain some IP rights for academic recognition and potential revenue. Collaborations including OSS would have to balance open access to results with the ability to still patent or commercialize innovations. Publishing research findings is also a priority to enhance their reputation. ? ?? INDUSTRY PARTNERS aim to develop competitive, market-ready products. Collaborating with universities provides access to cutting-edge research and talent. OSS reduces development costs and time-to-market by leveraging existing software frameworks and this is an important factor for them. However, industry partners are as well protective of IP in R&D results, as it impacts their competitive advantage and profitability. They may seek exclusive rights to commercialize results or negotiate joint ownership of IP. Protecting proprietary elements while considering OSS license implications would the therefore crucial. ? ?? SUCCESSFUL collaborations including OSS will require clear agreements on Open Source software use, IP rights, publication policies, and each side’s exploitation strategies. Collaboration terms will have to respect the open nature of OSS in terms of its use and distribution while at the same time safeguarding proprietary innovations and the parties interests. Hybrid licensing models, where certain components remain open source but specific applications or core components are proprietary, can be one solution. ? WHETHER OR NOT the parties can achieve their individual objectives, while driving innovation and creating impactful software based solutions "including OSS" will strongly depend on their depth and breath of understanding related to the opportunities OSS is bringing to the collaboration at hand and know how to use those for a mutual benefit. #OpenSource #OSS #industry #academia #research #collaboration #IP Image: Roberto

What is an Open Source LICENSE? Everyone thinks they know the answer to this question: ? It's a means of providing transparency by ensuring that 'source code' is released or made available to the downstream user and commercial distributor so that they can use the program freely for whatever purpose they wish. ? It's a means by which everybody is guaranteed the same rights and the same restrictions, i.e. those included in the license, no more and no less. While more or less true, these statements don't tell the complete story. ???? Lawyers may give you a slightly different perspective. For them, an Open Source License is essentially a form of copyright license, providing recipients with the right to do things with code (essentially a form of literary expression protected by copyright law) that they would not otherwise have the right to do. Right again. Now consider this question: what is an Open Source license NOT? Clumsy form of a question, but bear with us. An Open Source license is: ?? not a license to use any kind of trademark associated with the program's author or creator (think about the current WordPress lawsuits); ?? not, or at least not necessarily, a license to any patent that might be infringed by commercial use of the software program; ?? not a permission to copy, reproduce, modify or reproduce other copyright materials that may not consist of computer code (Creative Commons licenses perform this function but they are different from Open Source licenses accredited as such by the OSI). ?? not a license under any associated know-how of the program's author or creator (except to the extent such know-how is part of the published source code or source material (documentation) released with the program). Those looking to modify and commercialize Open Source programs in their product or service offerings should pay particular attention to these last points. Right now, everyone wants their own pet LLM or LLM agent. But remember: LLMs are "not just for Christmas". For those wanting to use "Open" or "Open Source" LLMs for commercial (rather than experimental) purposes, we can only urge that you apply an extra level of caution and look closely at all the small print. #OSS #License #OSI #Open #copyright #patent #trademark Image: BrianAJackson

OPEN SOURCE software in ACADEMIA IP Policies There are certain challenges universities face when trying to facilitate Open Source software friendly Intellectual Property and Licensing policies: ?? Focus on Profit: Prioritization of revenue generation over the sharing of technology or knowledge often complicates academic engagement in Open Source software initiatives. ?? Monetary Concerns:? Universities tend to require a financial return if someone exploits or builds on university work for profit. This can lead to more restrictive IP policies that hinder OSS contributions, OSS development or open collaborations. If no profit is anticipated, universities may support engagement with OSS but do rather little to drive or facilitate it. ?? Differentiation Between Software and Publications:? There is still a notable disparity in how universities perceive software (as a mere product with monetary value) versus publications or accreditations (as a measure of academic prestige). A balance between these two approaches is still often missing. ?? Resistance to Open Source:? There seems to be an ongoing tension regarding e.g. integrating open-source software into faculty research? work or marketing student engagement in OSS projects, with some institutions still viewing skeptically, while others recognize its potential for fostering reputation and funding. ?? Technology Transfer Models:? While many universities advocate for "Open Innovation," very few tech transfer offices actively engage in managing Open Source projects in part due to competing priorities and in part due to the complexity of such initiatives. Software, most especially OSS, is not as widely understood, much less supported by tech transfer offices.?There are many who are knowledgeable and supportive – just not the critical majority yet. ?? IP Policy Gaps:? Some universities' IP and licensing policies do not address open source, although they may be amenable to certain licenses (like BSD or MIT) that lack contractual patent grant implications. However, universities often reject the use of Apache 2.0 licensed software due to concerns over mandatory patent grant rights without considering the position of licensees, i.e. businesses interested in the software might prefer the patent protection of the Apache 2.0 for commercial use purposes. Universities will have to continue finding a balance between commercializing their IP and recognizing Open Source software as a legitimate and necessary part of academic work, industry collaboration and grant-funded projects, which should be reflected in their IP and licensing policies. This will help cultivate the idea of Open Source code as an important element of an academic ecosystem that brings reputation, prestige and funding to the University as well as profit. #opensource #IP #licensing #policies #university #techtransferoffice Image: Iurii Motov

Who wants to LEARN about OSS? It has been mentioned of late that the Open Source software development communities are getting older. More of the experienced so-called "grey beards" coming to the end of their careers and less of the young firebrands looking to make their name and acute enough to spot the next big thing. No doubt the industry needs both but the grey beards will have passed on before long, leaving a wealth of live projects to be maintained. Colleges and universities need to start introducing OSS into their curricula and facilitating early introduction of students into Open Source communities. Otherwise, they will be failing the next generation of IT entrepreneurs and society as a whole. Open Source is increasingly the way software is made these days. Apart from the coding itself, anyone considering a career in business, law, IT, industry or academia would do well to add a basic knowledge of OSS to their portfolio. #OSS #OpenSource #IT #business #academia Image: SergeyNivens

A unique alternative to?the Apple (SMART) WATCH, now available as an OSS PROJECT Have you ever wondered if there is an alternative to Apple Watches - not only an alternative but?one that is also open for modifications? ‘Open for modifications’ in terms of you as the user being able to - for example - customize the OS of your smartwatch to include some new features or to change up existing ones to your liking? Or maybe you are an OSS contributor and interested in exploring some of the core components of the OS of a smartwatch on the market? Well, Google has just released the OS of a new 'Pebble style’ smart watch. What's the background? Back in 2008, and by the way more than 5 years prior to Apple entering the market with the Apple watch in 2015, a tech start-up named Pebble, founded by Eric Migikovsky, had succeeded in inventing and bringing to market “Pebble Time”. With Pebble Time, the start-up created an entirely new product category, namely the smart watch.?The business failed and the founder sold Pebble’s software and IP to Fitbit in 2016. Following its acquisition of Fitbit, Google recently decided to release the Pebble Time OS as open source and is now calling for OSS contributions. The source code release is not only due to the Pebble founder’s influence, but also because of a still thriving and extensive user base and community behind Pebble and the potential Google sees in it to create a modern reboot of the original Pebble Time, based on Eric Migikovsky’s vision. The open-source code includes Pebble OS’s core components, responsible for features such as notifications, media controls, fitness tracking, and customizable apps and watch faces. A nice coding playground for both, techie?smart watch users as well as OSS contributors. Another great story demonstrating the tremendous potential of Open Source software to improve technology, enable business models and enhance user experience. #opensource #OSScontribution #IP #technology #smartwatch #UX https://lnkd.in/guh4BhzV

After 7 years it's still the LICENSE that counts most. According to the Open Source Survey report recently issued by GitHub, not a lot has changed since the first such survey in 2017 in terms of the ranking of factors that are considered important by developers who are either: ?? using OSS in their work; or ?? contributing to OSS projects. Active development and responsive maintainers are still the most important factors for the largest percentage of respondents in 2024, although less so than in 2017. A new priority has arisen in the meantime that is evidently of importance to both groups, namely #security by #design. This is not in the least surprising of course. It also has as a corollary the statistic that >80% of respondents say that their employer is either accepting or encouraging as to the use of #OSS #dependencies in their codebases. What is perhaps a little more surprising is the continued emphasis on the importance of the license. Whether we are talking about using or contributing, the percentage of respondents considering that "an Open Source license is very important to have" remains higher than the other factors. Of course, statistics can be misleading and can be used deliberately to build or support a particular narrative, but at a time when many are questioning whether more weight should be given to topics like ?? #governance, ?? #influence over the project road map and ?? #scope for #contribution, it is revealing that the license remains paramount...for now. All the more reason for caution when dealing with so-called "open" or "open source" LLMs. The license may very well not be an Open Source license. https://lnkd.in/gx6687wt Image: olm26250

OPEN SOURCE is inevitably becoming an equally important puzzle piece in the AUTOMOTIVE Industry ?? ?? ?? ?? ?? Our cars are transforming more and more into so-called Software Defined Vehicles (SDVs). Software defined in the context of an automotive vehicle does not only mean that the amount of software in vehicles is vastly and rapidly increasing, it also means that software architecture(s) is(are) the way of managing hardware resources (such as e.g. powertrain, suspension) using software instead of traditional hardware. And with that, the vehicle’s functionality and features are no longer defined by (solely) hardware engineering but rather predominantly by software and systems engineering. Put differently, software is not only coming from various different suppliers in the traditional automotive arena but also from different industries, plus, it defines technically "everything" in a vehicle on all the various vehicle levels (i.e. the OEM level, the component supply level of Tier 1s and Tier 2s, as well as all the non-automotive supplier levels (the cloud providers, mobile apps providers etc.). As such, software becomes the fundamental part of a vehicle and transforming it into a software defined "system". Where there is software there is also Open Source Software, even (or maybe better: especially) in a SDV. ?? ?? Embarking on the OSS path it is still a very new approach for the entire automotive industry, especially when it comes to integrating OSS within the deeper embedded software layers of a vehicle, those which were originally strictly operated with proprietary software. The decision to exploit OSS in SDVs has been made. Relevant collaboration has begun and is being expressed in various OSS projects around SDVs, such as for example projects coming out of the Eclipse Foundation SDV Working Group or out of SOAFEE. ?? With the choice of OSS comes the responsibility and commitment for all automotive players in the supply chain to gear up not only in the area of gaining OSS knowledge but also in terms of readiness for a mindset change, especially when it comes to open collaboration and open innovation. It will be for sure a new adventure for everyone involved including many opportunities as well as challenges that will require bold decisions, determination?and ideas. ?? ?? Including OSS will certainly not only enhance the evolution of vehicles, it will also provide new and exciting business opportunities for the entire industry. #opensource #automotive #sdv #opencollaboration #innovation