Date
1 - 3 of 3
OpenChain Global Work Team Meeting - 2021 -11-22 (Today) @ 14:00 UTC / 06:00 PST / 15:00 CET / 19:30 IST / 22:00 CST / 23:00 KST + JST
Our regular global work team meeting takes place in one hour.
Our first playbook (for Medium Companies) is done. Now seeking final comments before preparing for publication. The OpenChain Playbooks - Medium Company - Final Review: https://docs.google.com/document/d/1GK0-d5vy_mN8gzAuS5XQ6vYM8_BePvO088WYV0eRF7M/edit#heading=h.7i5u45phff9 Dial in https://zoom.us/j/4377592799 Not sure of your time? OpenChain Global Work Team Meeting - 2021 -11-22 (Today) @ 14:00 UTC / 06:00 PST / 15:00 CET / 19:30 IST / 22:00 CST / 23:00 KST + JST
|
|
Dear Shane,
Thanks for leading the interesting discussion today; sorry for having to leave early. During the meeting, my parents called me to ask if - A: I knew what AnyDesk was, and B: why 'Amazon Customer Support' wanted them to install it! All danger was averted, I am glad to say. It's always good to share links about complex topics such as license compatibility, as search engines are unfortunately not wont to promote miscellaneous YAML files on GitHub! As for the topic of whether OpenChain should be linking to license compatibility information, I take the view that false negatives are safer than false positives here. Compatibility information, even if not 100% correct, can still be useful for instance to quickly flag up issues such as combining code under the CDDL with (GPL'ed) Linux. For a company which would like to avoid risk, it's perfectly acceptable to automatically reject any such 'incompatible' combinations whilst taking the 'compatible' combinations with a grain of salt. However, in the case of Canonical with ZFS [1], if there are no reasonable alternatives for a certain piece of software, the company can still spend time to manually review the license compatibility for their own use-case. When it comes to companies with more of a software development focus, then using tools such as the OSS Review Toolkit with the DoubleOpen machine-readable information that we discussed could be very useful. Even if not a substitute for specific legal review, it can be very good to produce noisy warnings in the CI/CD system when an upstream software dependency changes its license to something incompatible, which does happen now and then [2]. Again, this is using the information as more of a source of warnings rather than a source of truth. Hope this helps, and I look forward to seeing the playbook be published! :) Best wishes, Sebastian 1: https://ubuntu.com/blog/zfs-licensing-and-linux 2: https://www.theregister.com/2021/03/25/ruby_rails_code/
|
|
Thanks Sebastian! Very useful input.
toggle quoted messageShow quoted text
I concur that more information and knowledge is more helpful than less. Our only balancing act is to provide it without anyone thinking the OpenChain Project endorses X interpretation of a license. Have several sources and a disclaimer covers a lot (or all) of this ground. Regards Shane Shane Coughlan OpenChain General Manager +818040358083 Book a meeting: https://meetings.hubspot.com/scoughlan
On Nov 23, 2021, at 0:21, Sebastian Crane <seabass-labrax@gmx.com> wrote:
|
|