Open-source News

New Banana Pi SBCs slim down for low-power IoT  LinuxGizmos.com

UbuntuDDE Beta: A Linux Remix That Lifts User Experience to the Next Level  TechNewsWorld

UbuntuDDE Beta: A Linux Remix That Lifts User Experience to the Next Level  LinuxInsider.com

Wine 5.7 is out as the newest bi-weekly development release and it's a fun one with multiple interesting advancements...

Wine 5.7 Released With More Progress On D3D Vulkan Backend, USB Device Driver  Phoronix

A new Linux Foundation whitepaper seeks to uncover the complexities of open source licensing implications when distributing and deploying Docker containers. Introduction

Deployment, distribution, and execution of software and especially services have significantly changed in the last few years. A few years ago, a person had to install a Linux based OS distribution with the necessary software and dependencies — these days, it is now much more common to “spin up a Docker container” and run a service. 

A container is basically nothing more than one or more applications with all dependencies, data, and configuration in a single isolated environment that can be deployed without the need to buy a new system or create a virtual machine. Containers allow services to be isolated from each other and require far fewer resources from a virtual machine, so they are becoming extremely popular in extremely dense multi-tenant hosting environments run by hyper-scale cloud providers, such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud.

Docker has had a significant impact on the popularity of containers and has made it much simpler on the technological side of things, but on the legal side, there are potentially increased complexities. For example, using containers makes it easier for developers to deploy software, but it also makes it easier to deploy (sometimes inadvertently) the wrong thing. Docker containers hide many of the implementation details, and developers might end up unknowingly shipping all kinds of software without knowing the license compliance issues that occur as a result. 

The Linux Foundation has recently published a whitepaper by Armijn Hemel that seeks to uncover the complexities of open source licensing implications when distributing and deploying Docker containers — it can be downloaded here. This blog post is a summary of the general findings.

Containers and images: what’s the difference?

In articles and documentation about Docker, there are frequent references to “containers” and “images.” These are not the same, although sometimes used interchangeably in articles or conversations. There is a very fundamental difference: an image is the on-disk collection of software, while a container is a running instance of an image, together with run time data and run-time state.

An example image could contain the Apache webserver and all its dependencies, from which a container can be instantiated and run. An image can be instantiated multiple times: these would then all become separate containers. 

Figure 1. A Docker image instantiated into multiple containers.

Images can be made available for reuse in public or private repositories, where they can be searched for and downloaded to be reused.

Each Docker image consists of one or multiple layers that are stacked on top of each other. Some of the layers contain files (programs, files, etcetera); others are meta-layers modifying existing layers. Different images can, and often do, share layers. For example, if two images are both based on a specific Debian layer, then this layer will only be stored on disk once.

If an existing image is reused (for example: downloaded from a repository) and modifications are made, then these modifications are stored as one or more separate layers on top of the existing layers in the image. All the layers of the base image and the new layer with the modifications together form a new image that can be instantiated (to create a container) or exported to be distributed or made available in a repository. A Docker image could be as pictured below, for example, a base image with four base layers (building on top of each other), and a custom layer on top. 

Figure 2. A base image with four base layers with a custom layer on top.

Understanding licensing complexities of layers within containers

When attempting to understand the license implications of software stored within a Docker image, it is essential to realize that the image that users interact with is simply a view of all layers, and during run-time, only the final view is seen. This view will possibly not show all of the software that is inside all of the layers: each layer can modify the view, but it will not change the content stored in any of the underlying layers.

 

Figure 3. A Composite view of a Docker image.

It could be that one layer installs software, and a new layer overwrites the software with another version (possibly with another version under a different license). In the final view, users see that the older software seems to have been removed, but in the underlying layer, the original software will still be present. For example, with the representation of a container image shown above, a user of the image would only “see” the following:

Figure 4. End-user representation of a container image.

However, when the image is distributed, all files from all layers will be distributed: each of A through H, and also modified files B’ and C’.

