自由開源軟體在雲端的運用中央研究院資訊科技創新研究中心自由軟體鑄造場葛冬梅法政研究

自由開源軟體在雲端的運用中央研究院資訊科技創新研究中心自由軟體鑄造場葛冬梅法政研究
中央研究院　資訊科技創新研究中心　自由軟體鑄造場葛冬梅　法政研究　　TEL: #1474 林誠夏　法政研究　本著作採用創用CC 「姓名標示－非商業性」授權條款台灣3.0版

OpenFoundry 2012/12/13

法律源地 2012/12/13

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

大綱重要授權條款簡介利用自由開源軟體元件開發雲端應用專案自由開源軟體專案的開發管理流程 2012/12/13

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

重要授權條款簡介中央研究院資訊科技創新研究中心自由軟體鑄造場葛冬梅法政研究
中央研究院　資訊科技創新研究中心　自由軟體鑄造場葛冬梅　法政研究　　TEL: #1474 2012/12/13

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). 2012/12/13

Apache Software License 1.1 Apache-2.0 Apache License 2.0 BSD-3-Clause
常見授權條款表分類授權條款全名 BSD類 Apache-1.1 Apache Software License 1.1 Apache-2.0 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 2012/12/13

BSD類：幾乎無拘無束的自由 MIT/BSD BSD類 Apache License Public Domain 2012/12/13

BSD類：重要內容 BSD授權條款的本質 Copyright Notice，保留著作權聲明。 Disclaimer，保留免責聲明。
No Endorsement，禁止廣告宣傳。必要時可以不用提供程式源碼只要再散布時，改以其他授權方式散布。故即使散布衍生程式，也沒有必然提供程式源碼的義務 2012/12/13

Apache-2.0：特色保留BSD條款的本質 Copyright Notice，保留著作權聲明。 Disclaimer，保留免責聲明。
No Endorsement，禁止廣告宣傳。增加商業運用上的相關配置明示提醒：商標權(Trademark)未授權。明示提醒：可收費提供擔保(Warranty)。專利(Patent)授權規定。專利反制條款。 2012/12/13

2012/12/13

BSD類 vs. 私有軟體 BSD類被私有軟體大量利用。建議散布時提供原程式的源碼。有益於PR。
易於取得社群支援+建立良好互動=益於未來的研發應用。 2012/12/13

化簡為繁的 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 解析之。 2012/12/13

2012/12/13

GPL類：大家都必須要一直自由 LGPL GPL類 GPL AGPL Proprietary Software License
2012/12/13

Copyright 著作權 Copyleft 著佐權
2012/12/13

請你跟我這樣說請你跟我這樣做 2012/12/13

散布修改程式相同方式授權 2012/12/13

散布目的碼 → 提供原始碼 2012/12/13

Strictly Copyleft示意圖：GPL為例1/3
新程式利用 GPL程式 2012/12/13

新程式→ GPL程式利用 GPL程式 2012/12/13

散布時必須提供程式源碼新程式→ GPL程式利用 GPL程式 2012/12/13

GPL：重要內容注重程式源碼的散布散布程式目的碼，便有提供程式源碼的義務。提供程式源碼的方式必須符合授權規定。
衍生程式採用相同條款來授權修改過的檔案必須標示 2012/12/13

授權拘束性 / Strictly Copyleft
Viral Effect / 授權感染性 License Capture / 授權攫取性 License Reciprocal / 授權互惠性 License Inheritance / 授權承繼性 2012/12/13

LGPL → 函式庫 - 調弱授權拘束性 AGPL →網路服務應用程式 - 強化授權拘束性
2012/12/13

2012/12/13

其他類：有點自由又不太自由 MPL/CDDL 其他類 EPL/CPL Proprietary Software License
Public Domain 2012/12/13

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

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

其他類：重要內容衍生程式採用相同條款授權。若符合特定條件，自己撰寫的程式碼可以採用其他條款授權。特定條件 → 獨立性
File-based independence / 檔案基礎的獨立性 Module-based independence / 模組基礎的獨立性 2012/12/13

2012/12/13

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

利用自由開源軟體元件開發雲端應用專案中央研究院資訊科技創新研究中心自由軟體鑄造場林誠夏法政研究
中央研究院　資訊科技創新研究中心　自由軟體鑄造場林誠夏　法政研究　　TEL: #1474 2012/12/13

2012/12/13

To be derivative work or not to be derivative work, that's the question.
2012/12/13

部份條款寬鬆認定衍生的定義(BSD-like) 部份條款嚴格擴張衍生的範圍(GPL-like)
Copyleft的基礎在改作權改作之後的作品為衍生著作部份條款寬鬆認定衍生的定義(BSD-like) 部份條款嚴格擴張衍生的範圍(GPL-like) 2012/12/13

一個GPL各自解讀 2012/12/13

1. 剔除拘束性質程式碼 2. 核心技術分開散布 3. 中介隔離預作區隔 2012/12/13

