Memahami implikasi LGPL pada #include

Question

Saya bertanya tentang penautan dinamis di C ++ di stackoverflow (https://stackoverflow.com/q/64039902/14321464), namun, saya tertarik dengan tanggapan tentang keinginan saya untuk tetap membuka kode sumber saya oleh LGPL copyleft. Saya sendiri telah menanyakan hal ini dan mencarinya selama berhari-hari di sini di stackexchange, membaca banyak klarifikasi yang dibuat oleh berbagai tim (seperti dari Teems:http://teem.sourceforge.net/lgpl.html), dan berkeliling mencari tahu. Inilah yang saya pahami sejauh ini:

1. Jika saya menulis dan mengkompilasi kode sumber dan menautkan pustaka LGPL secara statis (melalui .a di Linux atau .lib di Windows (... mungkin? Saya tidak yakin apa yang setara dengan file .a di Windows)), saya terikat untuk setidaknya menyediakan file keluaran (.o) dari kompilasi kode sumber saya sehingga orang dapat menggunakan linker pilihan mereka untuk menautkan kembali dan mengkompilasi file .o menjadi file eksekusi akhir yang dapat dieksekusi menggunakan perpustakaan pilihan mereka.

2. Jika saya menulis dan mengompilasi kode sumber Anda dan menautkan pustaka LGPL secara dinamis (melalui .so di Linux, atau .dll di Windows), dan jika saya memutuskan untuk mendistribusikan kembali file .SO sebagai bagian dari distribusi perangkat lunak saya, maka saya harus menyediakan sumbernya kode pustaka LGPL yang sedang digunakan dan didistribusikan (saya berasumsi, hanya dengan hosting sendiri, saya mungkin cenderung hanya mengemas kode sumber sebagai bagian dari distribusi).

3. Jika saya menulis dan mengkompilasi kode sumber saya dan menautkan pustaka LGPL secara dinamis (melalui .so di Linux, atau .dll di Windows), dan hanya menyatakan bahwa untuk menjalankan program ini pengguna harus memperoleh pustaka LGPL sendiri, maka kode sumber tidak perlu disediakan untuk pengguna akhir. Saya hanya perlu menyatakan bagaimana dan di mana file-file itu perlu ditempatkan agar program dapat berjalan.

Dan setelah membaca LGPL v2.1 dan LGPL v3 bolak-balik, saya masih memiliki 2 pertanyaan di kepala saya:

1. Pertimbangkan kasus ini: pustaka LGPL v2.1 menyediakan kumpulan file .so / .dll, serta folder penyertaan yang berisi semua file .h (header) yang berhubungan dengan .so / .dll (menjelaskan semua struktur, kelas, konstruktor dan destruktor, dan semua deklarasi fungsi dalam kompilasi .so / .dll).

Sejauh yang saya pahami, penautan dinamis berarti bahwa program harus dapat dijalankan (baik melalui terminal menggunakan ./( nama yang dapat dieksekusi), mengklik dua kali pada yang dapat dieksekusi, atau beberapa bentuk lain dari menjalankan yang dapat dieksekusi sebagaimana dimaksud oleh host Operasi Sistem) dan masih dapat berjalan bahkan tanpa kehadiran .so / .dll (dengan memunculkan layar kesalahan atau bahkan menutup sendiri secara paksa).

Jadi, dalam hal ini, pertimbangkan contoh ini:

sampleo.hpp

#IFNDEF SAMPLESO_HPP__
#DEFINE SAMPLESO_HPP__

struct carDesc
{
    const char *model;
    int prod_year;
    int wheel_num;
    const char *license_plate;
    const char *colour;
} car;

carDesc fillCarID(void);

sampleo.cpp

#include "sampleso.hpp"

carDesc fillCarID(void)
{
    car.name = "Ford Fiesta";
    car.prod_year = 2014;
    car.wheel_num = 4;
    car.license_plate = "D 1234 ABC";
    car.colour = "Midnight blue";
    
    return car;
}

dan keduanya dikompilasi menjadi libsampleso.so (g ++ sampleso.cpp -fPIC -shared -Wall -ldl -o libsampleso.so). Saya kemudian mendistribusikan kode ini sebagai LGPL v2.1 dengan libsampleso.so dan sampleso.hpp. Jika nanti saya menggunakan libsampleso.so dengan:

main.cpp (v1)

#include <iostream>
#include "sampleso.h" //<< THIS IS THE INTERESTING BIT

int main (void)
{
     carDesc fordCar;
    
     fordCar = fillCarID(); //I know this function will produce NOTHING USEFUL, but let's just pretend it is
     ...
     return EXIT_SUCCESS;
}

dan mengkompilasinya dengan dynamic linking (g ++ main.cpp -Wall -Wextra -std = c ++ 17 -L. -ldl -lsampleso -o main), adalah penambahan dari #include "sampleso.h"make my main.cpp (V1) dihitung sebagai karya turunan , sehingga memaksa kode sumber main.cpp diungkapkan sebagai copyleft, atau tidak? Atau apakah saya harus menggunakan dlopen, dlsym, dan dlclose untuk dianggap sebagai tautan dinamis (lihat main.cpp V2)? Seberapa jauh FSF dan LGPL menghitung program sebagai tautan dinamis (dengan hanya menyebutkannya sebagai bagian dari -l param cukup? Atau apakah saya harus benar-benar memanggil perpustakaan menggunakan dlopen dan menghapus setiap #include "sampleso.h"tempat di kode saya agar dianggap cukup dinamis? ). Semua orang berbicara tentang .so dan .dll, tetapi tidak ada yang berbicara tentang penyertaan file header LGPL dan kompilasi kode apa pun dengan header LGPL yang disertakan.

main.cpp (v2)

#include <iostream>
#include <dlfcn.h> //Completely has no sampleso.hpp in it

int main (void)
{
     //... some dlopen codes here to find the libsampleso.so, and handle the error if it failed to be found in the aformentioned location ...

     struct carDesc * fordCar;
     fordCar = reinterpret_cast<struct carDesc*>(dlsym(hHandler,"car"));
    
     carDesc(*__fn_fillCarIDv)(void);
     __fn_fillCarIDv = reinterpret_cast<carDesc(*)(void)>(dlsym(hHandler,"_Z9fillCarIDv"));

     fordCar = __fn_fillCarIDv(); //doesn't work, error: function returns incomplete type "carDesc" C/C++(862), still working on how to make it work
     return EXIT_SUCCESS;
}

1. Karena LGPL v2.1 dan v3 menuntut kemampuan bagi pengguna untuk memutakhirkan / menurunkan versi pustaka bersama sesuai keinginan mereka, sambil menjaga kemampuan yang dapat dieksekusi untuk berjalan, bagaimana dengan yang dapat dieksekusi yang membutuhkan versi pustaka tertentu (masih dengan tautan dinamis, tetapi versi tertentu dari .so / .dll file dibuat wajib oleh programmer)? Itu membuat pengguna tidak dapat meningkatkan atau menurunkan versi sesuai keinginan mereka lagi, karena pengguna terikat pada versi pustaka tertentu, dan jika mereka meningkatkan atau menurunkan, program juga akan rusak.

Saya sangat menyesal jika pertanyaan ini lebih seperti esai, tetapi datang dari negara selain AS, sangat sulit untuk menafsirkan dengan jelas apa itu LGPL dan di mana batas-batas di mana LGPL berlaku atau tidak untuk aplikasi.

EDIT: Saya tahu tentang semua hal hukum lainnya yang diwajibkan oleh lisensi LGPL (menyebutkan penggunaannya dalam lisensi saya, memberikan teks lisensi LGPL secara lengkap, dan menghosting kode LGPL, dll.) Saya hanya ingin fokus pada bagian 4, 5 dan 6 yang masih diperdebatkan oleh banyak orang tentang sejauh mana seseorang dapat mengatakan bahwa sesuatu itu turunan pekerjaan.

Answer 1

LGPLv2.1 berisi paragraf berikut yang secara langsung relevan dengan pertanyaan Anda

Ketika sebuah "karya yang menggunakan Perpustakaan" menggunakan materi dari file header yang merupakan bagian dari Perpustakaan, kode objek untuk karya tersebut mungkin merupakan karya turunan dari Perpustakaan meskipun kode sumbernya bukan. Benar atau tidaknya sangat signifikan jika pekerjaan bisa ditautkan tanpa Library, atau jika pekerjaan itu sendiri adalah library. Ambang batas agar hal ini benar tidak ditentukan secara tepat oleh hukum.

Jika file objek semacam itu hanya menggunakan parameter numerik, tata letak dan pengakses struktur data, serta makro kecil dan fungsi sebaris kecil (panjangnya sepuluh baris atau kurang), maka penggunaan file objek tidak dibatasi, terlepas dari apakah itu turunan secara legal. kerja.

LGPLv3 memiliki bagian yang serupa:

3. Kode Objek Memasukkan Materi dari File Header Perpustakaan.

Bentuk kode objek dari Aplikasi dapat menggabungkan materi dari file header yang merupakan bagian dari Perpustakaan. Anda dapat menyampaikan kode objek tersebut sesuai pilihan Anda, asalkan, jika materi yang digabungkan tidak terbatas pada parameter numerik, tata letak dan pengakses struktur data, atau makro kecil, fungsi dan templat sebaris (panjang sepuluh baris atau kurang), Anda lakukan kedua hal berikut: [...]

Dalam istilah yang juga bisa dipahami oleh manusia normal, jika Anda menggunakan file header dari pustaka LGPL yang hanya berisi

• parameter numerik
• tata letak struktur data
• pengakses untuk struktur data tersebut
• makro kecil (masing-masing kurang dari 10 baris)
• fungsi sebaris kecil (masing-masing kurang dari 10 baris)

maka kode Anda tidak akan "terinfeksi" oleh persyaratan LGPL dan Anda dapat mendistribusikan kode Anda di bawah lisensi apa pun yang Anda suka, termasuk lisensi sumber tertutup.

FSF diterima bahwa tidak ada jaminan bahwa bagian-bagian dari pustaka tersebut dapat diganti oleh pengguna akhir.