If a complete image is shipped, then the license conditions for software in all layers apply, even if, in the final view, software in some of the layers can no longer be seen. This means that for compliance with a full image, every layer that is inside the image should be checked.

An extra complexity could be linking. If a component is linked with other components in a layer and components get overwritten with other versions under a different license, then the license implications might be different depending on which layer is examined.

Docker repositories, registries and the potential for licensing misinterpretation

Docker images can be retrieved from repositories. Apart from the docker.io repository (run by Docker), there are also other repositories, such as quay.io, which is run by Red Hat. Community projects such as Fedora and CentOS also have public repositories, and there are many running their private repositories of Docker images.

In addition to full images being retrieved from repositories, Docker can also build images in a “just in time” fashion where instead of a full disk image or container image only a “recipe” to assemble a container image is provided using a Dockerfile.

The software is assembled on the fly from a base image that is downloaded from a repository, or that is available on the local system, with possibly extra software being installed from (other) upstream sources, like installing updates from a Linux distribution.

An example is a recipe that defines that the base image is based on a specific version of Ubuntu Linux, with updates being pulled from the Ubuntu update servers and then having a proprietary program installed from a local server.

The recipes, such as a Dockerfile, can be stacked and depend on other recipe files. These recipe files are typically stored in local files or registries that can be searched.

The recipes used for assembling the images are sometimes released under licenses that are different than the actual software being aggregated (which is perfectly fine), and there is a real chance that people will misinterpret this information and think that the licenses of the Dockerfile files apply to the assembled image, which is incorrect.

Misinterpretation of license provenance within a container image is not an imaginary problem as something similar happened in a non-containerized context in the past with Android, of which large parts have been released under Apache 2. This license confusion led some people to believe that all of Android had been released under Apache 2, even though there were significant portions of Android released under GPL-2.0 (Linux kernel, iptables, etc.) and various versions of the LGPL license.

Who distributes the software?

From a compliance point of view, there is a big difference between distributing an image that has already been fully created (and when all the software is included in the image) and distributing a Dockerfile that only describes how the image should be built. In the former case, the software is distributed in binary form, while in the latter form, possibly only a recipe for constructing an image is distributed.

When a complete image is distributed, only one party is doing distribution of the image — the party sending the built image out the door.  However, when a Dockerfile (the recipe) is distributed, then when the end-user builds the image, it is assembled on the fly with software possibly being pulled from various places.  In this scenario, it means distribution is possibly done by several parties, because (e.g.) each layer could come from a different third party. One layer could be distributed by the party operating an image repository, with content in another layer coming from a distribution (example: distribution updates), and content in another layer coming from yet another party (custom download location).

The license of dockerfiles vs. software inside containers

The Dockerfile files can be licensed under an open source license themselves. It is vital to realize that the scope of this license statement is only the Dockerfile and not the container image.

For example, the Dockerfile itself can be licensed under the MIT license but describing the installation of GPL licensed software. In a typical use case, the license of the Dockerfile and the license of the described software are entirely independent.

Compliance for all layers, not just the final layer

When distributing an image, typically, multiple layers are included and distributed. As these layers are stacked on top of each other, it could be that the contents of one layer obscure the contents of the other layers. From a pure license point of view, the final view does not matter: what matters is what is distributed. It could be that one version of an open source licensed program is distributed in one layer, with another version of the same program distributed in another layer. In this case, the license conditions for both versions need to be met.

Also, to be safe, one should not rely on the fact that specific layers of their image may already exist at the destination or in the repository receiving the push, and that therefore they will not distribute the software for those layers.  At some point, that container will land in a place where none of the layers are pre-existing, so all layers of the image must be provided to the recipient, and one will have to comply with distribution obligations for each layer provided.

How do we collect and publish the required source code?

An open question is how to collect complete and corresponding source code for containers with software under licenses that require complete and corresponding source code. With the current Docker infrastructure, it is not possible to automatically gather and publish the required source code. This means that extra work needs to be done (either manual or scripted) to gather the right source code, store it, and make it available. There are a few complications:

