好有心機的詐騙電子郵件 (scams email)

今天收到一封詐騙電子郵件,跟一般不太一樣的是,內容如下:

Hello Dear  Florence  Ko

Please I want to have a deal with you.

( I am Miss Ehmy Ashima ) I was engaged to a foreign contractor, whom I had a child for ,In the same year he was attacked in Somalia by rebels.

Before the incident happened ,he shipped some refurbished mining machines to a firm in Monrovia on an agreement to be paid after 3 months upon the receipt (which precisely was to be June 2008) before the incident happened.

And ever since that 2008 ,I have have been thinking that the relative would come to us or contact us ,which as a result ,I opted not to contact the firm till I speak with them to discuss about the debt ,which has taken too long to wait for more time as I believe they probably might not know about us.

Due to challenges ,I decided to come to the company ,which I have met their management with a resident lawyer that I hired to assist me .After several meeting ,they demanded a letter of surety from the lawyer to enable them release the money to me but the lawyer is demanding to speak with the family before he can sign for the surety ,and there is no way I can get to the family as I never met with them for the first time and I don’t want the lawyer to know of that.

Please I am craving for your cooperation (by the virtue of your same family name) to stand as a relative to speak as the family representative please ,I am willing to offer 25% of the payment to you as a deal and agreement.

Please help me ;there is no risk of any problem, the lawyer just want to speak with the family member to be sure of their knowledge over my pursuit of the payment before he can sign for the payment to me ,and I don’t want to tarry to connect him to the family to avoid misconception please.

Ehmy Ashima.

閱讀全文〈好有心機的詐騙電子郵件 (scams email)〉

自由開源軟體預設的不附隨保證與擔保特性

本文原刊登於自由軟體鑄造場的法律專欄

在我跟Lucien所進行的企業演講中,通常一開始會先說明自由開源軟體的基本授權特性,而在經過多年的討論與反芻之後,目前我們歸納出來的自由開源軟體授權特性有六項:

  1. 開放程式源碼
  2. 不限制授權對象與使用地域
  3. 不收取授權金
  4. 授權不可撤回
  5. 不附隨擔保
  6. 釋放四大自由給予後手

不過並非每一項特性都有專論文章來說明,此外又或者是即使有相關主題的文章,但是由於早期撰寫文章時,對於跟主題相關內容的掌握度並不夠,所以文章內容並不完整,所以我從2013年11月開始,針對這六大特性來撰寫法律專欄文章,補強過去所有沒有談到的內容,因此2013年11月的「從開放源碼的理想到提供源碼的義務」就是針對第一個特性所撰寫的文章,而2013年12月所撰寫的這篇文章則是針對第五個特性。

接下來幾個月應該還會有這樣的文章出現,也許下一篇會寫跟第三個特性有關的文章吧!

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

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

閱讀全文〈自由開源軟體預設的不附隨保證與擔保特性〉

心情雜記-20131219

Rider-Waite_7Rods

今天是第80天。

從十月開始,心情感受起伏特別大,日子也過得異常忙碌,平日研究之外的演講、會議以及瑣碎事務一項接著一項、川流不息,身體與心靈都在承受著前所未有的挑戰。一根棍子打六根棍子,真的是不容易。不過,還好,關關難過,關關過! 閱讀全文〈心情雜記-20131219〉

自由開源軟體侵權爭端案例文章彙整

近來在整理法律專欄中,跟自由開源軟體侵權相關的文章,也同時將鑄造場網站上相關的新聞報導也做了整理。在鑄造場工作了這麼多年,雖然沒有一案不漏地介紹過所有侵權爭端案例,不過重要的案件都沒有漏掉。只是其中有些文章沒有做後續更新,因此資料仍是舊的,是比較可惜的地方。

【新聞報導】

一、BusyBox 侵權案件(違反GPL)

「Monsoon Multimedia 與 BusyBox 的 GPL 侵害訴訟達成和解」
http://www.openfoundry.org/tw/foss-news/1287

「SFLC 控告 Verizon 違反 GPL 散佈開放源碼軟體」
http://www.openfoundry.org/tw/foss-news/1334

「BusyBox 開發者與 Xterasys 取得 GPL 侵權訴訟和解」
http://www.openfoundry.org/tw/foss-news/1353 閱讀全文〈自由開源軟體侵權爭端案例文章彙整〉

[簡報] COSCUP 2013

我在今年COSCUP簡報的主題是貢獻者契約,早在2009年7月份的法律專欄,我就撰寫過這個主題的文章,不過今年度4月份我的同事兼前輩林懿萱又寫了一篇相關的文章,因此才讓我想要在COSCUP上面談這個主題。

《他人貢獻部份的智慧財產權管理》
http://www.openfoundry.org/tw/legal-column-list/2117-2010-07-15-10-16-56

《淺談貢獻者契約在自由開源軟體之應用》

http://www.openfoundry.org/tw/legal-column-list/8961-a-brief-introduciotn-of-the-application-of-contributor-agreement-in-the-field-of-foss

~~~~~~~~~~~~~~~~~~~~~~~~ 簡 報 資 訊 ~~~~~~~~~~~~~~~~~~~~~~~~~~
pdf檔:檔案下載請至20120803 from Florence T,M. Ko
odp檔:檔案下載請點這裡下載
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 閱讀全文〈[簡報] COSCUP 2013〉

雲圖 (Cloud Atlas)

“I seen too much o’ the world. I ain’t good slave.”
~~ Autua

每個人對於電影的喜好不盡相同,而雲圖正是一部打中我多項偏好的電影:細緻的服裝、豐富的色調、美麗的音樂、交錯跳躍的故事劇情、變化多端的人物臉龐以及對於人性正面進化的樂觀態度,這些元素讓我在看這部片子時,在在感覺到無比的享受。

而這部電影最讓我印象深刻的是黑人奴隸Autua所的一句話:

“I seen too much o’ the world. I ain’t good slave.” (我看過這世界太多的人事物,我不是個好奴隸!) 閱讀全文〈雲圖 (Cloud Atlas)〉

從開放源碼的理想到提供源碼的義務

本文原刊登於自由軟體鑄造場的法律專欄

過去在為商業公司的員工進行教育訓練課程時,都會介紹自由開源軟體具有「開放程式源碼」的授權特性,講久了,卻發現關於這一個特性卻沒有寫過介紹文章,所以才興起了我要撰寫這篇文章的念頭。不過寫完之後才發現,這篇文章不僅是在釐清「開放源碼」與「提供源碼」這兩個概念,也順便將自由軟體到開放源碼的歷史做了一個簡要的介紹,所以若是有人想要快速了解從四大自由到開放源碼間的歷史由來,本文可以當作一個入門的文章來閱讀。

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

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

淺析自由開源軟體專案與其個別元件授權條款之差異

本文原刊登於自由軟體鑄造場的法律專欄

這是一篇有趣的文章,文章靈感來自於近日跟一位業界工程師所聊到的一段話,當時他表示有些自由開源軟體專案的授權還蠻複雜的,因為專案整體標示的是一種授權,但是裡面卻可能包含許多其他不同授權的程式碼,一不注意的話,可能就會誤解授權義務規定,而有侵權利用的狀況產生。這讓我想到,前一陣子處理的諮詢問題中,剛好也有開發者誤認元件授權條款跟專案整體授權條款一樣,最後必須置換元件的實例,因此而有了撰寫這篇文章的想法。

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

有經驗的開發者在利用自由開源軟體時,會主動了解軟體專案所適用的授權條款,以遵守授權義務規定的方式來應用自由開源軟體。但是,不少開發者可能容易忽略的是,有些自由開源軟體專案裡,還可能包含或附帶與主專案框架不同授權條款的元件,若是應用專案的方式涉及到這些元件的話,便可能會在實際應用上產生完全不同的效果。

【個案實例】

1、關鍵引擎採用 LGPL-2.1 授權的 GPL-2.0 專案:VLC

這幾年很受到歡迎的多媒體播放器與其框架專案VLC,就是一個很顯著的例子。VLC專案整體採用 GPL-2.0 授權,但是為了讓 VLC 可以持續地被應用在 Linux、Windows、Mac OS X、Android 等不同平台上,該專案的開發者在 2011 年決定,要將 VLC 的關鍵引擎改用 LGPL-2.1 來重新授權(註一),這是因為 LGPL-2.1 對於函式庫的利用方式有著較為彈性的規定,使用者只要在合於授權規定的方式內,透過函式庫既定的介面來與其互動存取資料,則新開發出來的軟體,就可以適用非 LGPL-2.1 條款的方式來授權散布,甚至必要時也有機會採取封閉源碼的方式來授權新軟體。因此當開發者僅利用到 LGPL-2.1 函式庫或程式碼的話,就有著根據 LGPL-2.1 授權規定來開發私有軟體 (proprietary software) 的彈性空間(註二),但若是開發者確實是利用到整個 VLC 專案的程式碼,包括 LGPL-2.1 授權的函式庫,以及 GPL-2.0 的播放框架時,便可能必須一體遵守 GPL-2.0 的規定,因此時 GPL-2.0 授權的程式碼,也一併經引用而成為後續衍生專案不可分割的一部份了。

閱讀全文〈淺析自由開源軟體專案與其個別元件授權條款之差異〉

試論「公眾授權條款」之名詞辨析與基礎概念

本文原刊登於自由軟體鑄造場的法律專欄

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

接觸過自由開源軟體 (Free and Open Source Software)、創用CC 授權條款 (Creative Commons licenses) 與相關領域的人對於「公眾授權條款」這個詞應該都不陌生,因為在許多場合或者文獻資料中常常都會看到它。但是,「公眾授權條款」這樣一個被廣泛利用的中文辭彙,其實並沒有被清楚定義,甚至也沒有人嘗試加以描述或說明,因此筆者透過這篇文章,嘗試對其內涵進行整理、歸納,並且給予「公眾授權條款」一個基礎的解釋概念,讓未來有需要利用到這個詞的人,有一個參考的依據。

由於本篇文章將會綜合討論不同領域的授權條款,以及比較著作權與專利權的不同之處,這些條款的內容與權利的態樣均不完全相同,但囿於篇幅,筆者無法詳細介紹其中所有的相關內容,因此在相關段落中,還請讀者自行參閱引註當中的延伸資訊,在此先行說明。

閱讀全文〈試論「公眾授權條款」之名詞辨析與基礎概念〉

利用自由開源軟體元件開發雲端應用專案

本文原刊登於自由軟體鑄造場的法律專欄

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

雖著網際網路的進一步發展,近年來雲端運算成為一鼓新興的潮流,無論是大型的商業公司或小型的資訊服務業者,乃至於個人工作室,都乘著這鼓潮流,嘗試開發網路應用程式或提供相關的商業服務。與一般的軟體開發專案一樣,在開發網路應用程式或線上服務平台(以下統稱這些應用程式與服務平台的開發專案為「雲端應用專案」)的時候,也可能面對部份專案內容無法對外提供程式源碼 (Source Code) 的情況,例如雲端應用專案中某一部份的程式碼,因為受到第三方保密協議的拘束,所以不能對外提供源碼與相關資訊。這樣的專案若仍想要利用自由開源軟體元件來開發的話,那麼選擇哪些條款授權的元件,才不會造成未來應用時產生必須提供程式源碼的衝突,將是開發過程的一項重點。因此,本文將針對常見的自由開源授權條款(註一),說明相關的義務規定,據此建議雲端應用專案可以選擇哪些條款授權的元件,以避免無法提供源碼的專案產生授權義務上的衝突。

閱讀全文〈利用自由開源軟體元件開發雲端應用專案〉