認識與活用自由開源軟體 -初階：授權內容與基礎概念介紹 - 中央研究院資訊科技創新研究中心自由軟體鑄造場葛冬梅法政研究

認識與活用自由開源軟體 -初階：授權內容與基礎概念介紹 - 中央研究院資訊科技創新研究中心自由軟體鑄造場葛冬梅法政研究
中央研究院　資訊科技創新研究中心　自由軟體鑄造場葛冬梅　法政研究　　TEL: #1474 林誠夏　法政研究　本著作採用創用CC 「姓名標示－非商業性」授權條款台灣3.0版

Open Foundry 2014/03/31

法律源地 2014/03/31

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

進行方式原則的解說討論的方式非放諸四海而皆準，需個案討論。可隨時提問，視情況回答。會後的連絡電郵、電話、法政論壇。
2014/03/31

大綱初階：授權內容與基礎概念介紹進階：重要案例與進階管理介紹開源授權六大特性判斷利用元件為自由開源軟體的方式授權條款三大分類
散布時的重要義務進階：重要案例與進階管理介紹開源訴訟重要案件與侵權糾紛的處理區隔GPL程式碼的措施採用策略與管理流程商業應用模式 2014/03/31

開源授權六大特性中央研究院資訊科技創新研究中心自由軟體鑄造場葛冬梅法政研究
中央研究院　資訊科技創新研究中心　自由軟體鑄造場葛冬梅　法政研究　　TEL: #1474 2014/03/31

2014/03/31

自由研究、自由分享 2014/03/31

六大特性開放程式源碼不限制授權對象與使用地域不收取授權金授權不可撤回不附隨擔保釋放四大自由予後手 2014/03/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及其後續版本」來授權，利用程式碼請遵守授權規則，授權規則說明請見：程式碼下載： 2014/03/31

1. 為軟體採用自由開源授權條款 2. 提供程式源碼國科會計畫開發者 (著作權人) 接受技轉公司使用者 User/You (被授權人)
A 國科會計畫開發者 (著作權人) B 接受技轉公司使用者 User/You (被授權人) 2014/03/31

使用權　修改權重製權　散布權 2014/03/31

修改 → 源碼形式　　 (Source Code) 2014/03/31

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

1. 為軟體採用自由開源授權條款 2. 提供程式源碼國科會計畫開發者 (著作權人) 接受技轉公司使用者 User/You (被授權人)
A 國科會計畫開發者 (著作權人) B 接受技轉公司使用者 User/You (被授權人) B 接受技轉公司 C 後手 Recipient (被授權人) 是否提供程式源碼？　1. 依授權條款規定　2. 依使用者意願 2014/03/31

GPL類 → ✔ BSD類 → ∆ 2014/03/31

開放源碼 → 理念提供源碼 → 義務 2014/03/31

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

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

2014/03/31

程式碼→表現形式-著作權程式碼→發明技術-專利權 2014/03/31

限制　　授權對象授權時間授權範圍 2014/03/31

著作權 ✘ 專利權 ✘ 2014/03/31

GPL-3.0專利授權規定 2014/03/31

BSD類條款+額外專利授權：WebM 2014/03/31

商標權 ∆ 圖案、文字...→商業信譽-商標權 2014/03/31

Ubuntu商標政策概要 UBUNTU、KUBUNTU、EDUBUNTU、XUBUNTU、JUJU與LANDSCAPE為註冊商標。
未經授權直接為之針對這些商標討論、打油詩。針對Ubuntu撰寫文章、架設網站或部落格，只要這些行為不會引起誤解。經過授權才得為之將商標用於銷售目的。將商標於網域名稱、URL中。將UBUNTU或BUNTU用於其他標章文字的結尾。 2014/03/31

2014/03/31

授權金 ✘ 費用　 ✔ 2014/03/31

服務費、擔保費用、維護費、技術服務費用 2014/03/31

2014/03/31

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

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

自由散布事實上難以撤回 2014/03/31

GPL-3.0第2條第1項 2014/03/31

Apache-2.0第2、3條 2014/03/31

升級改版、更改授權 - Samba為例 2014/03/31

權利人散布時設立條款升級機制 – GPL-3.0 2014/03/31

條款訂立時設立條款升級機制 – MPL-2.0 2014/03/31

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

