一個閒聊、發牢騷、無病呻吟的個人網誌
此篇文章原載於自由軟體鑄造場電子報第185期。
部份的自由開源軟體專案開發者，慣常表達出其嫌惡軟體專利 (software patent) 的立場，因為若是任由軟體專利制度發揮到極致，很可能會直接扼殺自由開源軟體未來的接續發展，然而、近年許多跨足自由開源軟體商業加值應用的產業公司，也慣常的會透過專利申請的手段來保障其商業優勢，此種專利申請模式、已經是在業界行之有年並且體系性的被固定維持，若說是為了因應自由開源專案的應用而要其突然式的改弦易轍，亦有現實上的困難。有鑑於此、本文要討論的議題是，從軟體社群與產業公司這二個不同的立場出發，觀察其對於軟體專利反對與認同、弱化與強化不同態度之間的理由與作法，並透過這些資訊的分析，協助國內自由開源軟體專案的社群開發者與商業應用公司，能更深入了解自由開源軟體所涉及的專利問題與可能的解決方式。
Continue reading “20111103-備位啟動的自由開源專案軟體專利"
GPL 類別的授權程式，最為人著稱的特性便是其「牽一髮而動全身」的授權拘束性（License Inheritance，註一）。所謂的「授權拘束性」白話來說，指的是當使用者將 GPL 授權的程式碼抄寫到自己的軟體專案時，如果抄寫程度佔專案程式碼的比例很大，或是此一 GPL 授權元件提供了專案的核心功能，並且專案的其他元件在互動上亦無法與其分割，則整個軟體專案便會一體被視為該 GPL 授權元件的衍生著作，嗣後使用者如果再行散布這個軟體專案，便僅能適用 GPL 的授權方式來進行釋出。而由於近年來自由軟體元件被產業化利用的比率愈見頻繁，因此授權拘束性所帶來的爭議也愈來愈受到重視，本文便是針對這個議題，先依著作權法的預設說明、再照 GPL 授權條款的文意解釋，接著舉 Linux Kernel 的實際運作狀況佐證，一步步抽絲剝繭的分析 GPL 授權程式在衍生程式方面的判定標準，及此標準在軟體元件的連接關係 (linking) 上，所可能擴散的拘束性範圍。
以自由軟體授權元件來加速產品開發已漸成時代趨勢，但許多著名的自由軟體授權條款皆帶有 Copyleft（註一）性質的授權拘束性，其拘束散布這些自由軟體授權元件目的碼（Binary code）及其衍生作品（Derivative Works）者，亦有義務一併提供該元件的原始碼（Source code）予收受程式的後手，所以連帶的要求散布者亦需盡相當程度的「標示義務」。
所謂的「標示義務」是說，散布者在散布該自由軟體授權元件的當下，須得開宗明義的將該元件的授權狀態提示予後手知悉，並應進一步說明該元件原始碼的取得途徑給後手知道。以使用率非常高的 GPL 授權條款為說明範例的話，其要求內含 GPL 授權元件的產品釋出時，皆需要有個顯著清楚的標示，說明該產品中哪些部份是內含 GPL 授權程式碼的元件，並進一步告知使用者有取得該元件原始碼的權利，以及後續取得這些原始碼的方式。這樣的理論說來簡單，但實際上國內外精準完成此項義務的廠商並不多見，所以以下即以 gpl-violations.org 所撰寫的「商用常見問答集（註二）」為說明基礎。