OSSF Open Source Experience Sharing

OSSF Open Source Experience Sharing
TSID Next Focus: OSSF Open Source Experience Sharing 中央研究院　資訊科技創新研究中心　自由軟體鑄造場林誠夏　法政研究　　Profile: 葛冬梅　法政研究　　Profile: 本著作採用創用CC 「姓名標示－非商業性」授權條款台灣3.0版

個人簡介林誠夏 Lucien 2005年-自由開源軟體授權條款與商業模式研究自由軟體鑄造場法政研究 / 台灣創用CC計畫法律項目主持人
FOSS License, CC Licenses, Open Data Policy 「國際自由開源軟體法律參考書 (IFOSS Law Book)」台灣專章作者「政府資料開放授權條款－第1版」討論倡議人之一 at Linkedin at 2015/12/31

2015/12/31

法律源地 2015/12/31

法律源地常用連結法律小辭典自由軟體授權常見問答集自由軟體訴訟案件分析彙整法律政策發問討論區自由軟體授權條款介紹
法律小辭典　自由軟體授權常見問答集　自由軟體訴訟案件分析彙整　法律政策發問討論區　　自由軟體授權條款介紹　自由軟體授權條款分類表　自由軟體授權導引精靈v2.3　　自由軟體授權導引精靈v3.3　　 2015/12/31

大綱 1、自由軟體鑄造場單位服務介紹 2、自由開源軟體專案的授權特性 3、自由開源軟體與開放平台的產業動向
歷史(2003-now)，使用工具、網站介紹 2、自由開源軟體專案的授權特性自由開源軟體授權的三大分類 3、自由開源軟體與開放平台的產業動向給台灣企業的建議如何獲知各分類最新自由開源軟體專案的新星如何評估適合企業的自由開源軟體專案如何快速導入企業內部與之後的維運與管理業界的連絡支援 2015/12/31

一、自由軟體鑄造場單位服務介紹 2015/12/31

2015/12/31

重要開源訴訟案件分佈地域 7 24 （BusyBox8件） 2015/12/31

http://www. softwarefreedom
2015/12/31

2015/12/31

二、自由開源軟體專案的授權特性 2015/12/31

2015/12/31

自由研究、自由分享程式源碼(Source Code) 2015/12/31

六大特性開放程式源碼不限制授權對象與使用地域不收取授權金授權不可撤回不附隨擔保釋放四大自由予後手 2015/12/31

* ##/%% variable matching code ripped out of ash shell for code sharing
* This code is derived from software contributed to Berkeley by * Kenneth Almquist. * Licensed under GPLv2 or later, see file LICENSE in this source tree. * Copyright (c) 1989, 1991, 1993, 1994 * The Regents of the University of California. All rights reserved. * Copyright (c) Herbert Xu * was re-ported from NetBSD and debianized. */ #ifdef STANDALONE # include <stdbool.h> # include <stdio.h> # include <stdlib.h> # include <string.h> # include <unistd.h> # define FAST_FUNC /* nothing */ # define PUSH_AND_SET_FUNCTION_VISIBILITY_TO_HIDDEN /* nothing */ # define POP_SAVED_FUNCTION_VISIBILITY /* nothing */ #else # include "libbb.h" #endif #include <fnmatch.h> #include "match.h" char* FAST_FUNC scan_and_match(char *string, const char *pattern, unsigned flags) { char *loc; char *end; unsigned len = strlen(string); int early_exit; /* We can stop the scan early only if the string part * we are matching against is shrinking, and the pattern has * an unquoted "star" at the corresponding end. There are two cases. * Case 1: * "qwerty" does not match against pattern "*zy", * no point in trying to match "werty", "erty" etc: early_exit = (flags == (SCAN_MOVE_FROM_LEFT + SCAN_MATCH_RIGHT_HALF) && pattern[0] == '*'); if (flags & SCAN_MOVE_FROM_LEFT) { loc = string; end = string + len + 1; } else { loc = string + len; end = string - 1; if (flags == (SCAN_MOVE_FROM_RIGHT + SCAN_MATCH_LEFT_HALF)) { /* Case 2: * "qwerty" does not match against pattern "qz*", * no point in trying to match "qwert", "qwer" etc: const char *p = pattern + strlen(pattern); if (--p >= pattern && *p == '*') { early_exit = 1; while (--p >= pattern && *p == '\\') early_exit ^= 1; } 開放程式源碼此頁面程式碼擷取自BusyBox 的源碼檔案”match.c”，採用「GPL-2.0及其後續版本」來授權，利用程式碼請遵守授權規則，授權規則說明請見：程式碼下載： 2015/12/31

GPL類 → ✔ BSD類 → ∆ 2015/12/31