2014/03/31

功能面權利面 2014/03/31

衡平原則天下沒有白吃的午餐 2014/03/31

沒有綠豆的綠豆湯 2014/03/31

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

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

四大自由執行程式的自由。研究與修改程式的自由。再次散布程式的自由。散布修改版本，藉此回饋社群並促進改良其他程式的自由。
2014/03/31

自由軟體 Free Software 關於四大自由與自由軟體的內涵，請見： 2014/03/31

Richard M. Stallman ©Gisle Hannemyr, CC by-sa 3.0 unported, 2014/03/31

GNU Project “GNU's Not Unix!” 2014/03/31

GNU計畫授權條款 GNU General Public License, GPL
GNU Lesser/Library General Public License, LGPL GNU Affero General Public License, AGPL GNU Free Documentation License, GFDL 2014/03/31

Free Software Foundation, FSF
2014/03/31

GNU計畫所分析的授權條款 1/2 2014/03/31

GNU計畫所分析的授權條款 2/2 2014/03/31

2014/03/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). 2014/03/31

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

名詞 Free Software Open Source Software (OSS)
自由軟體 Open Source Software (OSS) 開源軟體、開放原始碼軟體 Free/Open Source Software (FOSS) 自由/開放源碼軟體、自由開源軟體 Free/Libre/Open Source Software (FLOSS) 2014/03/31

Open Source Software 開源軟體促進商業化 2014/03/31

Free/Open Source Software
自由開源軟體 Free/Open Source Software 2014/03/31

共享軟體(Shareware)-商業行銷
免費軟體(Freeware) -免費散布共享軟體(Shareware)-商業行銷 2014/03/31

與自由開源軟體的差異原則上不提供程式源碼大多限制用途即使提供程式碼源碼，不代表使用者一定可以修改源碼。
僅得個人使用，不得用於商業用途，或有功能或使用期間上的限制。 2014/03/31

自由軟體？開放源碼軟體？還是開放原始碼軟體？
葛冬梅在中文裡，最常看到的用詞為「自由軟體」，可是也看到有人使用「開放源碼軟體」與「開放原始碼軟體」，為什麼會有這些不一樣的名詞，它們是一樣的嗎？自由軟體這個詞源自於英文的 “Free Software”，由 Richard M. Stallman 首先提出這個詞，其並且對其加以定義：只要一個軟體的散布方式符合四大自由就是自由軟體。所謂的四大自由是指：執行程式的自由、研究程式的自由、再散布程式的自由以及改進程式的自由（註一）。因為這是最早的源頭，沿襲至今，「自由軟體」這一個中文用詞，與下面介紹的其他用詞來的較為被普遍使用。 2014/03/31

判斷利用元件為自由開源軟體的方式中央研究院資訊科技創新研究中心自由軟體鑄造場林誠夏法政研究
中央研究院　資訊科技創新研究中心　自由軟體鑄造場林誠夏　法政研究　　TEL: #1474 2014/03/31

手動自動 2014/03/31

網站有清楚寫明 2014/03/31

README或LEGAL檔 2014/03/31

2014/03/31

Header有簡要標明 2014/03/31

2014/03/31

授權方式不就寫在專案上嗎？ 2014/03/31

2014/03/31

LICENSE.TXT: GPL2 2014/03/31

2014/03/31

? 2014/03/31

2014/03/31

OpenFoundry：OSI: MIT License *of/services Request Tracker：GPL 2.0
*of/of OpenFoundry：OSI: MIT License *of/services Request Tracker：GPL 2.0 Kwiki：Artistic License 2.0 Sympa：GPL 2.0 Subversion：Subversion License CVS：GPL 2.0 *sso *wsw joomla!：OSI: GPL 2.0 2014/03/31

2014/03/31

https://github.com/cfwheels/cfwheels
2014/03/31

2014/03/31

https://github.com/joshuaclayton/blueprint-css/wiki/License
2014/03/31

2014/03/31

以貌取人 2014/03/31