1. Creating a Docker image is not reproducible but depends on configurations. If different configuration options are chosen every time a Docker image is created, the resulting image could be different. This means that gathering source code at a later time than image creation might not yield the corresponding source code for the image created earlier.
2. Layers can be composed at different times and source code for some layers might have disappeared.
3. Source code might need to be gathered from various places. Focusing on just system packages could lead to missing packages.
4. Gathering source code needs to be done for all layers.

This is currently an unsolved problem.

A checklist for Docker license compliance

The following section is a compliance checklist that should help companies distributing containers to understand the license obligations better.

Is any software distributed?

The first question to ask is: is any software distributed at all? If the only thing that is distributed is a Dockerfile recipe that needs to be instantiated by the user, and software gets pulled from repositories and the company publishing the Dockerfile does not run the repository and also did not push (base) images that are used in that Dockerfile into that repository, then the company is likely not distributing any software other than the Dockerfile itself. This would require a thorough investigation of the used Dockerfile files and the build process.

What software is distributed?

Knowing which software is shipped and what license this software is under requires analyzing the software in all layers of the container image, not just the final (assembled) layer that is presented to the user. The software might have been hidden from view in the final layer, so a full analysis of all layers is necessary.

How is the software distributed?

Depending on how the software is distributed (as a full image, Dockerfile, etc.), different parties might be responsible for fulfilling license obligations. 

Who is distributing the software?

If you are distributing the container as a whole, then you are responsible for license compliance for all of the software it contains. By contrast, if you are distributing just a Dockerfile which tells people how to build a container, and the recipients are then using your Dockerfile to obtain container layers from third-party locations, then you are perhaps not responsible for license compliance for that software. 

Conclusion

Docker has made the quick deployment of software much simpler, but also introduces a few legal challenges. What the solutions to some of these legal challenges are is currently not clear. 

Evaluating compliance challenges requires a basic understanding of the technical specifics of how containers work and how they are built. With this understanding, it becomes evident how the distribution of containers bears some similarities to more historical means of distributing software while making clearer the aspects that can be obscured.

In our original whitepaper, which will hopefully serve as a starting point for discussions to what the solutions should be, the following challenges were identified:

1. There are different types of distribution and depending on which form of distribution is chosen you might or might not have an obligation to distribute corresponding source code. It is not yet obvious to casual users when or if obligations are present.
2. The Docker tools and ecosystem currently do not make it easy to collect complete and corresponding source code and are focused purely on assembling container images and deploying containers.
3. Because of the layered approach of Docker and only making the final layer visible it is easy to overlook possible distribution of software. A thorough analysis of what is distributed using tools (such as Tern) is necessary in those cases.

Future opportunities to improve the compliance environment for containers should likely focus on further developing tooling and processes that can collect and publish the corresponding source code in a more automated fashion.

To download the “Docker Containers for Legal Professionals” whitepaper, click on the button below. Download whitepaper

The post Docker containers: What are the open source licensing considerations? appeared first on The Linux Foundation.

While there has been the CPU-based "Kazan" Vulkan driver (formerly Vulkan-CPU as a Google Summer of Code project) and Google's SwiftShader has been implementing CPU-based Vulkan support, it turns out Red Hat's David Airlie has been working on a Mesa/Gallium3D-inspired Vulkan software renderer...

Docker Containers for Legal Professionals

Docker has had a significant impact on the popularity of containers and has made it much simpler on the technological side of things, but on the legal side, there are potentially increased complexities.

A whitepaper that seeks to uncover the complexities of open source licensing implications when distributing and deploying Docker containers.

Containers make it easier for developers to deploy software, but it also makes it easier to deploy (sometimes inadvertently) the wrong thing. Docker containers hide many of the implementation details, and developers might end up unknowingly shipping all kinds of software without knowing the license compliance issues that occur as a result.

Author: Armijn Hemel, MSc. Download Now

