兩點關於增加信任的建議

[caasi]

我覺得 #16 的斷網功能很棒，的確可以增加大眾對 recall2025 的信任，除此之外還有一些事也能增加其他程式開發者對網站的信任：

1. 新增滿足團隊需求，同時對開源開發者來說比較熟悉的授權聲明
   現在團隊寫著「本 repo 之設計與程式碼，為本團隊所有，僅供查看，禁止未經授權的分發或商業用途。所有權利受法律保護，違者必究」，也許可以採用 Creative Commons 的 CC BY-NC-ND 聲明，表示使用這個網站軟體時必須標示原作者、不可作商業用途、不可改作。當然這無法解決壞人複製偷改的問題，所以有第二點。
2. 建立公開的 CD 佈署機制
   例如使用 GitHub Actions ，讓其他開發者可以清楚看到這個網站，的確是自動佈署到 recall2025.ourtaiwan.tw 上，這樣除了斷網離線使用外，只要認明 ourtaiwan.tw 網址，就知道這個網站是可以信任的。

熱衷公民科技的各路工程師都是台灣同路人，希望能儘快消弭誤會，一起前進。

[imtaiwanese18741130]

您好，謝謝您的來信。

拍謝最近被客服跟訊息大量轟炸，回應有點 delay。

關於第一點，本團隊目前的授權有其原因，
沒套用常見的開源授權，就是不想讓「在臺親共勢力」改來對付自己人。
當時要衝上線其實沒花時間好好研究可以使用什麼既有授權方式。

您提到的是 https://creativecommons.org/licenses/by-nc-nd/2.0/tw/deed.zh-hant 對嗎？
這個授權方式如果能夠符合上述需求的話，那麼我們完全沒有問題喔！
我們會好好把授權看完，確認無誤的話就會修改授權方式。

第二點於昨日已請 DevOps 著手囉。

各路努力的目標，都是希望大罷免能順利成功。
謝謝您，一起加油！

[caasi]

謝謝您的回信，

您提到的是 https://creativecommons.org/licenses/by-nc-nd/2.0/tw/deed.zh-hant 對嗎？
這個授權方式如果能夠符合上述需求的話，那麼我們完全沒有問題喔！
我們會好好把授權看完，確認無誤的話就會修改授權方式。

是的，但是台灣站不知怎麼停在 CC 2.0 ，可以從 Creative Commons 官方的 About CC Licenses 挑選 4.0 版本的授權。

第二點於昨日已請 DevOps 著手囉。

GitHub Actions 也能設定隱藏 CD 流程中用到的機敏資訊，很好用。

各路努力的目標，都是希望大罷免能順利成功。
謝謝您，一起加油！

一起加油！

[danny0838]

開源專案有個麻煩的點是如何處理貢獻者的權利義務問題。如果用 CC BY-NC-ND，那麼所有 fork 版本庫、修改程式碼並提交 PR 的開發者，可能都會有踩到「禁止改作」、「禁止分發」的線的疑慮。

附上 ChatGPT 的說法：

開源軟體是否適合使用 CC-BY 授權取決於你對該軟體的目標和使用場景。

CC-BY（Creative Commons Attribution）授權是一種要求使用者給予原作者適當署名的授權方式，適用於許多創意作品，如文檔、藝術作品和音樂等。然而，對於開源軟體來說，通常不推薦使用 CC-BY 授權，原因如下：

1. 與開源精神不完全匹配：開源軟體的授權通常專注於保證用戶可以自由地修改、分發和使用軟體，而許多開源授權（如 MIT、GPL）更注重代碼的自由使用和共享。CC-BY 授權雖然允許用戶修改和重新分發軟體，但它缺乏像 GPL 或 Apache 授權那樣對衍生作品的要求，例如要求衍生作品同樣開源或要求提供源代碼。

2. 可能引發兼容性問題：如果你的開源軟體使用 CC-BY 授權，它與其他常見的開源授權（如 GPL、MIT 等）之間的兼容性可能會成為問題。這是因為不同的開源授權對於修改、分發和重用的要求不同，可能會造成一些法律和技術上的衝突。

3. 不適用於專有軟體的商業化：CC-BY 允許商業使用，但它沒有提供明確的條款來處理商業化衍生作品的使用，而像 MIT 或 Apache 2.0 這些開源授權通常會更明確地處理商業使用的問題，且不會限制其他開發者在相同項目上商業化。

總結來說，開源軟體選擇授權時，CC-BY 授權並不是最佳選擇。一般建議選擇更專門為軟體設計的開源授權，如 MIT、GPL、Apache 2.0 等，這些授權條款能更好地支持開源社群的合作精神、保護使用者的權利並保障源代碼的開放性。

開源軟體使用 CC-BY-ND（創用CC - 署名 - 不得改作）授權並不常見，這主要是因為這種授權條款與開源軟體的核心理念有些衝突。

為什麼不建議開源軟體使用 CC-BY-ND 授權？