判斷一個軟體是自由開源軟體的方法葛冬梅 2008-12-22
若是初次接觸自由軟體，在茫茫的網海中想要辨認出自由軟體，的確不是件容易的事情。鑄造場提供以下一些簡單的判斷方法，讓您可以在面對一個陌生軟體的時候，初步判斷它屬於自由軟體的可能性。要判斷一個軟體是不是自由軟體，最明確的方式就是看它的授權條款，其次就是這個軟體的介紹文字中是否有用到特定的名詞來形容。這兩種判斷方法都很明確，卻不見得簡單，因為這些資訊不見得會放在顯眼之處，而是藏在層層網站架構中的某一個網頁裡，因此鑄造場最後也提供其他的判斷方法，供您有需要時參考之用。 2014/03/31

(1) BLACKDUCK/掃描完自行剔除 (2) PALAMIDA/掃描完買風險保單 (3) FOSSOLOGY/掃描授權資訊
(4) BAT/以拆解字串方式驗證目的碼查驗程式碼授權狀態的方式 2014/03/31

2014/03/31

FOSSology based on Ubuntu (2009/09/22) Above all =========
1. FOSSology is copyrighted to Hewlett-Packard Development Company, L.P. 2. Ubuntu is a community developed and supported project, the word Ubuntu is a registered trademark of Canonical Ltd. 3. FOSSology110_Ubuntu904_by_OSSF.vdi is not so-called derivative work above, simply a desktop virtualization file to faciliate the usage of FOSSology on Ubuntu by VirtalBox, presented to you by "Open Source Software Foundry, OSSF". About ===== FOSSology110_Ubuntu904_by_OSSF.vdi is a framework for software analysis, built on Ubuntu9.04, can be used throught Sun Microsystems's Virtualbox in most operating systems. It uses a repository for unpacking and storing the uploads, "agents" to analyze the uploaded files, and a Postgres database to store and display the results. Also included is a license agent for scanning source code for potential license texts. 2014/03/31

2014/03/31

2. VirtualBox's Network Setting Adapter Type: PCnet-FAST III
Installation ============ 2. VirtualBox's Network Setting Adapter Type: PCnet-FAST III Attached to : Host-only Adapter Name : vboxnet0 3. Login credential Username: ossf Password: ossf 4. Check IP # ifconfig 5. Browser FOSSology User your favorite browser to surf, 6. Login FOSSology Username: fossy Password: fossy 2014/03/31

2014/03/31

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

自由開源授權條款三大分類中央研究院資訊科技創新研究中心自由軟體鑄造場葛冬梅法政研究
中央研究院　資訊科技創新研究中心　自由軟體鑄造場葛冬梅　法政研究　　TEL: #1474 2014/03/31

建議基本遵守義務標示聲明附上授權條款全文著作權聲明(Copyright Notice) 免責聲明(Disclaimer)
2014/03/31

2014/03/31

建議標示處源碼應用程式嵌入式裝置可標示在README、LEGAL、LICENSE等純文字檔中。
可標示在說明(About)或其他明顯易見之處。嵌入式裝置可標示在紙本說明手冊、使用手冊中。 2014/03/31

“基本遵守” 做了不會有問題不做可能會有問題 2014/03/31

提供程式源碼國科會計畫開發者 (著作權人) 接受技轉公司使用者 User/You (被授權人) 接受技轉公司 C
A 國科會計畫開發者 (著作權人) B 接受技轉公司使用者 User/You (被授權人) B 接受技轉公司 C 後手 Recipient (被授權人) 是否提供程式源碼？　1. 依授權條款規定　2. 依使用者意願 2014/03/31

再散布時，是否有義務提供程式源碼？ 2014/03/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 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 2014/03/31

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

2014/03/31

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

採用BSD授權仍需提供程式源碼 2014/03/31

2014/03/31

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

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

(Object Code → Source Code)
散布目的碼 → 提供程式源碼 (Object Code → Source Code) 　原程式　衍生程式 2014/03/31

Strictly Copyleft示意圖：GPL為例1/3
新程式利用 GPL程式 2014/03/31

新程式→ GPL程式利用/運作關係密切 GPL程式 2014/03/31

散布時必須提供程式源碼新程式→ GPL程式利用/運作關係密切 GPL程式 2014/03/31

授權拘束性 / License Inheritance
Viral Effect / 授權感染性 License Capture / 授權攫取性 License Reciprocal / 授權互惠性 License Inheritance / 授權承繼性 2014/03/31

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

2014/03/31

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