The post Docker Containers for Legal Professionals appeared first on The Linux Foundation.

NVIDIA has released their latest weekly-ish beta update to their Vulkan Linux driver...

NVIDIA 440.66.11 Linux Driver Fixes Annoying Bugs With PRIME Sync  Phoronix

Edge AI mini-PC spins up Nvidia's Xavier NX  LinuxGizmos.com

Edge AI mini-PC spins up Nvidia's Xavier NX  LinuxGizmos.com

Intel FSGSBASE Linux Support Revived For A Performance Boost On Intel/AMD Processors  Phoronix

Earlier this month I reported that Linux developers were reviving work on the Intel FSGSBASE patches as a performance helper going back to Ivy Bridge CPUs but for which past patch series never got over the finish line for mainlining. On Thursday a new version of the FSGSBASE patches were sent out...

Virtual event suggestions for open source communities Introduction

With the COVID-19 pandemic affecting every aspect of life across every population and industry around the globe, numerous conferences, events, and meetings have been canceled or postponed. The Linux Foundation events team has been working in overdrive negotiating to cancel or postpone events that were or are impossible to operate this year safely. The health and safety of our communities and staff is our top concern.

The good news is that for those events that can no longer safely take place in person, virtual events still offer the opportunity to connect within our communities to share valuable information and collaborate. While not as powerful as a face-to-face gathering, a variety of virtual event platforms available today offer a plethora of features that can get us as close as possible to those invaluable in-person experiences. Thanks to our community members, we’ve received suggestions for platforms and services that the events team has spent the past several weeks evaluating. 

After researching a large number of possibilities over the last few weeks, the Linux Foundation has identified four virtual event platforms (and a small-scale developer meeting tool) that could serve the variety of needs within our diverse project communities. Our goal was to determine the best options that capture as much of the real-world experience as we can in a virtual environment for virtual gatherings ranging from large to small. After evaluating 86 virtual event platforms, and in the spirit of contributing back, we thought we would share what we learned.

Below is the shortlist of platforms we’ve identified for our potential use, based on which offered features that best replicate our in-person events of different sizes. We’re sharing our findings because these learnings might be a good fit for others in our community, or perhaps save you time looking at options. If you’re evaluating any platform, be prepared to spend a few weeks getting conversations started with salespeople, viewing demos, obtaining pricing, and negotiating features.

Why we chose the platforms listed

There are many virtual conferencing solutions offered in the market today. Each solution varies on price, features, scalability, and technology integration points. The list of every single platform and software solution we looked at, including open source-based solutions, can be viewed here. One of these other solutions might be a better fit for your organization’s needs. 

Finding a virtual event platform, however, is also just one piece of the virtual event puzzle. How you plan, structure, and execute the virtual event will be critical to achieving a successful community engagement. We stumbled across this great Guide to Best Practices for Virtual Conferences put together by the ACM Presidential Task Force, which we thought provided some great practitioner tips for communities running virtual events. 

Our goal was to find solutions for our events team that met the following three requirements: 

• • The ability to deliver the required content
  • The ability for attendees to network and collaborate with each other
  • The ability to deliver sponsor benefits in the platform for those companies supporting these events financially

Due to these requirements, we did not focus as much on web conference solutions, such as the now popular Zoom. However, if you are looking for a simple web solution, many of the typical web conferencing platforms are easy, quick options to set up a small virtual gathering. In many cases, you might not need all the features of the virtual events platforms.

There are even some wonderful open source options out there including:

• • Jitsi Meet, which has some very useful features like streaming, screen sharing tabs, sharing videos, and more that are not found in other solutions.
  • Open Broadcaster Software if you’re looking to record and stream session content, which can also be usefully paired with conferencing tools.
  • EtherPad, which many of our communities use and it’s exciting to see that there’s also video support to connect and talk while editing.
  • Big Blue Button that’s designed for teachers and students, but open source for anyone to use (and we know many of you have kids at home and might find this useful).