從開放源碼的理想到提供源碼的義務葛冬梅 2013/11/26
開放源碼（Open Source，註一）是現在許多人在接觸自由開源軟體時，第一個會接觸到的詞，它代表此類程式在散布時，皆能夠從散布者手上取得程式源碼。不過常見到的是，部份使用者會將這個詞，誤解為使用自由開源軟體所必須遵守的義務，認為一旦取得、持有自由開源軟體就必須主動公開手上所持有的程式源碼。其實開放源碼理想與提供源碼義務是兩個不同、但有所關聯的概念：開發者因為認同自由開源軟體理念，而主動公開其所撰寫的程式源碼，並授權給予他人來利用，所以他人才有機會以更深層的方式，利用到其所散布的自由開源軟體，這是屬於實踐開放源碼理想的過程；而當使用者取得自由開源軟體的程式源碼，部份條款要求其得在散布軟體的同時提供源碼給予後手，則是屬於履行授權義務的過程。本文以下將從自由軟體與四大自由談起，介紹相關的歷史背景與授權條款中提供源碼義務的內容，來說明開放源碼與提供源碼所代表的意義，以釐清兩個概念之間的關係。 2015/12/31

Repository Client 此圖下載於網際網路，其授權資訊如下，本次取用特別聲明在非商業性、學術推廣演講中主張「合理使用」，請讀者不要更行移置他用。Author: Iconshock; Homepage: License: Linkware; Commercial usage: Not allowed. 2015/12/31

https://developer.mozilla.org/en-US/
2015/12/31

限制　　授權對象授權時間授權範圍 2015/12/31

✘ 限制　　授權對象授權時間授權範圍 2015/12/31

　　程式碼→表現形式-著作權 ✘ 　　程式碼→發明技術-專利權 ✘ 2015/12/31

GPL-3.0專利授權規定 2015/12/31

BSD類條款+額外專利授權：WebM http://www.webmproject.org/license/additional/
2015/12/31

圖案、文字→商業信譽-商標權 ∆ 2015/12/31

商標權授權金→不影響軟體的自由利用與散布
將商標拿掉即可自由利用程式碼商標權授權金→不影響軟體的自由利用與散布 2015/12/31

授權金 ✘ 費用　 ✔ 2015/12/31

2015/12/31 2010 (CC) Yoni Lerner, "wonder dog" in CC BY 2.0 at

服務費、擔保費用、維護費、技術服務費用 2015/12/31

本照片採用創用CC「姓名標示-非商業性-相同方式分享」2. 0通用版授權，下載網址：http://www. flickr
2015/12/31

自由開源軟體不收取授權金之特性葛冬梅 2014-02-26
不收取授權金是自由開源軟體的一大特性，這其中牽涉到的智慧財產權種類包括了著作與專利兩類，雖然法律專欄在過去發表過許多相關的文章，不過都是屬於細部的分析，並未有統合性的介紹，也沒有對於這個特性形成的緣由加以說明，因此本文將針對這些過去所未說明過的部份進行統合性的介紹，同時針對常被併同提起的商標權加以說明，供想要深入了解自由開源授權特性與成因之讀者參考。【不收取著作權授權金的鐵律】一般介紹自由開源軟體的文章，開宗明義都會說明使用者可以直接自由使用、修改、重製與散布軟體，而這些使用者被允許利用軟體的行為，其實就是著作權法所付與軟體著作權人所專有的權利，只是自由開源軟體的著作權人事先透過授權條款的宣示，允許使用者可以直接利用軟體，並且承諾不會對使用者的這些行為收取權利金。若是使用者只能透過支付著作權授權金才能換取使用、修改、重製與散布軟體的權利，那麼這個軟體就不是自由開源軟體（註一）。 2015/12/31

商業利用自由開源軟體之商標須知林旅強 2013-06-25
第三方利用人將自由開源軟體專案（以下簡稱「專案」）運用於其商品或服務的開發及相關商業行為時，首要重視者即其利用方式是否合乎該專案之授權條款。所有 OSI 認證的授權條款對於著作權授權皆有規範，較新近的條款對於專利權授權亦多有規範（註一）。然而，不同於著作權及專利權，商標權在授權條款中若有明文者，皆明示其專案之智慧財產權之授權範圍不包含商標及相關標章和名稱；未於授權條款中規範者，亦等同未就商標進行授權。其原因是，商標權乃利用該商標於商品或服務的法定專用權，目的在於保護商標權人之品牌，使他人不能隨意攀附商譽，亦避免其品牌價值被其他劣質商品或服務所影響，或是品牌印象被淡化，而失卻其商標權之保護（註二）；同時，商標權亦旨在保障消費者對於該商品或服務之質量水平的信賴。因此，若利用人欲於其商品或服務中利用自由開源軟體，並會利用到該專案的名稱、商標或標識等，亦需注意利用方式必須符合該專案的商標政策或者合於商標法制規範，始得為之。 2015/12/31

自由散布事實上難以撤回 2015/12/31

GPL-3.0第2條第1項 2015/12/31

Apache-2.0第2、3條 2015/12/31

將條款升級機制融入授權條款中 – MPL-2.0 2015/12/31

自由軟體專案授權方式的轉換葛冬梅、林誠夏 (上)：不得撤銷原授權條款葛冬梅、林誠夏 (下)：新版本號另以更改後的授權方式釋出筆者在工作上，接觸過不少國內的軟體開發者有這樣的疑問：自己的程式 A（以下簡稱 A）採用甲款自由軟體授權條款釋出，但是之後想要採用另外一份不同的乙款條款來授權的話，是否可以將專案原來的甲款授權方式撤銷 (revoke)，然後改為新的乙款授權條款來授權？雖然部份授權條款並沒有明文說明這方面的規定，目前也沒有司法判決明確禁止這樣的行為，不過因為自由軟體授權條款具有授權給公眾利用後不間斷散布的特性，因此從條款的授權架構與軟體社群的運作習慣分析之，筆者並不認為自由軟體授權專案具有嗣後撤銷性。本文將以目前最廣為應用的自由軟體授權條款 GPL 第 2 版（以下簡稱 GPL-2.0）為例，說明公眾授權條款的特性以及嗣後撤銷授權所可能產生的問題，以解釋為何自由軟體著作權人不宜逕行撤銷原授權，而必須採取其他的方式轉換專案的授權方式。 2015/12/31

/gimp-2.6.9/modules/color-selector-cmyk.c
2015/12/31

衡平原則天下沒有白吃的午餐 2015/12/31

沒有綠豆的綠豆湯 2015/12/31

強制禁止規定例一：我國民法規定出賣人負有瑕疵擔保責任
強制禁止規定例一：我國民法規定出賣人負有瑕疵擔保責任　　例二：歐盟境內賣出的產品附隨二年產品保固責任 2015/12/31

自由開源軟體預設的不附隨保證與擔保特性葛冬梅 2013/12/24
自由開源軟體在散布的過程中，並不收取使用上限定時間、範圍，與對象的授權金（註一），而雖然非授權金性質的其他收費名目是可以要求的，但在大部分的狀況下ー例如透過公開的網路空間平台提供下載，也不會收取其他費用，也就是原則上，自由開源軟體的授權人並不會因為散布自由開源軟體獲得任何的金錢利益，因此相對地，這些授權人並不承諾自由開源軟體的功能一定完美無缺、不會造成使用者有任何損失。這種不附隨保證或擔保承諾，是自由開源軟體的一大特性。不過，這樣的特性，並不等於自由開源軟體的授權人或使用者，可以免除遵守各國法律的強制規定與禁止規定，因此，當授權人或使用者違反法律的強制規定與禁止規定時，還是一樣必須依照法律的要求來負擔一定的責任。本文以下將會針對自由開源軟體這種不附隨保證與擔保的特性加以說明，同時也將舉例說明違反強制、禁止規定的狀況，以協助讀者更進一步了解自由開源軟體的授權特性。 2015/12/31

授權條款三大分類 2015/12/31