File/module-based copyleft: 以MPL-2.0為例 1/3
2014/03/31

X X X MPL-2.0 X MPL-2.0 MPL-2.0授權條款 X授權條款授權條款之間相容 2014/03/31

X Y Y Y X X MPL-2.0 X Y MPL-2.0 MPL-2.0授權條款 X授權條款 Y授權條款授權條款之間相容 2014/03/31

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

2014/03/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 版的主要差異點作要點分析。 2014/03/31

差異的原因制定者不同、目的不同 BSD類-學術機構-顯名 GPL類-軟體開發者-研究其他類-商業公司-利益 2014/03/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 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 2014/03/31

其他重要授權條款規則 2014/03/31

Proprietary Software License Public Domain
MPL/CDDL LGPL MIT/BSD GPL類其他類 BSD類 GPL EPL/CPL Apache License AGPL Proprietary Software License Public Domain 2014/03/31

範例：FreeBSD源碼檔頭著作權聲明免責聲明 2014/03/31

範例：FreeBSD源碼檔頭 2 clause BSD 2014/03/31

範例：PostgreSQL授權網頁 3 clause BSD
2014/03/31

1. Redistributions of source code must retain the above
copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the PostgreSQL Global Development Group nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. 2014/03/31

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

Open Source / Closed Source
Apache-2.0 Apache-2.0 Apache-2.0 Public Domain Apache-2.0 MIT BSD-like LGPL-2.0 Apache-2.0 BSD-like BSD-like GPL-2.0 2014/03/31 2009 © Alvaro Fuentes Vasquez (Kronox), released under GFDL-1.2+, with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

化簡為繁的 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 解析之。 2014/03/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 的授權程式來進行程式改作與專案開發（註二）。 2014/03/31

GPL類授權條款 GPL LGPL AGPL GPL-2.0, GNU General Public License 2.0
LGPL-2.1, GNU Lesser General Public License 2.1 LGPL-3.0, GNU Lesser General Public License 3.0 AGPL AGPL-3.0, GNU Affero General Public License 3.0 2014/03/31

Lesser Copyleft示意圖：連結LGPL為例1/3
新程式連結利用 LGPL函式庫 2014/03/31

新程式連結利用 LGPL函式庫 2014/03/31

散布時是否提供程式源碼，依照新程式的授權條款來決定。新程式連結利用 LGPL函式庫 2014/03/31

Lesser Copyleft示意圖：修改LGPL為例1/3
新函式庫修改 LGPL函式庫 2014/03/31

2014/03/31

散布時必須提供程式源碼 LGPL函式庫修改 LGPL函式庫 2014/03/31

Application Service Provider, ASP
2014/03/31

More strictly Copyleft示意圖-修改AGPL為例 1/3
新程式結合 AGPL-3.0程式 2014/03/31

新程式→ AGPL-3.0程式結合/運作關係密切 AGPL-3.0程式 2014/03/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？本文將會針對這些問題一一說明。 2014/03/31

修改-散布-提供源碼源碼範圍？ 2014/03/31

以GPL-2.0為例 source code + installation information + compiling script
也就是說原始碼編譯資訊可以載入回原裝置運作的資訊相關工具？ 2014/03/31

不同社群要求不同實際案例、個別判斷 2014/03/31

著作權人態度具有極高的影響力 2014/03/31

著作權人態度可以從原始說明文件的詳盡程度窺之
2014/03/31

BusyBox：注重自由分享與權利維護的社群
2014/03/31

請儘量提供所有的資訊以建立良性的循環 2014/03/31

例外狀況　個案討論 2014/03/31

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

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

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

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

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

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

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

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

散布時的重要義務中央研究院資訊科技創新研究中心自由軟體鑄造場林誠夏法政研究
中央研究院　資訊科技創新研究中心　自由軟體鑄造場林誠夏　法政研究　　TEL: #1474 2014/03/31

放話條款逕行取用、遵守規則、毋需通知。不需回報原作者！ 2014/03/31

散布-Codes Conveying 幾乎所有自由開源軟體授權條款的義務性規定提供程式原始碼≠公開程式原始碼
皆從程式碼被散布開始：光碟、USB、網路。內部使用依GPL3的定義並不該當程式散布。 Application Service Provider → 衍生AGPL-3.0。提供程式原始碼≠公開程式原始碼你的程式有沒有Open=你提供的自由開源軟體是不是有提供Open Source Codes? 公開 to 不特定多數人；提供 to 合法收受程式目的碼的人(客戶)。 2014/03/31