剔除／分開／中介風險↑ 風險↑ 風險↑ 2012/12/13

1. 剔除拘束性質程式碼 2012/12/13

不要用 2012/12/13

(1)分析授權狀態 2012/12/13

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

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

(2)實施剔除工作 2012/12/13

A. 尋求原程式著作權人的另行授權 B. 學習後重新創作不相容的程式碼
C. 以非COPYLEFT性質的軟體代換 2012/12/13

A.另行授權 2012/12/13

2012/12/13

B.重新創作 2012/12/13

重新創作≠抄襲改作 2012/12/13

著作權法保護標的僅及於著作的表達、不及於著作的概念。重點是不可機械式自動編譯、或是用全自動轉譯的手法。
2012/12/13

月落烏啼霜滿天，江楓漁火對愁眠；姑蘇城外寒山寺，夜半鐘聲到客船。楓橋夜泊唐張繼 2012/12/13

月落烏啼霜滿天，江楓漁火對愁眠；兩岸猿聲啼不住，請用猴標六神丹。改寫楓橋夜泊唐張繼 2012/12/13

秋夜江邊，殘月西沉，烏鴉啼叫，清霜滿天。滿懷鄉愁孤臥客船，只有火紅的江楓，明滅的漁火相伴。夜深難眠，又聽到從蘇州城西寒山寺傳來的悠揚的鐘聲，幽靜得更令人難耐。
改寫楓橋夜泊唐張繼 2012/12/13

自小背誦張繼的楓橋夜泊，所以旅遊時興沖沖的來到寒山寺看看，秋天晚上的天氣確實非常寒冷，感覺頭頂以上滿罩一層薄霜，月亮下沉時烏鴉的啼叫聲顯得特別淒厲，岸邊楓樹的葉子早已呈現火紅的顏色，在明明暗暗燈火的照耀下，讓人不禁想起台北故鄉的霓紅燈，隨著鐘聲擺盪起伏，終於感受到一人旅行的孤獨感。重新創作楓橋夜泊唐張繼 2012/12/13

This image is a work of a U. S
This image is a work of a U.S. military or Department of Defense employee, taken or made during the course of an employee's official duties. As a work of the U.S. federal government, the image is in the public domain. Author Raúl Silva Permission “for any use you want" Fair use at: 2012/12/13

MPL-1.1 2012/12/13

C. 軟體代換 2012/12/13

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

2012/12/13

2. 核心技術分開散布 2012/12/13

2012/12/13

GNU General Public License Version 2
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. 2012/12/13

2012/12/13

GNU is Not Unix 2012/12/13

Linux Kernel 2012/12/13

Independent and separate works
2012/12/13

分開散布→獨立性 2012/12/13

2012/12/13

Work based on the Program Work uses the Program
2012/12/13

靜態連結動態連結 2012/12/13

Static Link: 必然的連結關係代表其他程式與GPL程式間不可分割的依賴關係衍生著作-非獨立著作 2012/12/13

此圖下載於：作者polarpila採用創用CC-姓名標示-非商業性-禁止改作對外釋出；此處特別聲明為在自由軟體推廣演講中進行「合理使用」，請讀者不要更行移置他用。 2012/12/13

Dynamic Link: 浮動的連結關係代表其他程式與GPL程式間可被取代的獨立關係獨立著作-不受授權拘束限制 2012/12/13

2012/12/13

Windows, Linux, Mac OS X, MeeGO....
2012/12/13

此圖下載於：作者The 2th RoOm採用創用CC-姓名標示-非商業性-相同方式分享對外釋出；此處特別聲明為在自由軟體推廣演講中進行「合理使用」，請讀者不要更行移置他用。此圖下載於：作者polarpila採用創用CC-姓名標示-非商業性-禁止改作對外釋出；此處特別聲明為在自由軟體推廣演講中進行「合理使用」，請讀者不要更行移置他用。 2012/12/13

2012/12/13 此圖下載於：http://www.flickr.com/photos/leeicep/6891496/sizes/m/
作者icelee採用創用CC-姓名標示-非商業性-禁止改作對外釋出；此處特別聲明為在自由軟體推廣演講中進行「合理使用」，請讀者不要更行移置他用。 2012/12/13

It depends 2012/12/13

2012/12/13

2012/12/13 此圖下載於：http://www.flickr.com/photos/0x0000org/3492093532/
作者0x0000org採用創用CC-姓名標示-非商業性，對外釋出；此處特別聲明為在自由軟體推廣演講中進行「合理使用」，請讀者不要更行移置他用。 2012/12/13