Linux Foundation virtual event platform shortlist

These tools are designed for medium to large events with multiple concurrent tracks, in-depth attendee networking and collaboration needs, and robust sponsor requirements. The pricing for each of these will depend on the specific event details, such as number of conference tracks, the number of chat rooms/attendee collaboration spaces, length of the event, number of attendees, and number of sponsor booths.

All of these event platforms (with the exception of QiQo Chat) have all the following standard functionality:

• • Web-based (HTML5) supporting Linux desktops/browsers (and also Windows and Mac)
  • Registration integrations that will comply with GDPR and privacy regulation requirements
  • Webhooks or REST APIs to integrate with security systems like SSO (Auth0) and SFDC.
  • Can be white labeled for your community’s event branding
  • Speaker Q&A chat available within sessions
  • Attendee networking capabilities
  • Integrated scheduling tools and agenda builder
  • Attendee analytics: booths visited, session attendance, etc.
  • Gamification options to drive attendee engagement
  • Pop-up notifications throughout the platform (‘Keynotes starting in 5 minutes!’, ‘Visit [Sponsor’s] booth’)
  • Guaranteed uptime, redundancies and autoscaling

inXpo Intrado Best for large events with high budgets requiring a virtual conference experience with few compromises.

InXpo Intrado has robust hosting capabilities and uses hyper-scale cloud providers for its infrastructure to provide highly reliable and resilient performance. The company uses its own platform for session broadcast and integrates with third-party CRM and registration platforms. It offers 3D virtual environments throughout the platform as well as robust attendee networking options and sponsor benefits, including virtual booths. 

Benefits:

• • Extremely customizable, very immersive event experience. 3D environments & virtual booths (VR representation of physical world exhibit hall that looks like a video game)
  • A good user interface for attendees to access all content
  • No limit on concurrent sessions or live sessions so you will not have to worry about maxing out session/attendee capacities on this platform
  • The solution provider uses its own network infrastructure backbone that is fault-tolerant enough to support 98% of 911 call centers in the US
  • Real-time translation and closed captioning capabilities without requiring third-party platforms or plugins
  • Works from within China — used by Chinese companies to run in-country virtual events
  • Extra layer of attendee privacy protection with optional ‘pop up’ message for attendees to confirm before sponsors can gather any information about the attendee

Additional Considerations:

• • One of the most expensive platforms we evaluated
  • Potential longer turnaround time needed for event onboarding and setup
  • Sponsor booth templates are customizable for a fee
  • Does not allow you to plug in your own open source video streaming/video conferencing solution

vFAIRS Best for medium to large events with smaller budgets that want to offer a 3D environment/booth experience.

vFAIRS is more appropriate for medium or large events. It has many of the same robust features for sponsors, virtual trade shows, concurrent sessions, and attendee networking features that InXpo Intrado does, but at a lower cost of entry. While it does not have its own built-in session broadcasting platform, they do have Zoom integration built-in, and you can choose to use other video streaming solutions as well. They also offer integration with numerous CRM and registration platforms.

Benefits:

• • Highly customizable
  • Great sponsor exposure and look and feel with customizable booths (dozens of templates available)
  • Attendee networking lounges and chat rooms 
  • Works from within China
  • Built-in web content accessibility — participants can change colors and font size to ease accessibility
  • Ability to incorporate closed captioning via a 3rd party solution
  • Flexibility on video broadcasting systems

Additional Considerations:

• • The lower price tag comes with more limited support than InXpo (the company is based in Toronto with many staff overseas)
  • External infrastructure dependencies (vs all-in with InXpo)
  • Capacity constraints for larger live sessions (4,000 max)
  • While the pricing is more competitive, the price increases with additional booths and/or additional sessions

MeetingPlay Best for any size event where attendee networking tools are a priority and sponsor ‘booths’ aren’t required.