基本義務1 保留所有標示與聲明 2014/03/31

以免誤刪了不該刪的東西 2014/03/31

範例1：FreeBSD源碼檔頭著作權聲明免責聲明 2014/03/31

基本義務2 提供程式源碼 2014/03/31

有些條款規定不提供源碼就是侵權 2014/03/31

source code的範圍？ 2014/03/31

提供GPL程式源碼的各項義務 Whom to open the source code
When to open the source code 開發時？完成時？散布時？被舉發時？被告時？ Where to open the source code 前後手關係→全球散布。 What content should be provided The preferred form of the work for making modifications to it. How to open the source code 燒出去、寫下來、傳出去、放下來、丟出去。 2014/03/31

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

基本義務3 附上授權條款全文文字內容 2014/03/31

後手才有機會知道有哪些權利義務 2014/03/31

JMRI 模型火車控制軟體專案 Jacobsen vs. Katzer 2014/03/31

基本義務4 修改時註明修改者、修改日期 2014/03/31

後手才會知道有問題該找誰 2014/03/31

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

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

Software Package Data Exchange
授權資訊標示標準 SPDX Software Package Data Exchange 2014/03/31

產品上下游流通圖-SPDX資訊 1/4 國科會計畫接受技轉公司品牌公司上游公司 ODM公司 D A B C Ｄ消費者
2014/03/31

產品上下游流通圖-SPDX資訊 2/4 ? ? ? ? 索取GPL元件源碼國科會計畫接受技轉公司品牌公司 ? ? A ? ? 上游公司
B 接受技轉公司 ODM公司 C 品牌公司Ｄ消費者 D ? ? 2014/03/31

產品上下游流通圖-SPDX資訊 3/4 違約賠償 GPL元件源碼 GPL元件源碼國科會計畫接受技轉公司品牌公司 GPL元件源碼
A 國科會計畫上游公司 B 接受技轉公司 ODM公司 C 品牌公司Ｄ消費者 D GPL元件源碼違約賠償 2014/03/31

產品上下游流通圖-SPDX資訊 4/4 ✘ ✘ SPDX資訊 SPDX資訊違約賠償 GPL元件源碼 GPL元件源碼國科會計畫
A 國科會計畫上游公司 B 接受技轉公司 ODM公司 C 品牌公司Ｄ消費者 D GPL元件源碼違約賠償 ✘ SPDX資訊 2014/03/31

SPDX 2014/03/31

1、軟體套件資訊／個別檔案資訊著作權聲明、授權條款、評論與說明、軟體套件名稱、檔案名稱、下載位置、版本對照檢驗方式(checksum)、技術描述資訊… 2014/03/31

2、授權資訊／條款縮寫列表按步就班的標準規格將該被記錄的授權資訊填註到軟體專案裡，並隨著程式碼一併散布出去；重整授權條款縮寫表：簡名為首、以半形符號「-」連接授權條款版本別及其他重要資訊。 2014/03/31

GNU General Public License v2.0 及其後版本
GPL-2.0+ 2014/03/31

GPL-3.0-with-GCC-exception
GNU General Public License v3.0加上GCC編譯器例外條款 GPL-3.0-with-GCC-exception 2014/03/31

2014/03/31

3、後設資料／分析資訊 SPDX規格書提供了兩套後設資料(metadata)的標示標準。一般的標籤記號(tag)與資源描述框架(Resource Description Framework, RDF)的標示方法，使用者可以依照自身的需求選擇適合的來利用。 2014/03/31

Example-all licenses information from files
Tag: “PackageLicenseInfoFromFiles:” Example: PackageLicenseInfoFromFiles: GPL-2.0 PackageLicenseInfoFromFiles: LicenseRef-1 PackageLicenseInfoFromFiles: LicenseRef-2 RDF: property spdx:licenseInfoFromFiles in class spdx:Package <Package rdf:about=""> <licenseInfoFromFiles rdf:resource=" /> <licenseInfoFromFiles rdf:resource="LicenseRef-1" /> <licenseInfoFromFiles rdf:resource="LicenseRef-2" /> </Package> 2014/03/31

