如何闭源项目 并调用 lgpl 开源项目

  • 参考：

  • 回答引文

    Situation: Your own C / C++ source code using an unmodified LGPL library to produce a commercial product (with closed source code) that you can distribute to customers (for a fee).

    Questions and Answers: Q1: Can the LGPL library be used in that situation? A1: Yes, if you comply with the license requirements. Note that much of the license compliance is not in the building (or your use) of the application but in the distribution [LGPL 9] of the LGPL library [primarily] and your application [secondarily].

    Q2a: What is the implication of static linking? A2a: You need to comply with the license requirements. Eban Moglen in http://www.spinics.net/lists/xf/msg02311.html indicates that you are producing a "derivative work" of the code in the library. In the United States the US Copyright Office states at http://www.copyright.gov/circs/circ14.html A ?derivative work,? that is, a work that is based on (or derived from) one or more already existing works … [copyright statements]. Both of those statements are pretty clear so section 6 of the LGPL applies. Note that you can distribute (6a) … [your work] as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library You can thus distribute object files (and protect your source code) and still comply with the requirements of the LGPL.

    Q2b: What is the implication of dynamic linking? A2b: That is pretty much up to you. You can decide to…

    • build the application (with your copies of the library),

    distribute that application without the library and expect to have users provide their own copy of the library. In this case - YOU are not distributing the LGPL library and thus are not bound by the distribution terms of the LGPL license.

    • build the application (with your copies of the library), and

    distribute [or make available] two separate packages o your application (binaries only) o the matching LGPL library (binaries and source code) In this case, I strongly suggest you clearly document what you did to produce the LGPL library so [you and] others can reproduce it to confirm your compliance with the LGPL terms. I also suggest you distribute the two items separately so it is clear you are not producing a "derived work" of the library.

    If you are targeting for a specific system configuration (e.g., Fedora Core 3), I suggest an approach like the first one since it is much less likely to cause any possible problems with compliance. The second one is more appropriate if you want to support a range of configurations (and perhaps want to reduce support problems due to "almost compatible" libraries).

    ….

    • 动态链接

      • 分发方式

        • 可以不放入 lgpl 动态库文件

          • 让用户自己获取 lgpl 动态库文件
          • 这样 –> 不必 使用 LGPL 证书

        • 分别提供两份 文件

          • 两份文件

            1. 自己的库文件等（binary only, 仅二进制文件）

            2. LGPL 库文件等（binaries and source code）

              • 必须包含 lgpl 库的源码，无论任何方式传输给用户
              • in one of the ways for which the LGPL provides
          • 最好分开分发，说明自己做的不是相应 lgpl 库的 lgpl 衍生品（derived work）

    • 静态链接

      • 即：制作 lgpl 衍生品（derivative work）
      • 需要以 LGPL 发布

      • 使用方法

        • 方式一

          • 制作封装器

          • 封装器分发

            • 发布 源码

          • application 文件

            • 发布 目标文件

              • 所有 直接或间接调用 封装器的程序

            • 源代码

              • 可以不用发布

        • 方式二

          • 完全开源