> For the complete documentation index, see [llms.txt](https://willh.gitbook.io/it-startup/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://willh.gitbook.io/it-startup/14/16.md).

# 面對軟體侵權的事件

**軟體開發需要花上大量的時間與精力，並搭配不斷的測試與調校才能孕育出一個好的產品，我們在創業的第一年就遇到軟體被盜用的事件。**

![](/files/-M6Eeyiud-Dhx05fMlGj)

圖片來源 <http://bit.ly/1VH67re>

說實在的，軟體真的不好賣，我們真的想了很多方法行銷，但礙於沒有行銷經費，所以只能再想其他法子。由於我們的「繁簡轉換」軟體必須安裝在伺服器上，我已經將安裝程序簡化許多，但光是請客戶「安裝」的動作，有時候就會碰上許多釘子。最後我們想到直接在線上提供免費試用，客戶只要直接到我們網站輸入任意網站的網址，我們就能自動將現有「繁體網站」轉換成「簡體版」，做了這層改變之後，確實試用的頻率大幅增加，我們也增加了許多新客戶。

我們不是什麼大公司，要是有成千上萬的人來我這裡輸入網址試用，我去哪裡生機器或頻寬提供服務呢？但另一方面想，我們公司其實還很小，沒什麼人知道，應該不會有太多人來試用，所以就在忐忑不安的心情下開放試用。這段幾個月的試用時間確實增加了不少試用人口，但試用僅僅只是試用，每個網站頂多看個幾頁看到感覺就行了吧，而且我們的授權條款當時也寫得很清楚，客戶不能直接把「繁簡轉換」試用的超連結放到他們網站上，否則流量一貫入，我們主機肯定掛掉。

不知道從何時開始，我們的主機開始變得不太穩定，經常當機，我平時不會上去「試用」我自己開發的線上試用版，反而是有熱心的客戶跑來寫信跟我們說我們的線上試用無法運作，我收到通知後才會去處理，這段時間，我不知道有多少業務機會就此流失。當時的我，其實大部分心力還是放在「專案開發」上，產品的部分我不是特別用心注意，畢竟產品已經開發完成，在穩定運作的情況下，我的時間就一直擺在其他地方。

起初我並沒有想到是流量暴增所致，只覺得自己的程式可能有問題，但幾千行的程式重看了幾遍，不覺得哪裡有異常，怎麼主機會每幾天就當機一次呢？到了後期，主機每天都在當機，但我還是從程式面查不出原因，便從程式面分析轉往系統面進行分析，後來發現我們伺服器的 Apache Log 超級大，有十多 GB 這麼大！(當時我們的硬碟才 18GB 而已)

當看到異常狀況後，開始分析這些流量到底從哪裡來，這才發現我們的「線上使用服務」被別人掛在官網上，供他們的大陸用戶直接使用。這個「他們」不是甚麼名不見經傳的網站，而是當時非常知名的「滾石可樂官網」。這讓我們十分不解，一間流量如此龐大的網站，怎能公然盜用我們的線上試用服務，他們難道不知道光是他們一個網站就可以把我們的伺服器打趴嗎？況且已經用了好幾個月的時間。

大約在這次事件的半年多前，滾石公司才熱鬧參予反盜版活動，現在卻發生未經同意直接使用盜版軟體的侵權事件，這確實有點諷刺。我們開始商議各種可能性，要提告？要和解？息事寧人？首先，我們是一個很小很小的公司，跟大公司走法律途徑，搞不好還沒打完官司，公司就被律師費給拖垮了。息事寧人？似乎也太便宜對方了，畢竟他們已經用了幾個月的時間，說算了，就算我同意，其他夥伴可不見得同意。最後，似乎和解是個不錯的解決方案。

接著我們開始嘗試接洽對方，但對方確實是大公司，我們不知道要找誰，也很難找到網站的窗口，最後好像是透過存證信函才得到對方回覆的。當時的我才 24 歲，年輕又沒經驗，洽談和解這件事，我完全沒有信心。我的夥伴因為大我十多歲，歷練相對比我豐富很多，他便一肩扛下這個重任，讓我從原本緊繃的情緒舒緩許多。

和解洽談的過程，我並沒有參與，都是我的夥伴去對方公司談判，但經他回來轉述，談判的過程不是很愉快，主要是對方沒有和解的誠意，而且完全沒有賠償的打算，只想用原本產品的定價買下我們產品的使用權，還不斷推說這是工程師的「無心之過」，以致於和解談判一直沒有結果。我們創業團隊沒有人遇過這類問題，在討論的過程中，也經常談到鴉雀無聲，因為他們就不賠，我們還能怎樣？說真的，我們告不起。

後來，有人提議找台北市議員解決，因為議員都會有選民服務，都有服務處可以處理民眾需求。我剛聽到時只覺得很新鮮，沒想到也能這樣。隔天，他們就開始去找議員，問了一位、兩位、三位，都沒人有興趣，直到最後終於有一位議員說他有興趣處理我們的案件。我們聽到都非常開心，便把手邊所有的資料全部備妥，去找議員討論此事。很可惜這次我依然沒有參與，都是我的夥伴隻身前往。

我的夥伴回來之後，非常開心的跟我們轉述議員對此事表達強烈意願，且打算開記者會公布這件事，我們聽了都無不振奮。隔天，開記著會的消息傳到了對方公司高層的耳裡，便積極找我們出來二次談判。由於開記者會可不是小事，對方也不敢大意，談判的過程還帶了「工程師」過來，還讓工程師在我的夥伴面前哭泣，當下道歉認錯，說是自己不小心才犯錯的，還說工程師要負擔一部分賠償費用。夥伴說，他當下確實有點不捨，回來徵詢我的意見，看我覺得該怎樣處理。

這種問題我哪知道怎樣處理，只覺得讓夥伴決定就好，其他我沒什麼意見。我的夥伴決定，到議員那邊商談撤銷記者會的事，但誰知道記者會的消息已經發給三十多家媒體，已經無力收手了。既然木已成舟，在怎樣內疚也沒用，只好坦然面對。

記者會當天，由我的夥伴負責出席，而我在旁邊觀看，這場面好不壯觀，三十多家電視與平面媒體，都大篇幅報導滾石可樂的軟體侵權事件。由於輿論與媒體大多站在我們這邊，就談判的角度來看，滾石可樂已經暫居下風，和解的談判也就更加順利。因為他們不想事件再度擴大，所以很快的，這件事也圓滿落幕，我們也得到我們應得的和解金。(至於確切數字我必須保密)

這次的事件，讓我們學到很多，尤其是在法律與媒體方面。雖然官司沒有打，但深切的體會到，法律真正保護的不是守法的人，而是懂法律的人。我們沒有合作的律師，對方就「吃人夠夠」(台語)，知道我們不敢告，所以談判的態度十分強硬。媒體，真的威力很大，當時有兩家媒體為了做平衡報導，把我們寫得有點負面，這也讓我們覺得有點恐懼。覺得若要真的上媒體，最好真的知道輿論會站在我們這邊，否則千萬不要輕易嘗試。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://willh.gitbook.io/it-startup/14/16.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