Example-package info 2014/03/31

Tools Community-Maintained Tools SPDX Workgroup Tools
Yocto+SPDX FOSSology+SPDX SPDX Workgroup Tools Consolidated SPDX Tools and Library SPDX Compare Utility License RDFa Generator RDF to HTML Pretty Printer Tag To RDF Translator RDF To Tag Translator Spreadsheet Template and Examples RDF To Spreadsheet Spreadsheet to RDF SPDX Viewer 2014/03/31

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

較為嚴格的GPL類 MPL/CDDL LGPL MIT/BSD GPL類其他類 BSD類 GPL EPL/CPL
Apache License AGPL Proprietary Software License Public Domain 2014/03/31

3、已經沒有持續維護的元件,若已經找不到相關授權資訊,是否有建議的處理方法？
2014/03/31

(1) 聯繫原作者 (2) 定期失效 A、元件代換 B、重新撰寫 2014/03/31

4、授權變更的元件（如已經轉成商業販售,不再提供免費下載使用）,或是被三方修改重新打包但授權內容不清楚的元件,是否有建議處理方法？
2014/03/31

2014/03/31

http://gatkforums. broadinstitute
2014/03/31

2014/03/31

https://web. archive. org/web/. /http://sourceforge
2014/03/31

https://web. archive. org/web/20110122024535/http://sourceforge
2014/03/31

6、在使用OSS時，若其整體為A授權，而其內部部份元件為B授權時(AB不相同)，則在使用此OSS資源時，授權該如何認定？若僅使用其內部部份B授權元件時，授權該如何認定？
2014/03/31

互動架構 2014/03/31

2014/03/31

OpenFoundry：OSI: MIT License *of/services Request Tracker：GPL 2.0
*of/of OpenFoundry：OSI: MIT License *of/services Request Tracker：GPL 2.0 Kwiki：Artistic License 2.0 Sympa：GPL 2.0 Subversion：Subversion License CVS：GPL 2.0 *sso *wsw joomla!：OSI: GPL 2.0 2014/03/31

2014/03/31

7、若某元件由a提供程式碼文字檔(為A授權)，而b依照a提供的程式碼實作成實際檔案供人下載(為B授權)則此元件之授權應為A授權或B授權？舉例而言：(A.) JSON為JSON License ( )，有在官網提供java檔程式碼 ( )，但是沒有有編譯後打包為jar形式的檔案；(B.) 這個網站: GPL v2，首頁言明「官网给出是源码(github地址)，居然没打包，非常坑爹。本屌亲自打了个包，就这么简单」，下載頁面可以載到打包後的jar檔( )。A, B大概類似以上情況。 2014/03/31

A、非改作(derivative work)則向體相同 B、.deb、.rpm… C、此種狀況下，打包/微調前後同一。
(1) 微量修改不足以稱之為改作 A、非改作(derivative work)則向體相同 B、.deb、.rpm… C、此種狀況下，打包/微調前後同一。 (2) 但開源授權有可能依條款即可轉換 A、MIT→LGPL、GPL、MPL B、MPL-2.0→GPL2.0+、LGPL-2.1+、AGPL-3.0+ 2014/03/31

2014/03/31

第 1084 條子女應孝敬父母。父母對於未成年之子女，有保護及教養之權利義務。 2014/03/31

8、若在元件授權識別時，元件內無授權資訊，而可能之來源站點已失效，無法直接判斷授權，此時建議該如何處理？
2014/03/31

(1) 聯繫原作者 (2) 定期失效 A、元件代換 B、重新撰寫 2014/03/31

9、(1)在元件授權識別時，若有一待識別之java元件A. jar，及由疑似來源站點下載之元件B
9、(1)在元件授權識別時，若有一待識別之java元件A.jar，及由疑似來源站點下載之元件B.jar，兩者進行比對，若A及 B雖然檔案大小不同，但將jar解壓縮後內容完全相同，則可否辨識為同一元件？(2)承上，若A及B將jar解壓縮後內容雖稍有不同，但是有相同之Manifest資源配置文件(相同元件名稱、版本資訊、來源資訊…etc)，則可否辨識為同一元件？ 2014/03/31