This platform can accommodate events of all sizes but does not have a 3D virtual exhibit hall/booth capability. That said, the sponsor benefits built into this platform are robust, and they have excellent attendee networking capabilities. As with vFAIRS, you can use Meeting Play’s own integrated video conferencing solution for content delivery, or use your own. 

Benefits:

• • Heavy focus on “attendee” experience
  • AI-driven content, chat room and attendee suggestions — based on initial questions you can customize and ask of all participants
  • Allow for gated content with in-app registration upgrade options (freemium model) similar to offering a free “hall pass” and then requiring a higher registration to attend sessions
  • Sponsor pages are very robust offering sponsors the ability to chat 1:1 with attendees, show videos/demos, sharing resources, and more
  • Option to use MeetingPlay integrated video streaming solution, or the one of your choice via your own account
  • Works from within China — they support a number of customers in China and have virtual machines in-country that they use to test before going live for an event

Additional Considerations:

• • No 3D virtual exhibit hall or booth — sponsors receive a dynamic page that allows for real-time chat with attendees, downloadable resources, and a video player for demos or welcome videos
  • Looks more like a website rather than a virtual event
  • Only 2 concurrent live sessions at a time w/out additional fee. They recommend pre-recording most sessions and playing “simulive” (meaning it is played at a specific time, and speakers join real-time to do a text-based Q&A.) The platform has a limit of 8 concurrent live sessions at any one time
  • Collaboration spaces (used for sponsor booths, attendee ‘meeting rooms’ and any live sessions that have multiple speakers or require a two-way communication) are charged by the hour and by the number of attendees, which makes using these freely a bit difficult

QiQo Chat QiQo is best for smaller technical gatherings that don’t need all the bells and whistles of an industry event focus. This is a great option for a focus on small group collaboration, such as developer meetings and hackathons.

QiQo acts as a Zoom wrapper for attendees collaboration and session broadcasting and is ideally suited for smaller events that have a more narrow focus, where communication and collaboration needs are more back and forth, versus one-way delivery. One unique feature of QiQo is it offers the ability to collaborate on Google Docs and Etherpad as both are both integrated into QiQo’s interface. 

Benefits:

• • Inexpensive
  • An affordable option for small meetings that only need an elevated video conferencing option for collaboration. Each live event on Qiqo comes with 10 Zoom breakout rooms by default
  • Great for small group collaboration in multiple workspaces – as a Zoom wrapper, it creates more of a virtual environment around an event with multiple breakout rooms for discussions
  • Includes a large number of built-in integrated tools for collaboration and productivity: Slack, Google Calendar, Google Docs, and Etherpad
  • While Zoom is their default, their support team will work with you to set this up with Jitsi or another video conferencing solution of your choice
  • Works from within China depending on webcasting platform availability

Additional Considerations:

• • Simple Zoom wrapper to add collaboration features on top of Zoom – can be used with other video conferencing tools as well
  • Very limited sponsor elements
  • A little more challenging interface and workflow than other options — a lot of options, but definitely let ‘out of the box’
  • Minimalistic approach for collaboration

Conferencing platform feature comparison Screenshots gallery

Conclusion

With over 40 events remaining this year under the Linux Foundation umbrella of events, we have several conferences that might go virtual. Each of these will have different requirements, so to support our diverse communities, we needed a range of options and features. We do think that this portfolio of options together meets most of our various community needs, and we hope you find value in us sharing them, along with the list of all the other platforms we examined. 

The post Virtual event suggestions for open source communities appeared first on The Linux Foundation.

Current trends in MS Office Alternative Software for Linux Market: Business Size| Strategies| Opportunities| Future Trends| Top Key Players| Market Share and Global Analysis by Forecast  Cole of Duty

Ubuntu 20.04 LTS is out  Ghacks Technology News

Rough, tough Coffee Lake system is totally upfront with its I/O  LinuxGizmos.com

Lenovo to begin selling some ThinkPad laptops with Fedora Linux  Liliputing

Radeon Software 20.10 vs. Upstream Linux AMD Radeon OpenGL / Vulkan Performance  Phoronix