Academic Free License 3. 0 (AFL-3. 0), Adaptive Public License (APL-1
Academic Free License 3.0 (AFL-3.0), Adaptive Public License (APL-1.0), Apache License 2.0 (Apache-2.0), Apple Public Source License (APSL-2.0), Artistic license 2.0 (Artistic-2.0), Attribution Assurance Licenses (AAL), BSD 3-Clause "New" or "Revised" License (BSD-3-Clause), BSD 2-Clause "Simplified" or "FreeBSD" License (BSD-2-Clause), Boost Software License (BSL-1.0), Computer Associates Trusted Open Source License 1.1 (CATOSL-1.1), Common Development and Distribution License 1.0 (CDDL-1.0), Common Public Attribution License 1.0 (CPAL-1.0), CUA Office Public License Version 1.0 (CUA-OPL-1.0), EU DataGrid Software License (EUDatagrid), Eclipse Public License 1.0 (EPL-1.0), Educational Community License, Version 2.0 (ECL-2.0), Eiffel Forum License V2.0 (EFL-2.0), Entessa Public License (Entessa), European Union Public License, Version 1.1 (EUPL-1.1), Fair License, Frameworx License (Frameworx-1.0), GNU Affero General Public License v3 (AGPL-3.0), GNU General Public License version 2.0 (GPL-2.0), GNU General Public License version 3.0 (GPL-3.0), GNU Library or "Lesser" General Public License version 2.1 (LGPL-2.1), GNU Library or "Lesser" General Public License version 3.0 (LGPL-3.0), Historical Permission Notice and Disclaimer (HPND), IBM Public License 1.0 (IPL-1.0), IPA Font License (IPA), ISC License (ISC), LaTeX Project Public License 1.3c (LPPL-1.3c), Lucent Public License Version 1.02, MirOS Licence, Microsoft Public License (Ms-PL), Microsoft Reciprocal License (Ms-RL), MIT license (MIT), Motosoto License (Motosoto), Mozilla Public License 2.0 (MPL-2.0), Multics License, NASA Open Source Agreement 1.3 (NASA 1.3), NTP License (NTP), Naumen Public License (Naumen), Nethack General Public License (NGPL), Nokia Open Source License, Non-Profit Open Software License 3.0 (Non-Profit OSL 3.0), OCLC Research Public License 2.0 (OCLC-2.0), Open Font License 1.1 (OFL 1.1), Open Group Test Suite License (OGTSL), Open Software License 3.0 (OSL-3.0), PHP License 3.0 (PHP-3.0), The PostgreSQL License (PostgreSQL), Python License (Python-2.0), CNRI Python license, Qt Public License (QPL-1.0), RealNetworks Public Source License V1.0 (RPSL-1.0), Reciprocal Public License 1.5 (RPL-1.5), Ricoh Source Code Public License (RSCPL), Simple Public License 2.0 (Simple-2.0), Sleepycat License (Sleepycat), Sun Public License (SPL), Sybase Open Watcom Public License 1.0 (Watcom-1.0), University of Illinois/NCSA Open Source License (NCSA), Vovida Software License v. 1.0 (VSL-1.0), W3C License, wxWindows Library License (WXwindows), X.Net License (Xnet), Zope Public License 2.0 (ZPL-2.0), zlib/libpng license (Zlib). 2015/12/31

常見授權條款表分類授權條款全名 BSD類 Apache-1.1 Apache Software License 1.1
Apache License 2.0 BSD-3-Clause New BSD License MIT MIT License Zlib Zlib/libpng License GPL類 GPL-2.0/3.0 GNU General Public License 2.0/3.0 LGPL-2.1/3.0 GNU Lesser General Public License 2.1/3.0 AGPL-3.0 GNU Affero General Public License 3.0 其它類 CPL/EPL-1.0 Common Public License 1.0 Eclipse Public License 1.0 MPL-1.1/2.0 Mozilla Public License 1.1/2.0 CDDL-1.0 Common Development and Distribution License 1.0 Artistic 2.0 Artistic License 2.0 2015/12/31

再散布時是否提供源碼：BSD類 BSD類程式源碼自行決定是否提供程式源碼國科會計畫開發者 (著作權人) 接受技轉公司
A 國科會計畫開發者 (著作權人) B 接受技轉公司使用者 User/You (被授權人) B 接受技轉公司 C 後手 Recipient (被授權人) 自行決定是否提供程式源碼 2015/12/31

2015/12/31

再授權/轉授權 (sublicense) 前一段法律關係裡的被授權人，轉以授權人的地位，以其本人的名義將其所得到的權利，再轉而授權出去給其後的後手被授權人。 2015/12/31

Apache-2.0特色：增加商業運用上相關配置
明示提醒：商標權(Trademark)未授權。明示提醒：可收費提供擔保(Warranty)。軟體專利(Patent)授權規定。專利反制條款。 2015/12/31

化簡為繁的 Apache-2.0 授權條款林懿萱 2012-01-13
若是把常見的自由軟體分成三類：對使用者限制甚少的 BSD 類、以 Copyleft 的授權拘束性著稱的 GPL 類、及不屬於前述兩類的其他類，則 Apache Software Foundation（簡稱 ASF）推出的 Apache 授權條款會落入 BSD 類中。而 Google 的 Android 作業系統雖以 Linux 為基礎，但卻選擇與 Linux Kernel 不同的授權條款－Apache License 2.0（簡稱 Apache-2.0），Android 作業系統之所以選擇 Apache-2.0，是因為相較於拘束性強的 Copyleft 類授權條款，如 GPL 或是 AGPL 系列條款，Apache-2.0 相對是對商業公司較有彈性的授權條款，其並沒有 GPL 類別的諸多規定，更不被要求義務性地將自行開發的程式碼再回饋給自由開放源碼社群，而可以將這部分程式碼封閉私有化後加以利用（註一）；當然，這樣的論點也受到不少批評，認為這是只享受不付出、佔程式開發者便宜的行為。然而，若是採對使用者規定愈少，愈有利於商業公司軟體開發及利用的論點，只有幾百字規定的 BSD 授權條款豈非最佳選擇？（註二）Apache-2.0 佔有什麼優勢，獲得諸如 Google 等商業公司的青睞，本文以下將與 BSD 授權條款相對照，試著對 Apache-2.0 解析之。 2015/12/31

利用 Apache-2.0 程式所應遵守的義務規定
葛冬梅、林誠夏 Apache License 2.0（以下簡稱 Apache-2.0）是 Apache Software Foundation（簡稱 ASF）在 2004 年所發布的自由開源軟體授權條款（註一），雖然一開始從數據上來看，Apache-2.0 被開源專案使用的程度，並不如 BSD、GPL 等授權條款高，不過由於 ASF 旗下專案包括使用率極高的 Apache httpd，以及 Google 在智慧型行動裝置上主推的 Android 平台，均採用 Apache-2.0 來授權，因此此一授權方式的重要性與影響力日漸提升。近兩年來，筆者在工作上發現，愈來愈多人在詢問與討論 Apache-2.0 條款的相關內容，而這些問題中，又以詢問應該如何遵守 Apache-2.0 授權程式的義務性規定佔了大部分。為此，本文特別針對 Apache-2.0 的義務規定加以說明，並且模擬常見的幾種狀況，提供實際應用的著作權聲明範本，希望可以協助開發者安心取用 Apache-2.0 的授權程式來進行程式改作與專案開發（註二）。 2015/12/31

簡論「轉授權／再授權」於公眾授權領域的效力與應用方式
林誠夏「轉授權 (sublicense)」是一個在自由開源軟體授權等公眾授權領域，常被運用到的授權機制。然而、它在著作權法與相關的智慧財產權領域裡，卻是被定義為「例外」機制，這樣的配置，導致許多應用者對 sublicense 並不熟悉，而未能精準掌握其中的概念與運作方式。而一般文獻裡多將 sublicense 中譯為「再授權（再次授權）」，此一譯法亦已為我國著作權法所選用，但文義上也常讓許多人誤認 sublicense 等同於「re-license（重新授權）」，其實，前者 sublicense 是一個法律詞彙與機制，代表「前一段法律關係裡的被授權人，轉以授權人的地位，以其本人的名義將其所得到的權利，再轉而授權出去給其後的後手被授權人。」而後者 re-license 則是一個較為口語的詞彙，代表「某個權利客體（例如軟體專案）之前已經被權利人以某種方式授權釋出，之後同一個權利人轉以改變被授權對象，或是改變授權方式的作法，重新授權給同一個使用者或是其他的使用者。」所以較精準的來說，sublicense 可以被翻為「轉授權」、「副授權」或是「次級授權」，會較貼近原來的定義範圍，並免除文義上的誤會與爭議。 2015/12/31

再散布時是否提供源碼：GPL類 GPL類程式源碼有義務必須提供程式源碼國科會計畫開發者 (著作權人) 接受技轉公司
A 國科會計畫開發者 (著作權人) B 接受技轉公司使用者 User/You (被授權人) B 接受技轉公司 C 後手 Recipient (被授權人) 有義務必須提供程式源碼 2015/12/31

(Object Code → Source Code)
散布目的碼 → 提供程式源碼 (Object Code → Source Code) 2015/12/31

(A work based on the original GPL program)
基於原程式產生的衍生程式後續散布也必須依GPL (A work based on the original GPL program) 2015/12/31

Copyleft 著佐權機制以實踐四大自由理念為目的。以著作權為基礎。反向運用，將使用、散布、修改與重製程式等權利事先授予使用者。
修改後的程式碼仍然必須採用相同方式來授權。 2015/12/31

2015/12/31

因應網路時代與雲端應用而生的 AGPL-3.0 授權條款
葛冬梅 GNU Affero General Public License 3.0 (AGPL-3.0) 是自由軟體基金會於 2007 年 11 月 19 日所發佈的一份自由開源軟體授權條款（註一）。這份授權條款與 GPL-3.0 為孿生條款，因為這兩份條款僅在第 13 條有所不同，其餘的規定則一模一樣。但這第 13 條的不同差異處，就讓 AGPL-3.0 與 GPL-3.0 的拘束特性有著很大的分別，這也讓許多提供網路服務的公司對於這份條款避之唯恐不及。但 AGPL-3.0 在使用上真的如此令人恐懼？其中的條款內容究竟如何？在利用自由開源軟體元件的同時，又應該以什麼樣的態度與立場來面對 AGPL-3.0？本文將會針對這些問題一一說明。 2015/12/31

授權拘束性之強弱 AGPL > GPL > LGPL 2015/12/31

散布GPL衍生程式所須提供的源碼範圍葛冬梅 2010-08-30
這篇文章所要談論的是關於 GPL 授權議題的一個大哉問：「針對 GPL 元件的衍生程式 (derivative works)，使用者應該提供「什麼樣的源碼 (Source Code)」給收受程式的後手？」很多人認為只要單純地將本來以 GPL 授權的元件源碼提供出來即可，並不管這些提供出來的源碼，在實際上是否可以被其他開發者加以研究與修改，也未交待這些 GPL 授權元件是如何與專案裡其他的元件進行連結與互動。這樣的態度其實與 GPL 授權條款的規定並不相符，也與一些自由開源軟體開發者的理念相左。筆者將在本文引述，目前在侵權實務上具有重要地位的自由開源軟體開發者意見，說明他們認為在修改 GPL 元件後，修改者在後續散布時，應該提供什麼樣的源碼（註一）。 2015/12/31

如何提供 GPL 元件的程式源碼葛冬梅 GPL 授權條款制定的目的，是希望人人都可以研究、修改與散佈程式，為了要達到這個目的，取得程式源碼 (Source Code) 是不可或缺的前提要件。因為雖然一位有能力的開發者在拿到目的碼的狀況下，也有可能透過逆向工程來將程式還原到源碼的形式，但這畢竟非常不便，也不是常態，很多情形下也有違法侵權之虞。因此在 GPL 授權條款的規定中，提供程式源碼是一項非常重要的義務，針對程式的研究與修改，透過源碼形式來進行是最為便捷的。而為了讓任何一位拿到程式的後手使用者，都可以順利取得相對應的程式源碼，GPL 設有一套規定散佈者如何提供程式源碼的規定，來保障這些源碼可以持續地被後手取得。綜合 GPL 二版與三版的規定（註一），筆者歸納出五種散佈者提供程式源碼的方式，這是因為 GPL 規定，「散佈」程式目的碼的人，有同時或是嗣後「提供」程式源碼的義務。此篇文章將給予每一種方式簡短的名稱，用以方便記憶與即時運用。這五種方式在二版與三版有些細部的差異，不過基本上非常相近，因此筆者將以 GPL-2.0 為基礎，來說明兩個版本在提供程式源碼的共通之處，而針對相異之處，將會擇其要者加以解說（註二）。 2015/12/31

在源碼之外－編譯與安裝資訊的提供葛冬梅 2009-08-22
依據 GPL 規定，散布 GPL 程式的人，必須要提供程式源碼給拿到 GPL 程式的人。按照字面意義，所謂的源碼就是程式修改源頭的原始碼 (Source Code)，也就是其他開發者可以很方便接續修改這個程式的形式。不過 GPL 在定義源碼範圍的時候，特別提到、若是該專案為一個可執行程式的話，完整的源碼還包括了介面定義檔、控制編譯過程的腳本與安裝資訊，GPL-3.0 更進一步規定，這裡所謂的源碼包含可以讓程式編譯、安裝起來的所有原始資訊，按照這樣的規定，所有該程式相關的必要編譯工具組 (toolchain)，也都包括在這個定義範圍之內，進入散布時必須提供的清單之列（註一）。可是有關程式元件相關的額外資訊，其實並不皆為程式運作時必要的附加物，甚至有些是使用者自己撰寫，完全沒有引用或包含到 GPL 元件的程式碼，在這樣的情況下，許多人常常便會產生疑問：此時使用者自行撰寫的額外資訊，也都必須要依照 GPL 的義務性要求提供出來嗎？ 2015/12/31

從 BusyBox 案例看美歐爭訟實務的差異與轉變
葛冬梅歐洲在過去 4 年，陸續產生 5 件 GPL 的法院案例，其中 4 件在德國，一件在法國，美國則是在 2007 年年底一口氣有 4 件 GPL 的訴訟案出來。在美國這 4 件案子出來前，就有不少人問我，美國既然是自由／開放源碼軟體的發源地，卻遲遲未見 GPL 法院訴訟，反而在德國產生了第 1 件 GPL 的訴訟，原因為何？現在美國有了案例，就讓我們先來大略瞭解一下這 4 個案例的始末，然後再來看美歐面對法律爭端時，處理態度的差異在那裡。 2015/12/31

從 BusyBox 案談起：台灣業者侵權利用自由軟體所面對的法律風險
葛冬梅去年 (2009) 12 月 BusyBox 專案（註一）的著作權人，透過 SFLC（Software Freedom Law Center，軟體自由法律中心）（註二）進行訴訟代理，在美國紐約南區地方法院對 14 家公司提出了自由軟體侵權控訴，其中被告包括了台灣的合勤科技在內，這是繼 2006 年友訊科技在德國被告之後，第二件台灣廠商被控違反 GPL（註三）、侵害自由軟體著作權的訴訟案件（註四）。在此同時，多家國內資訊業者也收到了 BusyBox 代理人所發出的警告信。BusyBox 著作權人這一波所採取的法律措施，對於台灣業界傳達出了不同於以往的意義，這表示，侵權利用自由軟體的法律風險，已由歐洲擴散至美國，其後，甚至可能演變至全球各地。 2015/12/31

再散布時是否提供源碼：其他類其他類程式源碼 1. 原則上有義務必須提供程式源碼 2. 若修改則有機會自行決定是否提供程式源碼國科會計畫
A 國科會計畫開發者 (著作權人) B 接受技轉公司使用者 User/You (被授權人) B 接受技轉公司 C 後手 Recipient (被授權人) 1. 原則上有義務必須提供程式源碼 2. 若修改則有機會自行決定是否提供程式源碼 2015/12/31

File/module-based copyleft: 以MPL-2.0為例 3/3
X Y Y Y X X MPL-2.0 X Y MPL-2.0 MPL-2.0授權條款 X授權條款 Y授權條款授權條款之間相容 2015/12/31

MPL – Netscape Communications CDDL – Sun Microsystem (Oracle)
商業公司制定的授權條款 MPL – Netscape Communications CDDL – Sun Microsystem (Oracle) EPL/CPL – IBM 2015/12/31

檔案基礎的獨立性 - MPL, CDDL 模組基礎的獨立性 - EPL, CPL 2015/12/31

2015/12/31

新版 MPL-2.0 與 MPL-1.1 簡要差異比較林懿萱 2012-04-23
歷經近二年的公開討論，過程中收納了包含 MPL 使用者、律師及開放源碼社群的意見，Mozilla Public License 2.0（簡稱 MPL-2.0，註一）於 2012 年 1 月正式推出了！MPL-2.0 較之先前的 MPL-1.1，有以下幾點主要差異：(1) MPL-2.0 更為精簡，讓使用者更易於閱讀及遵守，(2) MPL-2.0 加強了授權條款的相容性，一方面將專利保護條款修改成和其他開放源碼授權條款的規定更為一致，另一方面也設計若干新的機制，讓 MPL-2.0 不但能夠與 Apache license 在同一個軟體專案下合諧運作而不產生衝突，透過「備位條款」的新機制，也能夠在需要的時候與 GPL、LGPL、AGPL 相容，使程式碼更易於再次被利用及散布（註二）。本文以下將針對此次改版的 MPL-2.0 與之前 1.1 版的主要差異點作要點分析。 2015/12/31

Proprietary Software License Public Domain
幾乎無拘無束的自由大家都必須要一直自由 MPL/CDDL LGPL MIT/BSD GPL類其他類 BSD類 GPL EPL/CPL Apache License AGPL 有點自由又不太自由 Proprietary Software License Public Domain 2015/12/31

自由開源軟體授權條款的三分法葛冬梅既有的自由開源軟體授權條款為數眾多，光是經過開放源碼促進會 (Open Source Initiative, OSI) 核可通過的開源軟體授權條款就超過 50 份，而在自由軟體基金會 (Free Software Foundation, FSF) 網站上，被認定符合四大自由的自由軟體授權條款也超過 60 份，因此對於需要辨識這些授權條款的開發者來說，如果能有一個可以快速檢示授權條款差異的方式或是工具是會很有幫助的。 2015/12/31

GPL-2.0/GPL-3.0版本變更用字通俗化 TiVo反制條款專利授權明示使用原則自動復權機制額外添附條款明示容許ASP
契約自由主義。 TiVo反制條款使用/研究/重製散布/修改。專利授權最低限制專利授權。專利權行使抑制條款。明示使用原則不受感染仍需具名。自動復權機制自動補正、被動補正。額外添附條款調升擔保條款。顯名聲明條款。版本另名條款。廣告禁止條款。商標保留條款。責任禁添條款。明示容許ASP Application Service Provider。肯認合理使用 Fair Use、合理的抗辯權。 2015/12/31

散布自由開源軟體的注意事項葛冬梅若是只有單純地使用自由軟體，通常您並沒有甚麼義務需要負擔，但若想要再次散布這個軟體的話，那就有一些規定必須要注意。散布軟體的規定在每份授權條款中都不一樣，這裡只針對常見的自由軟體授權條款進行概略說明，若您散布的程式採用這裡未提及的授權條款，請注意其中的規定很可能與這裡的說明不一樣，您可以參閱法政中心各授權條款的中文介紹，或來信鑄造場詢問。 2015/12/31

修改自由軟體的著作權人標示葛冬梅最近與同事討論到一個程式釋出案的著作權標示應該如何寫才好，這個程式是修改自由軟體而來的，原本的自由軟體當然有它原有的著作權標示，將原有的軟體名稱與著作權人姓名替換之後，這個標示如下：「2006 (C) Software A, Copyright Owner A'」這是一個常見的標示：年份 + 著作權符號 + 軟體名稱 + 著作權人名稱。若 A 被 B' 修改，著作權標示也必須有相對應的修改，第一個就是軟體名稱需要改變，因為經過 B' 的修改後，軟體已經與原始的 A 不同，所以修改後的軟體名稱當然不可再繼續稱為 A。第二個修改的重點就是著作權人名字，因為修改軟體已經不純粹是甲一個人的創作，所以修改軟體的著作權人標示當然也必須與 A 不同。 2015/12/31

自由軟體授權資訊的標示說明與SPDX 葛冬梅 2011-08-17
自由軟體是一種人人都可以協力開發、修改與散布的軟體，不過並非所有的參與者，都清楚了解應該如何適當地標示授權相關資訊，這造成了許多自由軟體專案，在釋出時授權資訊標示不清，讓拿到軟體的後手不知道有哪些權利可以主張，也不知道有哪些義務必須遵守。而在後者的情況，更可能會讓後手在沒有被充份告知的情況下，以違反授權條款的方式來散布軟體，引發侵權糾紛。這樣的自由軟體侵權糾紛，近年在商業應用上層出不窮，同時也讓部份熱心釋出成果的自由軟體開發社群感到沮喪。所以本文將會分析一般常見授權資訊不清的型態、提出建議的標示方法，以及說明近期 Linux Foundation 針對這樣的問題，所發布的 SPDX 規格書架構，以期望能協助讀者釐清問題根源，並促成國內的自由軟體專案開發者與使用者，都能夠以更適當的方式來標示所使用自由軟體的授權資訊！ 2015/12/31

三、自由開源軟體與開放平台的產業動向 2015/12/31

給台灣企業的建議 2015/12/31

2015/12/31

https://thestack.com/world/2015/11/13/microsoft-open-sources-its-machine-learning-toolkit/
2015/12/31

2015/12/31

如何獲知各分類最新自由開源軟體專案的新星
2015/12/31

2015/12/31

如何評估適合企業的自由開源軟體專案 2015/12/31

2015/12/31

如何快速導入企業內部與之後的維運與管理 2015/12/31

2015/12/31

B. BLACKDUCK/掃描完自行剔除 C. PALAMIDA/掃描完買風險保單 D. FOSSOLOGY/掃描授權資訊
E. BAT/以拆解字串方式驗證目的碼查驗程式碼授權狀態的方式 2015/12/31

自由開源軟體授權分析輔助工具－自動化程式碼掃描系統
葛冬梅為了要解決工作上所需處理的授權分析問題，筆者常會需要了解一個專案究竟利用了哪些自由軟體元件，以及這些元件是採用哪一份自由軟體授權條款？這些工作通常得透過人工進行，也就是請實際開發專案的工程師提供他們的軟體架構圖，並且查詢這些軟體元件適用哪些授權條款，等到取得這些資料後，才有辦法進行後續的授權分析，以研擬授權衝突的解決方案。若涉及的自由軟體元件僅三、四個，那這樣的人工作業尚不困難，但若是牽涉到幾十個自由軟體授權元件，那就得花上好一番的功夫來進行人工作業。因此為了簡便這些授權分析的流程，近年不少團隊就此需求建置了自由軟體程式碼掃描的自動化系統，以掃描軟體專案程式碼的授權方式，並進一步列出報表以顯示該專案裡自由軟體元件的利用情形，以及所使用到自由軟體元件的授權細節。 2015/12/31

© Shane Coughlan 2012, with thanks to Royal Phillips Electronics, released under the Creative Commons Attribution-No Derivative works 3.0 Unported License. (The “Free Software” in the original chart is replaced with “FOSS” to be in accordance with the term used in the Chinese article “FOSS Governance Process” by Florence T.M. Ko, which is available at: 2015/12/31

2015/12/31

OIN亞太地區總監黃鴻文（Kevin Huang） khuang@openinventionnetwork.com
2015/12/31

善用管理流程以妥善利用自由開源軟體加入產品開發
葛冬梅經過這二、三十年的發展，自由開源軟體 (Free and Open Source Software, FOSS) 在品質與數量上面均有大幅度的成長，近年來更是大舉被產業界取來進行商業利用，也因此被應用的層面愈來愈廣，但對於傳統上僅熟悉私有軟體 (proprietary software) 授權模式的商業公司而言，初接觸自由開源軟體不免會引發各式各樣的問題與困擾，例如：「是否可以在終端產品中嵌入自由開源軟體進行商業販售？」、「是否作為內部開發工具就沒有延申要提供程式原始碼 (Source Code) 的問題？」、「如何讓工程師快速了解授權內容，從第一線開始避免侵權利用？」。在國內，有些公司已設有專職人員來研究與處理上述的相關問題，不過就筆者所知，這樣的公司目前仍是少數，大部份的狀況是，面臨到自由開源軟體授權問題與困擾的產品工程師，必須肩負起閱讀授權條款、釐清授權義務規定、回覆客戶相關問題，...... 2015/12/31

2015/12/31

THANK YOU 本簡報授權聲明 Website: www.openfoundry.org
除另有聲明外，本簡報內容採用 Creative Commons「姓名標示 - 非商業性」台灣 3.0 版授權條款。歡迎非商業目的的重製、散布或修改本簡報的內容，但請標明：(1)原作者姓名；(2)本簡報標題；(3)演講日期。簡報中所取用的圖形創作乃截取自網際網路，僅供演講者於自由軟體推廣演講時主張合理使用，請讀者不得對其再行取用，除非您本身自忖亦符合主張合理使用之情狀，且自負相關法律責任。 THANK YOU Website: Phone: ext. 1474 2015/12/31 123

OSSF Open Source Experience Sharing

Similar presentations

Presentation on theme: "OSSF Open Source Experience Sharing"— Presentation transcript:

Similar presentations

About project

反馈

请登录

Auth with social network:

OSSF Open Source Experience Sharing

Similar presentations

Presentation on theme: "OSSF Open Source Experience Sharing"— Presentation transcript:

Similar presentations

About project

反馈