(1) 聯繫原作者 (2) 微量修改不足以稱之為改作 A、參數的調整 B、解釋上B.jar → A.jar 2014/03/31

11、能否簡介GPL with Classpath Exception授權內容及注意事項？
2014/03/31

2014/03/31

Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination. As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. 2014/03/31

As such, it can be used to run, create and distribute a large class of applications and applets. When GNU Classpath is used unmodified as the core class library for a virtual machine, compiler for the java languge, or for a program written in the java programming language it does not affect the licensing for distributing those programs directly. 2014/03/31

2014/03/31

© David A. Wheeler, The Free-Libre / Open Source Software (FLOSS) License Slide, September 27, 2007, available at: You may use, modify, and/or redistribute this document under the Creative Commons “Attribution-Share Alike 3.0 License”; the GNU Free Documentation License; or the GNU GPL (version 2 or later). This information is believed to be correct, but is not legal advice; for formal legal advice, please consult an attorney. 2014/03/31

GPL 與常見授權條款相容性淺析葛冬梅 2014-01-28
GPL 是被廣泛採用的自由開源授權條款，不過由於 GPL 具有授權拘束性，衍生程式必須仍然適用相同條款授權（註一），所以在利用上會需要注意與之結合的程式碼授權內容是否相容，因為與之結合的程式碼一旦成為 GPL 衍生程式，就代表著在散布時必須要透過 GPL 條款來授權散布，若是其原本的授權內容與 GPL 不相容，會讓使用者無法同時符合兩份條款的義務規定，進而可能發生侵權利用的狀況。 2014/03/31

GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍
林誠夏 (上) 林誠夏 (下) GPL 類別的授權程式，最為人著稱的特性便是其「牽一髮而動全身」的授權拘束性（License Inheritance，註一）。所謂的「授權拘束性」白話來說，指的是當使用者將 GPL 授權的程式碼抄寫到自己的軟體專案時，如果抄寫程度佔專案程式碼的比例很大，或是此一 GPL 授權元件提供了專案的核心功能，並且專案的其他元件在互動上亦無法與其分割，則整個軟體專案便會一體被視為該 GPL 授權元件的衍生著作，嗣後使用者如果再行散布這個軟體專案，便僅能適用 GPL 的授權方式來進行釋出。而由於近年來自由開源軟體元件被產業化利用的比率愈見頻繁，因此授權拘束性所帶來的爭議也愈來愈受到重視，本文便是針對這個議題，先依著作權法的預設說明、再照 GPL 授權條款的文意解釋，接著舉 Linux Kernel 的實際運作狀況佐證，一步步抽絲剝繭的分析 GPL 授權程式在衍生程式方面的判定標準，及此標準在軟體元件的連接關係 (linking) 上，所可能擴散的拘束性範圍。 2014/03/31

OpenFoundry (02) EXT.1474 2014/03/31

openlegal openfoundry
2014/03/31

Ctrl+F: 2014/03/31

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

認識與活用自由開源軟體 -初階：授權內容與基礎概念介紹 - 中央研究院資訊科技創新研究中心自由軟體鑄造場葛冬梅法政研究

Similar presentations

Presentation on theme: "認識與活用自由開源軟體 -初階：授權內容與基礎概念介紹 - 中央研究院資訊科技創新研究中心自由軟體鑄造場葛冬梅法政研究"— Presentation transcript:

Similar presentations

About project

反馈

请登录

Auth with social network:

認識與活用自由開源軟體 -初階：授權內容與基礎概念介紹 - 中央研究院 資訊科技創新研究中心 自由軟體鑄造場 葛冬梅 法政研究

Similar presentations

Presentation on theme: "認識與活用自由開源軟體 -初階：授權內容與基礎概念介紹 - 中央研究院 資訊科技創新研究中心 自由軟體鑄造場 葛冬梅 法政研究"— Presentation transcript:

Similar presentations

About project

反馈

認識與活用自由開源軟體 -初階：授權內容與基礎概念介紹 - 中央研究院資訊科技創新研究中心自由軟體鑄造場葛冬梅法政研究

Presentation on theme: "認識與活用自由開源軟體 -初階：授權內容與基礎概念介紹 - 中央研究院資訊科技創新研究中心自由軟體鑄造場葛冬梅法政研究"— Presentation transcript: