薛先生您好，
是這樣的、我想進一步了解的是，您所說的「VLC PLAYER UI 部份」，會是架構圖裡面哪一部份的元件？
因為、Open Source領域裡不乏以中間隔層的方式來區隔GPL授權拘束性的案例，這件事如果是由商業公司來做，有時候會被自由開源軟體社群質疑是一個規避行為，然而、這件事若是由原社群開發專案來主導，那就表示該社群是共識性的提供一種GPL授權拘束的例外條件(exception)，也就是說、只要遵守這個中隔機制，則該專案底層的授權拘束性便不至於影響到應用層。例如您舉的libVLC就很可能是這樣的設計！
LGPL在授權拘束性方面的原則是這樣，如果是動態連結、原則上不會開啟，如果是靜態連結、將其他元件與其寫成一個執行檔，則會例外開啟；那麼、如果完全依照LGPL授權函式庫(library)預設的interface來與其互動的話，一般來說都會認定這就是動態連結，完全不會啟動這個函式庫的授權拘束性，也就是說、Applications只要透過libVLC原來已經定義好的interface來與其互動，就不會有開啟LGPL授權影響的疑慮。
然而、這種狀況是「確定該Application是僅單純透過既成interface與libVLC」互動的情況，如果Application有跳過libVLC直接與VLC PLAYER其他部份溝通的行動的話，那就不能保證這樣的中隔機制是可以被接受的。例如Android Phone上面的Application透過Android Framework來與Linux Kernel溝通，這些Applications因為中隔機制都沒有要求一定得受到Linux Kernel的GPL授權所拘束；然而該Android Phone上面若有硬體driver是直接與Linux Kernel溝通的話，則該driver還是會被要求應該GPL授權的方式釋出。
約略的授權關係是這樣，如有後續或衍生的疑問，再麻煩您補充資訊了。
謝謝！
順心健康
20120620 1105 自由軟體鑄造場 林誠夏
嗨你好
我是中央大學的學生,由於我們要利用VLC player 編寫商用軟體,
其中VLC PLAYER(UI 部份)是走GPL授權,libVLC是走LGPL授權,
他的架構圖在附件裡或可以連結至下面的網址,
http://www.videolan.org/vlc/libvlc.html
主要是想請問如果我們的軟體是有某一部分的功能會用到vlc player,
- 如果我們用vlc ui + libVLC (都用動態連結) , 請問這樣是BASE ON GPL還是LGPL
- 又如果以上的做法是base on GPL,所以如果只想要BASE ON LGPL,是不是UI要自己寫?
- 那如果在UI自己寫的狀況下,參考VLC UI source code的部分這樣會牽涉到GPL授權嗎?
煩請解答
謝謝
國立中央大學 資訊工程所 薛浩哲
無線網路暨多媒體實驗室
電話: (03)422-7151 分機 35352
信箱: lp3109@gmail.com
National Central University Computer Science and Information Engineer
Sean Hsueh, Hao-Che
Wireless Networks and Multimedia Lab
telephone: (03)422-7151 ext. 35352
E-mail: lp3109@gmail.com