※ 引述《[email protected] (大头)》之铭言： > 最近看了一些文章,认为有其逻辑性, > 想跟大家讨论一下, > 就是在GPL的规则中,硬体厂商的driver似乎不在此限制,也不需要公开source code? > 听到的有些意见是,目前GPL对於硬体的driver是睁只眼闭只眼的态度 比较简单的思考方式是，该硬体厂商的 driver 是「如何被撰写出来」的，如果能证明 是「独立创作」，一切好谈，反之，就得周旋在模糊地带与考验脸皮的厚度。 Copy-n-Paste programming 俨然是当今复杂度极高的软体产业，最常见的「设计途径」 ，而一个能运作的 Linux kernel module，在没有充分的参考文件的前提下，往往得 东抄西改 (自 GPL'd source code)，才能拼凑出一个堪用的 driver。这样的举动， 相当明显，是 GPLv2 所描述对程式与其演化而来的创作，自然递回性地受到影响。 为了避免争议，Linux Kernel 对 exported symbol 提供两种宣告方式，即 EXPORT_SYMBOL 与 EXPORT_SYMBOL_GPL 两个巨集定义，从而限制与强调 tainted kernel module (厘清授权条款不相容议题) 的存在。若您真要撰写 Proprietary kernel module，事实上，还得回避使用以 EXPORT_SYMBOL_GPL 宣告的 function / variable， 否则，作为一个使用者，可轻易得知 tainted kernel module 的讯息，从而质疑系统 设计的合理性。 「行为」才是这一切授权议题的 checkpoint。 > 因为期望Linux能支援更多硬体(得有人来写driver,使其能在Linux kernal运作) > 但对硬体厂商而言,公布source code也似乎等同公布硬体规格, > 有此一说是,这对硬体厂商似乎是个麻烦? 真的办法的厂商，还是能找到一个 trade-off 的途径，比方说可以参考 nVIDIA 的 Linux Kernel driver + Xorg driver 的实做规范与隔离途径。 > 发觉这些厂商的driver是close source,而且对於open这件是非常谨慎... > 但实在不好意思开口问这件事情,不知道各位先进有兴趣能否提出自己的意见 > 交流交流,谢谢 毕竟覆水难收，当然得谨慎些，不过，本来就该多交流讨论，才会成长进步 :) -- Jim Huang aka "jserv" Planet OrzLab: http://orzlab.blogspot.com/ website: http://jserv.sayya.org/ blog: http://blog.linux.org.tw/jserv/ -- ※ Origin: SayYA 资讯站 <bbs.sayya.org> ◆ From: 118-169-99-76.dynamic.hinet.net