GPL 的另類利用方式：「分開散布．責任轉嫁」
葛冬梅一個常被提出的問題：要如何在利用 GPL 程式碼的同時，避免其他部份的程式碼也被 GPL 感染？之前曾經提過一些抽象的判斷標準，例如採用動態連結 (dynamic link) 利用 GPL 程式碼，因此開發出來的新程式，許多開發者認為可以不用受到 GPL 的拘束，但是採用靜態連結 (static link) 利用 GPL 程式碼，許多開發者認為新程式仍應該採用 GPL 授權。這樣的標準仍是相當抽象，這期的法律園地就來談一個比較具體的方式，筆者稱這樣的方式為「分開散布．責任轉嫁」。所謂「分開散布」是指將 GPL 程式碼與非 GPL 程式碼分開散布，「責任轉嫁」則是將提供原始碼的責任轉嫁到他人身上。聽來這好像是兩件不同的事情，要怎麼樣才能兜在一起呢？現在就說個甲跟乙的故事來說明。 2012/12/13

3. 中介隔離預作區隔 2012/12/13

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 2012/12/13 2009 © Alvaro Fuentes Vasquez (Kronox), released under GFDL-1.2+, with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

2012/12/13

Linux Kernel 2012/12/13

User space GPL-2.0 ．感染性特強．佔有率高．可遠觀而不可褻玩焉．Linux Kernel是一個特殊的變態
Linux Kernel主要開發者兼精神領袖Linus Torvalds表態，寬鬆地允許應用程式可以不採用 GPL-2.0 授權。 User space 此圖著作權利歸屬於Google © 2008，特別聲明為自由軟體推廣演講中進行「合理使用」，請讀者不要更行移置他用。 ©Google 2012/12/13

Linux Kernel-COPYING NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the linux kernel) is copyrighted by me and others who actually wrote it. 2012/12/13

Derivative Works 衍生著作 2012/12/13

Open Middleware Open Middle Layer 2012/12/13

≠ Derivative Works ≠ 衍生著作 2012/12/13

Transplant 2012/12/13

Android 的區隔 GPL 拘束機制葛冬梅 2008-10-24
兩個月前談過「分開散佈．責任轉嫁」這種用來避開 GPL 感染的一種方法，今天要談的是另外一種方法：區隔機制。所謂的區隔機制就是在 GPL 程式與 nonGPL 程式中間插入一個中介的介面，這個介面寫得夠好，讓 nonGPL 程式透過介面與 GPL 程式互動，nonGPL 程式因此不會包含任何的 GPL 程式碼，所以 nonGPL 程式不受到 GPL 感染。而這個介面可以是 LGPL、BSD 或 Apache 等任何一份授權條款。 2012/12/13

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

是 Δ ？否 □ 2012/12/13 自由開源軟體元件A與自行撰寫元件B的互動關係通說認定上，元件B是否為元件A之衍生著作。
通說≠放諸四海皆準。元件B是否為元件A之衍生著作，乃依一般軟體著作權對衍生關係的界線來評判，但此界限在不同自由開源軟體授權條款，其實會被條款內容做進階放鬆或限縮的處理。回歸授權條款的基本面，但特例：Sencha / MySQL，建議尊重著作權利人的預先解釋以避除爭議風險。網路呼叫方式，應先判斷主機端與客戶端是否運作密不可分的結構關係，如兩者承襲一樣的資料結構與縝密無法取代與調整的互動流程，則其仍可能被視為一個統合專案(as a whole)，而必須一體適用同一個授權方式；而若並非這樣的緊密結合，再進一步討論兩者之間的互動關係，是否會讓兩元件授權方式互相影響。通說認定上，元件B是否為元件A之衍生著作。元件B是否須依原始開源授權方式來散布？ BSD-3-Clause Apache-2.0 LGPL-2.1/ LGPL-3.0 GPL-2.0/ GPL-3.0 AGPL-3.0 B、A具不同功能，B透過A之API呼叫其功能，但兩者一同編譯為一個執行檔。是 Δ B採用靜態連結方式與A互動，B在編譯時需要A，B在編譯後產生如Lib的函式庫檔案。？ B採用動態連結方式與A互動，B本身為一可執行檔，專案運作上只有需要的時候才會動態地載入A.dll。否 B與A各自為可執行檔，B在執行時傳遞參數給A，讓A執行之後回傳資料回到B。 □ B採用網路呼叫方式與A互動，A為主機端程式，B為客戶端程式，B執行時會呼叫A，並依據A回傳的結果繼續運作，如Web Service。 ☆ A採用網路呼叫方式與B互動，B為主機端程式，A為客戶端程式，A執行時會呼叫B，並依據B回傳的結果繼續運作，如Web Service。 Δ 衍生著作毋須完全採用原始開源授權方式散布，但仍須服膺踐履該授權條款的其他義務性要件。？是否元件B失去元件A的互動關係則無法運作(質的抽象判斷)；是否元件B失去元件A則失去多數功能(量的抽象判斷)；元件B與元件A之間的互動結構，是否可採用其他元件C代替元件A；若加上這些個案判斷的元素，能主張元件B具有獨立性，則例外地不受到元件A授權方式的拘束，而若不能主張獨立性，則原則上元件B受到元件A授權方式的拘束；在LGPL的狀況下，數字參數、資料結構層級及資料結構存取機制、或是小巨集及微量內嵌功能程式碼並不會開啟授權拘束性，但該被引用的LGPL函式庫必須具更新版本代換性，否則例外地會開啟其授權拘束特性。 □ 原則上為非衍生關係，但必須清楚交待元件B與元件A的互動方式與介面，讓使用者在元件A升級改版之後，能重啟元件A與元件B之間的互動關係；而若不能完成這個機制，則元件B就有可能被列回衍生關係，而必須受到元件A授權方式的拘束。 ☆ AGPL- 3.0授權元件，在「修改後」置於網際網路之上提供服務，依條款規定便需要向使用者提供此元件修改過後的程式源碼。 2012/12/13