1. 不得修改：CC-BY-ND 授權要求使用者不得對作品進行修改或製作衍生作品。開源軟體的基本特性之一就是允許使用者查看、修改、分發和改進原始代碼。如果使用 CC-BY-ND，使用者就無法對軟體進行修改或創建衍生作品，這與開源軟體的精神相違背。

2. 限制衍生作品：開源軟體強調的是社群合作和創新，軟體開發者通常希望他人能夠基於他們的代碼進行擴展和改進。CC-BY-ND 授權的「不得改作」條款會使得這一點變得不可行，因為衍生作品的創建被禁止。

那麼開源軟體適合使用什麼授權？

開源軟體一般會選擇以下幾種授權方式：

• MIT 授權：簡單、寬鬆，允許使用者自由修改和分發代碼，甚至可以用於商業用途。
• GPL（GNU 通用公共許可證）：要求修改過的代碼必須公開源代碼，保證軟體的自由性。
• Apache 2.0：與 MIT 類似，提供更詳細的條款，保護貢獻者免受專利訴訟的威脅。
• BSD 授權：類似於 MIT，但更注重對貢獻者的法律保護。

結論

如果你的目的是促進開源社群的合作和創新，使用 CC-BY-ND 授權可能不太適合。你可以考慮其他更適合開源軟體的授權，如 MIT、GPL 或 Apache 2.0 等，這樣能夠更好地支持社群的發展和創新。

[caasi]

@danny0838 看了一下別人的討論與官方建議，看來會擋貢獻的正是 ND 那部份。考慮到 Taiwan Dreamer 團隊有『不想讓「在臺親共勢力」改來對付自己人』這種需求，就算換用 GPL 等授權也沒法滿足。

如果從自由軟體的角度看，四大自由：

0. to run the program
1. to study and change the program in source code form
2. to redistribute exact copies, and
3. to distribute modified versions.

也和團隊現在的需求不相容。那可能不必稱為開源專案，但一樣放在 GitHub 上，配上合適的授權就好。

查了一下有沒有其他 repo 用上 CC BY-NC-ND ，發現 ArchLinuxTutorial 有過一串討論。但沒有發現其他好解法。

[danny0838]

關於『不想讓「在臺親共勢力」改來對付自己人』，我想主要是擔心這些程式碼會被拿去量產假連署網站，但可能也沒那麼重要：

1. 現在早就有其他假網站了。當今只要丟 AI 就可以輕易改寫，有心人可以輕易生出外觀、功能極其相似，但程式碼明顯不同，法律上難以被認定為此專案改作的作品。更別說有心這樣搞的大多會透過境外網站等方式操作，就算理論上可以被認定為侵權，實務上也很難追究，約束力和嚇阻力相當有限。
2. 罷團及貴團隊一定都會提醒大家使用你們認證的網站，勿輕信其他不明網站，否則後果自負。

如果可以放下這點，那麼比較省事的做法是直接挑一個適合的 GPL-like 的 copyleft 授權，基本上允許其他開發者重製、修改、分發程式碼，但要求必須以同樣方式開源授權，讓開發者能放心貢獻程式碼，且防止私下、閉源的濫用（也就是說，如果有心人用這些程式碼改作出一個假連署站，他還是必須公開程式碼，否則會違反授權條款）。我個人是偏向建議這樣做就好，比較能解決燃眉之急。

如果還是無法接受，那麼貴團隊就得花些心思寫出明確的授權方案，大體上大概是 copy 類 GPL 的授權條文再做一些客製化，例如：

1. 允許重製、分發、改作原始碼，但必須開源（即類 GPL 相關條文）
2. 允許用於部署本地版本
3. 不允許用於部署線上服務，除非取得貴團隊授權

但要面面俱到、避免潛在矛盾與不明確，可能需要大量的相關研究（畢竟那些類 GPL 條文都是許多專家研究多時的），在目前有時間壓力的情況下會很辛苦。

而如果維持現狀或擱置太久也不好，因為按照現有的授權寫法，貢獻程式碼的開發者都踩在「未經授權分發」的侵權紅線上。雖然著作權是告訴乃論，只要團隊不追究就好，但這樣讓人容易踩線及有所擔憂的情況應該不是大家樂見的。

[imtaiwanese18741130]

『不想讓「在臺親共勢力」改來對付自己人』

目前另外一邊也開跑罷免了，會改的人，某些檔案改一改就可以快速啟動。
雖然用 AI 就可以寫，但還是要花時間測、調整。
團隊不想讓他們免除這些門檻，拿到現有整個應用情境的流程成果，這裡指的不單是應用服務本身。

團隊有密切注意網路應用的活動，如果另外一邊也出現類似的應用，
經查為本專案的修改發布，那麼團隊一定告。

如果他們要用 AI 寫 Code，那就讓他們自己慢慢弄。

[danny0838]

瞭解，是我想錯方向了。

如果是這樣，GPL 確實不太可行。那接下來就看團隊是否打算把授權範圍寫得更清楚，以減少潛在開發／貢獻者的顧慮。