AGPL元件與雲端應用專案 2012/12/13

ASP Application Service Provider
2012/12/13

More strictly Copyleft示意圖-修改AGPL為例 1/3
新程式結合 AGPL-3.0程式 2012/12/13

新程式→ AGPL-3.0程式結合 AGPL-3.0程式 2012/12/13

AGPL：特色針對ASP所設計的授權條款依據GPL規定ASP的衍生程式不需要提供程式源碼強化GPL的授權拘束性 2012/12/13

AGPL-3.0 = GPL 修改第13條 2012/12/13

因應網路時代與雲端應用而生的 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？本文將會針對這些問題一一說明。 2012/12/13

自由開源軟體專案的開發管理流程中央研究院資訊科技創新研究中心自由軟體鑄造場林誠夏法政研究
中央研究院　資訊科技創新研究中心　自由軟體鑄造場林誠夏　法政研究　　TEL: #1474 2012/12/13

Trend 2012/12/13

2012/12/13

1、多人共工 2、借力使力 3、永續發展 2012/12/13

Free Software Foundation (FSF)
Richard M. Stallman (rms) Free Software Foundation (FSF) 1985- 基本教義派 2012/12/13

Open Source Initiative (OSI)
Free Software – 自由軟體 Open Source Software – 開放源碼軟體 Bruce Perens & Eric Raymond Open Source Initiative (OSI) 1998- 折衷主義，商業化思維 2012/12/13

gpl-violations.org 2012/12/13

Software Freedom Law Center (SFLC)
2012/12/13

Software Freedom Conservancy (SFC)
2012/12/13

Linux Foundation 2012/12/13

Linaro 2012/12/13

2012/12/13

2012/12/13 © Fair use, available at:
2012/12/13

Start a project linking with Open Source components
2012/12/13

Policy 2012/12/13

What's the enterprises' need?
2012/12/13

Lower cost, more profit. 2012/12/13

Advantage / Disadvantage
2012/12/13

When the advantage runs over the disadvantage, it worth doing.
2012/12/13

Money.... short term, long duration.
2012/12/13

In early stage: To release or not to release?
2012/12/13

Nowadays: How to release our source code?
2012/12/13

To Open or not to Open, that's the question.
2012/12/13

© Shane Coughlan, CC BY-ND 3. 0 Unported License
© Shane Coughlan, CC BY-ND 3.0 Unported License. The chart is at p18 of the slide “Licensing Compliance as Business Intelligence”, avaiable at: . 2012/12/13

© 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: 2012/12/13

Approved Software List
2012/12/13

Rejected Software List
2012/12/13

Business Model 2012/12/13

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

X 授權金、權利金收費名目不能是專利權授權金/著作權授權金 2012/12/13

1. 自由開源軟體服務收費模式 2. 自由開源軟體嵌入式加值模式 3. 自由開源軟體商標權收費模式 4. 自由開源軟體雙重授權模式
2012/12/13

Be Open 2012/12/13

Open Policy 2012/12/13

自由開源軟體雙重授權模式(1) 2012/12/13

自由開源軟體雙重授權模式(2) 2012/12/13

2012/12/13

X 1. 自由軟體服務收費模式 2. 自由軟體嵌入式加值模式 3. 自由軟體商標權收費模式 4. 自由軟體雙重授權模式 2012/12/13

Not to Open 2012/12/13

Close Policy 2012/12/13

1. 剔除拘束性質程式碼 2. 核心技術分開散布 3. 中介隔離預作區隔 2012/12/13

Main product Secondary product
2012/12/13

Useful tips for releasing Open Source code with commercial products
1. BusyBox configuration You need to provide the configuration that was used to build BusyBox as part of the source code. Depending on the version of BusyBox this is a file called Config.h (BusyBox and earlier) or .config (1.00-pre1 and later). 2. Linux kernel configuration If your product uses the Linux kernel you have to provide the configuration that was used to build it as part of the source code. 3. Extra Linux kernel modules If your product uses extra kernel drivers you may have to provide their source code. You should check their license terms carefully. 4. C library If your product uses glibc or uClibc you have to provide sources. If the software development kit (SDK) received from your supplier only has binaries, you need to request the source from the supplier. 5. Object files If you have a program that links non-Open Source code to code licensed under LGPL 2.1, then you need to provide the object files and build configuration. That means including the Makefile and so on. Example: liborz-0.11 is LGPL 2.1 licensed. It is linked with foo.o into a program called bar. To fulfill the LGPL requirements you have to provide the sources for liborz-0.11, the object file foo.o and the Makefile to combine these two. 6. Bootloader Many devices are shipped with a GPL licensed bootloader, such as ARMboot, PPCboot, RedBoot or u-boot. If the bootloader is GPL licensed you will have to provide source code to your customers. If the bootloader is provided by the supplier then they must give you the source code. 7. Toolchain If you distribute a binary toolchain (compiler, binutils, C library) licensed under GPL/LGPL with a device or on the Internet then you need to make the source code available too. The toolchain often comes as part of the software development kit (SDK) from your supplier and you can ask them for the source code. 8. Firmware Firmware often contains leftover programs from other devices because many different products are made from a single source tree. If these programs are licensed under GPL or LGPL then source code must be provided for them when the firmware is distributed. There are two solutions: supply the source code or remove any unused programs from the source tree. 9. Source archives Source archives often contain leftover programs from other devices because many different products are made from a single source tree. If these programs are licensed under GPL or LGPL then source code must be provided for them when the firmware is distributed. There are two solutions: supply the source code or remove any unused programs from the source tree. by Armijn Hemel, gpl-violations.org (Avaiable at: 2012/12/13

商業產品釋出程式原始碼的實用提醒 2012/12/13 1. BusyBox 設定檔
您需要提供 BusyBox 相關的設定資訊，讓他人可以根據這些資訊將 BusyBox 建置成為原始碼的一部分。而隨著 BusyBox 版本的不同，設定資訊相關檔案的名稱也會有所不同：在 BusyBox 及之前的版本，檔案名稱是 Config.h，在 BusyBox 1.00-pre1 及之後的版本，檔案名稱則是 .config。 2. Linux kernel 設定檔假如您的產品利用到 Linux kernel，您必須要將相關的設定資訊提供出來，讓他人可以根據這些資訊將 Linux kernel 建置成為原始碼的一部分。 3. 額外的 Linux kernel 模組假如您的產品有利用到額外的 kernel 驅動程式，您可能必須要提供這些驅動程式的原始碼。您應仔細了解這些驅動程式的授權條款內容，以確認是否需要提供原始碼。 4. C 函式庫假如您的產品利用到 glibc 或 uClibc 函式庫，您必須要提供這些函式庫的原始碼。假如相關的軟體開發套件 (SDK) 只有二進位碼，並且是由您的上游供應商所提供的，此時您需要向上游供應商索取原始碼，以便這些函式庫的原始碼能提供出來。 5. 目的檔假如您的程式將非自由軟體程式碼連結到 LGPL 2.1 授權的程式碼，那麼您就需要提供目的檔與建置所需要的設定資訊，這代表著編譯描述檔 (Makefile) 等資訊也在提供之列。例如： liborz-0.11 採用 LGPL 2.1 授權，您的程式 bar 中的 foo.o 檔案連結利用 liborz-0.11。此時，為了滿足 LGPL 的要求，您必須提供 liborz-0.11 的原始碼、foo.o 的目的檔以及結合這兩者的編譯描述案 (Makefile)。 6. 開機管理程式許多裝置是包含著 GPL 授權的開機管理程式 (Bootloader) 出貨的，例如： ARMboot、PPCboot、RedBoot 或 u-boot 等。假如開機管理程式是以 GPL 授權的話，您必須要提供這些程式的原始碼給您的客戶。若這些開機管理程式是由您的上游供應商所提供，上游供應商必須依照 GPL 的規定給您原始碼。 7. 工具程式若您隨著產品裝置或是在網路上散布二進位的工具程式（編譯器、binutils、C 函式庫），您便需要讓他人也可以取得這些工具程式的原始碼。工具程式通常是包含在軟體開發套件 (SDK) 裡面，並且由您的上游供應商提供，因此您可以向他們索取原始碼。 8. 韌體因為許多不同的產品都是從同一個原始碼樹狀結構 (source tree) 中產生出來，因此韌體中常會包含一些其他裝置才需要的多餘程式，假如這些多餘程式是採用 GPL 或 LGPL 授權的話，當散布韌體時，您也必須要提供這些多餘程式的原始碼。此時您有兩種不同的解決方法：您可以如前面所描述的那樣，提供他人原始碼，或者您也可以將這些不會被用到的程式，從原始碼樹狀結構中刪除。 9. 原始碼檔案庫因為許多不同的產品都是從同一個原始碼樹狀結構 (source tree) 中產生出來，因此原始碼檔案庫中常會包含一些其他裝置才會需要的多餘程式，假如這些多餘程式是採用 GPL 或 LGPL 授權的話，當散布韌體時，您也必須要提供這些多餘程式的原始碼。此時您有兩種不同的解決方法：您可以如前面所描述的那樣，提供他人原始碼，或者您也可以將這些不會被用到的程式，從原始碼樹狀結構中刪除。譯者：葛冬梅，自由軟體鑄造場 2012/12/13 （文章網址：

1. Derivative Works / No Derivative Works
2. Re-build the System (Install Information, Compiling Script...) 3. Binary Code → Source Code (Bootloader, Toolchain, Firmware, Source Archives...) 2012/12/13

Working with the community
1. What is "the community"? In open source software the concept of 'the community' is important, because it is the core unit to run the open source software development. Often a community consists of developers of the software, users of the software and other interested people. Every community is different and has different goals, methods and requirements. An approach that works with one community might not work with another. Some communities welcome corporate cooperation, while others will be quite hostile about it. Bigger communities, like the Linux kernel, almost always welcome corporate cooperation. 2. Why would I want to work with an open source community? Working with the community has advantages. For example, if you use code from a project and make changes to it, you can benefit from submitting it for inclusion in the "upstream" source. This means that: * if a newer version of the software is released, you will not have to apply your changes again * your code will get peer review and will probably be improved * it is good PR for your company * GPL license management is easier because there are no patches that can be forgotten when making a source code distribution 3. How do I work with an open source community? There are a few core rules that you will need to follow to increase the chance of a contribution being accepted: * Use the coding style that the project uses. The developers are used to this and will sometimes refuse your code if it uses a different style * Don't expect that big patches will be accepted right away. Some patches need revision before they are accepted, because they are too specific for one user and don't benefit a lot of users. * Be open, and ask questions if you don't understand something. * Don't take criticism personally. Many developers can be rude, especially on the Linux kernel mailing lists. This is because writing good code is what they pride in. They expect other people to write good code too, and they are not very subtle. Just remember that it is not personal and it is not a criticism of your company. They just care about code quality. 4. Getting help There are companies who provide consultancy on working with FOSS and with contributing to communities. Examples include large providers like IBM and HP, small management consultancy companies like Olliance and Opendawn, and engineer-focused consultancies like HMW Consulting and Loohuis Consulting. by Armijn Hemel, gpl-violations.org 2012/12/13 (Avaiable at:

與自由軟體社群合作 1. 什麼是「社群」？在自由軟體的領域中，「社群」是重要的概念，因為這是運轉自由軟體開發的核心單位。通常一個社群由軟體開發者、使用者與其他有興趣的參與者所組成。每一個社群都不盡相同，並且有不同的目標、做事方法與要求標準。因此，跟某甲社群的合作方式，不見得可以套用在跟某乙社群的合作上。有些社群歡迎與私人企業合作，不過有一些社群卻對此採取敵對的態度。然而規模越大的社群, 如 Linux kernel ，幾乎都很歡迎與私人企業合作。 2. 為什麼我要和自由軟體社群合作？與社群合作有一些好處。例如, 當您利用了某社群所開發的專案程式碼，並且對這些程式碼做了一些修改，若是這些修改能被納入到「上層」(upstream) 的原始碼中，這意味著： * 如果該軟體有新版本釋出時，您的修改將會直接被納入到新版本中，可以省掉將自己的修改納入新版本的功夫； * 您的程式碼可以被社群開發者共同審閱，並且可能因此獲得改進； * 對您公司的對外公共關係有益處； * 若這個軟體是以 GPL 授權的話，在管理上會比較容易，因為當散布原始碼時，不會有修正更新檔 (patches) 被遺漏而未散布出去。 3. 我該如何與自由軟體社群合作？這邊提供您一些重要原則，可以增加您的貢獻被社群接受的機會： * 使用跟那個專案開發社群一樣的軟體寫作風格 (coding style)。社群的開發者習於慣用的軟體寫作風格，並有時因此拒絕風格不同的程式碼； * 不要期望大的修正更新檔會立即被接受，因為有些修正更新檔只方便特定使用者利用，並無法讓大部分的使用者受惠，所以在被接受之前需要時間修訂； * 保持開放的態度，而若是您有什麼不懂的話，就請開口詢問； * 別把社群討論中的批評當作是人身攻擊。許多開發者也許言語直率，尤其在 Linux kernel 的郵遞論壇中有不少這樣的開發者，但這是因為寫出高品質的程式碼是這些開發者引以為傲的事情，因此他們也期待別人會想寫出好的程式碼，卻不善於圓滑地表達。請記住：這些批評並非人身攻擊，也並非是針對您公司的批評，這些開發者關心的只有程式碼品質而已。 4. 尋求協助有一些公司提供相關諮詢服務，協助他人如何利用自由軟體與如何將貢獻內容回饋給社群，提供諮詢的公司包括了 IBM、HP 等大型公司，以及 Olliance、Opendawn 等小型管理諮詢公司，還有像是以工程師為主要諮詢提供者的 HMW Consulting 與 Loohuis Consulting 兩間公司。譯者：葛冬梅，自由軟體鑄造場（文章網址： 2012/12/13

Communities → Copyright holders 2. Upstream / Public relations
1. It depends... Communities → Copyright holders 2. Upstream / Public relations 3. Charge for free / charge for fee； Official / Unofficial 2012/12/13

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

優點 / 缺點 2012/12/13

Management 2012/12/13

基本的注意事項 1、備齊此GPL相關程式的原始碼，以備軟體目的碼的收受者提出索取程式原始碼的要求時，能夠即時的予以供給(GPL所謂供給程式原始碼的義務，解釋上散布者由提供程式目的碼之始即應擔負；又、此一提供程式原始碼的義務乃針對「收受GPL程式目的碼之人」而言，並非對不特定公眾皆有提供程式原始碼的義務。 2、確定您與此一GPL相關程式的著作權歸屬關係，如在程式中摻雜了部份他人編著的自由軟體程式碼，請僅記須善盡尊崇原始著作權人的「顯名主義」，透過聲明或其他布告手法表彰其顯名上的權利。 3、確認欲釋出的程式原始碼版本是否正確，其與所散布的程式目的碼間須有完全的對應關係，而不是從權地散布陳舊的原始碼版本、或者根本給予他人錯誤的或不相關的原始碼檔案。 4、確定您是否盡到提供GPL相關程式及其衍生作品「完整」原始碼的義務，請注意GPL於程式編寫上有其「授權攫取性」，亦即若您取用了相當部份的 GPL軟體程式碼，則整個作品皆須以GPL為其日後再行散布之授權條款，故此處所指的提供「完整」原始碼義務，非僅止於結合作品中第三人本以GPL釋出之自由軟體，更包含至此結合作品中您另行編寫的其他部份。 5、確定您是否提供具體翔實的編譯腳本及安裝所需流程予收受程式的後手使用，依GPL的規定、釋放程式原始碼的義務並非僅是粗糙性的將原始碼檔案未經修整的散布出去即可滿足，其要求散布者亦須提供程式相關的編譯及安裝資料方可稱之。 6、如您釋出的標的包括其他附屬性的GPL程式(如GCC編譯器此一使用率極高的GPL程式)，注意除了您釋出的主要程式須服膺在GPL諸般義務性要求之下，亦不可忽略了這些附屬程式亦為GPL所拘，其雖為附屬性的程式、一經釋出仍須依足GPL預設的遊戲規則來進行。 2012/12/13

Basic Guidelines: 1. Check if the source code of the software is available to users. 2. Check if you are the copyright holder of the software and if you include Free Software copyrighted by third parties make sure you give proper credit. 3. Check if you are distributing the correct version of the source code. The source code shipped must be the same source code used to build the binary. 4. Check if you include the source code for any derivative works of the GNU GPL code you are using, not just of the third-party GNU GPL components themselves. 5. Check if you include the scripts used to control compilation and installation. 6. If the toolchain is released and contains tools under the GNU GPL (like the GCC compiler), check if the source code for those tools is also released. Copyright©FSFE. Last changed: :11:04(shanecoughlan) 2012/12/13

產品釋出時所須特別留意的事項 1、確認產品釋出時是否附隨一份GPL授權條款全文，此份文件的附隨散布亦為GPL授權條款的重要義務性要求之一。
2、確認程式原始碼是否附隨產品併行釋出，若您採取嗣後使用者要求後方才提供的作法，則需以一紙正式聲明隨同產品釋出，此份聲明的內容即講述使用者如何向您索取相關程式原始碼的管道，須注意的是、此嗣後單獨提供程式原始碼的作為僅得收求其散布上的工本費用，例如燒錄光碟片及寄送郵資等成本費用。 3、請記得、您並不能僅以片面公布一行連結網址供人下載原始碼，即認為已實踐了GPL授權條款所要求的公開原始碼義務，較傳統穩當的作法是、將此原始碼資料載於有形的散布媒體之上(如CD光碟片)，然後與您的產品同時併行散布；但當然、您仍然可在一定條件下，利用網際網路提供下載的機制來完遂此項義務，與前述不同的分野在於、此時下載連結的說明文件乃是併隨著產品一同傳達至收受產品的後手，其並非任意片面的公告、而是得到產品之人同時可資查照的慎重文件。 4、另外、如您徹頭徹尾皆是利用網際網路提供產品的散布方式，那麼依GPL授權條款規定、您須將產品原始碼的下載連結點置於產品目的標之旁，方便使用者下載完目的碼後若更有需要，可簡易尋得接續原始碼的下載節點。 2012/12/13

Shipping the product: 1. Check if a copy of the GNU GPL license is shipped with the product. 2. Check if a copy of the source code is shipped with the product or that you include a written offer to provide the source code on a physical media like a CD ROM for no more than the cost of production and shipping. 3. Remember you cannot offer a download link to the source code instead of a written offer to ship the source code on physical media. You can supplement the written offer with a reference to a download site. This may reduce the number of requests for source code. 4. Remember that if you distribute binaries over the Internet then you must also host the source code on the same server. Copyright©FSFE. Last changed: :11:04(shanecoughlan) 2012/12/13

產品釋出前的自我檢測 1、確認承包您產品之軟體編寫的上游廠商，是否已經由明示的書面契約、承諾其善盡編寫過程中取用GPL類程式的揭露義務。
2、若承包您軟體編寫的上游廠商、已明示其於編寫過程中採用了部份的GPL軟體程式碼，則您須自此承包商處得到相對應的充足資料，以助您在日後產品釋出時可善盡GPL所要求的各項義務性條款。 3、若承包您軟體的上游廠商認為其編寫的作品與GPL完全無涉或不受拘束，那麼對您更為慎重而有保障的作法是、請此承包廠商簽署相關的保證協定，要求其以書面允諾擔保，若日後此一產品釋出後涉及GPL相關爭議，則相關責任由軟體編寫廠商擔負，意即軟體編寫廠商須允諾在最短合理期間內改正GPL授權不當的爭議狀態，以避免您所釋出的產品受到GPL授權不當爭議的波及。 2012/12/13

Before shipping the product:
1. Check if your purchasing contracts require suppliers to disclose the presence of any GPL software. 2. Check if your suppliers provide all the materials you need to comply with the GNU GPL license. 3. It helps to ensure that if your supplier turns out to not comply with the GPL they agree to rectify the situation in a timely fashion. Copyright©FSFE. Last changed: :11:04(shanecoughlan) 2012/12/13

1、預作產品向性規劃 2、明列軟體清單釐清責任 3、確立程式碼的散布模式
2012/12/13

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

產品交付時：清楚的交付內容自由開源軟體清單 2012/12/13

商業產品上下游流通示意圖 1/4 A 國科會計畫上游公司 B 接受技轉公司 ODM公司 C 品牌公司Ｄ消費者 D 2012/12/13

商業產品上下游流通示意圖 2/4 A 國科會計畫上游公司 B 接受技轉公司 ODM公司 C 品牌公司Ｄ消費者 D 2012/12/13

✘ 商業產品上下游流通示意圖 3/4 自由開源軟體清單國科會計畫上游公司接受技轉公司 ODM公司品牌公司 D A B C Ｄ消費者
2012/12/13

✘ ✘ 商業產品上下游流通示意圖 4/4 自由開源軟體清單國科會計畫上游公司接受技轉公司 ODM公司品牌公司 D 自由開源軟體清單
A 國科會計畫上游公司 B 接受技轉公司 ODM公司 C 品牌公司Ｄ消費者 D ✘ 自由開源軟體清單 2012/12/13

釐清責任在清單上－下游客戶負擔責任不在清單上－自己負擔責任
釐清責任　在清單上－下游客戶負擔責任不在清單上－自己負擔責任　　 2012/12/13

自由開源軟體清單：內容自由開源軟體名稱版本號授權條款全名與版本號相關網址商業利用狀態禁止商業利用？雙重授權？其他說明
2012/12/13

善用自由軟體資訊清單有效降低法律糾紛的風險
葛冬梅在協助處理各式各樣自由軟體授權問題的過程中，常常發現有許多廠商是在接到侵權警告信之後，才開始著手整理產品中所利用到的自由軟體元件，以及清查這些元件是採用哪一份授權條款來授權，這種事後的清整一來是非常耗時費工的，再者，這中間若有損害賠償的費用產生，廠商還可能因此必須負擔額外的金錢支出。其實這些額外的時間、人力與金錢支出，都可透過一些事前的措施來加以預防，並降低被認定為惡意侵權行為的風險，自由軟體資訊清單就是一個簡單而有效的方法。 2012/12/13

技轉商業化過程圖 A 國科會計畫補助型研究計畫 B 接受技轉公司 C 品牌公司Ｄ消費者 D 2012/12/13

技術移轉授權契約 2012/12/13

授權金 X 費用　 V 2012/12/13

技轉費用、技轉金、服務費用、技轉服務費...... 2012/12/13

自由開源軟體技術轉移爭議要點授權金 vs. 技轉金授權時間、對象、地域方面的調整顯名主義方面的要求
專利授權方面的配置(GPL-3.0, Apache-2.0) 2012/12/13

Open Invention Network (OIN)
2012/12/13

© 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. 2012/12/13

openlegal openfoundry
2012/12/13

Ctrl+F: 2012/12/13

OpenFoundry (02) EXT.1474 2012/12/13

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

自由開源軟體在雲端的運用中央研究院資訊科技創新研究中心自由軟體鑄造場葛冬梅法政研究

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: