Tôi có thể tạm thời sử dụng các thư viện GPL để tạo mẫu và tạo mã nguồn đóng trong tương lai không?


23

Tôi đang làm việc trên một nguyên mẫu cho một hệ thống phần mềm, mà (ít nhất là lúc bắt đầu) sẽ là nguồn đóng.

Để tiết kiệm thời gian, tôi nghĩ đến việc sử dụng (nghĩa là liên kết tĩnh) một thư viện được cấp phép theo GPLv3 , vì vậy tôi có thể kiểm tra thiết kế của mình một cách nhanh chóng. Nếu tôi phân phối phần mềm ở giai đoạn này, tôi sẽ phải phân phối mã nguồn cùng với nó.

Điều gì sẽ xảy ra nếu tôi không, nhưng tự hài lòng rằng hệ thống của tôi hoạt động và sau đó thay thế thư viện GPL bằng mã của riêng tôi trước khi phân phối? Kết quả sẽ bị "ô nhiễm" bởi GPL?

Tôi có cảm giác rằng việc giữ lại thư viện GPL trong lịch sử Git của mình hay không có thể tạo ra sự khác biệt.


16
Tôi thích thành ngữ "bị ô nhiễm bởi GPL".
Arseni Mourzenko

7
nó phù hợp với tính chất lan truyền của giấy phép :)
Laurent S

5
Sửa lỗi cho tôi nếu tôi sai, nhưng bạn muốn phát hành một hệ thống nguồn đóng, đồng thời lưu trữ mã trên git? (và tôi cho rằng git này có thể đọc được bởi những người khác, vì nếu không thì tại sao bạn lại lo lắng về việc có GPL lib trong lịch sử?)
user2813274

3
@ user2813274, bạn có thể có một kho Git riêng.
Arturo Torres Sánchez

5
Khi bạn thấy câu hỏi này thú vị, bạn cũng có thể quan tâm đến đề xuất cho Stackexchange mã nguồn mở mới .
Philipp

Câu trả lời:


20

GPL viết :

Bạn có thể chuyển tải một tác phẩm dựa trên Chương trình hoặc các sửa đổi để sản xuất nó từ Chương trình, dưới dạng mã nguồn theo các điều khoản của phần 4, với điều kiện bạn cũng phải đáp ứng tất cả các điều kiện sau:

Vì vậy, điều kiện này chỉ áp dụng nếu công việc của bạn là "dựa trên" thư viện mà giấy phép xác định như sau:

Để sửa đổi, một tác phẩm có nghĩa là sao chép từ hoặc điều chỉnh tất cả hoặc một phần tác phẩm theo cách cần có sự cho phép bản quyền, ngoài việc tạo ra một bản sao chính xác. Tác phẩm được tạo ra được gọi là phiên bản sửa đổi của người dùng của các tác phẩm trước đó hoặc một tác phẩm khác dựa trên cơ sở của tác phẩm trước đó.

Đó là, chương trình của bạn "dựa trên" thư viện nếu và chỉ khi đó là một tác phẩm phái sinh theo luật bản quyền. Định nghĩa pháp lý của thuật ngữ đó thay đổi phần nào giữa các khu vực pháp lý và thường không trực tiếp giải quyết phần mềm. Chẳng hạn, Đạo luật Bản quyền Hoa Kỳ viết:

Một tác phẩm phái sinh của một người khác có thể được đúc lại, biến đổi, hoặc thích nghi. Một tác phẩm bao gồm sửa đổi biên tập, chú thích, xây dựng hoặc sửa đổi khác, nói chung, đại diện cho một tác phẩm gốc của tác giả, là một tác phẩm phái sinh của Hồi giáo.

Điều này có nghĩa là gì đối với phần mềm phải được các tòa án giải thích, dựa trên các phán quyết tương tự trước đó. Tôi không đủ quen thuộc với luật án lệ liên quan trong phạm vi quyền hạn của bạn để nói một cách chắc chắn rằng một tòa án sẽ quyết định trường hợp của bạn như thế nào. Người ta có thể lập luận rằng "thay thế thư viện GPL bằng mã riêng" là một hành động dịch thuật, đặc biệt nếu mã của bạn được truyền cảm hứng mạnh mẽ bởi việc triển khai GPL. Ngay cả việc sử dụng lại API của thư viện GPL cũng có thể đưa bạn vào nước nóng (xem Oracle so với Google ).

Nếu câu trả lời quan trọng với bạn, tôi khuyên bạn nên tìm kiếm tư vấn pháp lý có thẩm quyền thay vì hỏi người lạ trên internet.


1
ok, điều này thật thú vị, tôi đã không nhận ra rằng việc chia sẻ API có thể được coi là một công việc phái sinh.
Laurent S

Câu trả lời này đưa ra cùng một điểm mà tôi đã cố gắng đưa ra trong câu trả lời của mình dưới đây, nhưng theo một cách rõ ràng hơn nhiều. +1
Michael Shaw

23

Miễn là bạn không phát hành phần mềm cho bất kỳ ai trong khi bạn đang liên kết với các thư viện của GPL, bạn sẽ an toàn. Khía cạnh virus của GPL chỉ có tác dụng nếu bạn phân phối phần mềm của mình.

Sẽ tốt hơn nếu bạn có thể tìm thấy một thư viện có giấy phép dễ dãi hơn, tất nhiên, như LGPL hoặc APL2 hoặc MIT.


Rõ ràng, tôi sẽ cố gắng tìm một thư viện khác có giấy phép cho phép. Nhưng thất bại, có vẻ như tôi có thể có mã GPL cũ trong lịch sử git và không phá vỡ các điều khoản của nó, bằng cách phân phối trạng thái tương lai của mã.
Laurent S

5
Câu trả lời này không tính đến rủi ro tạo ra một tác phẩm phái sinh khi thực hiện phiên bản mới của thư viện.
Michael Shaw

4
@Ptolemy Hãy nhớ rằng nếu lịch sử git của bạn được phát hành, bạn đã phát hành phiên bản cũ. Nó không phải ở dạng nhị phân để đếm.
piojo

2
@piojo Mặt khác, hầu hết bắt buộc bạn phải cấp phép cho phiên bản cũ đó theo GPL (và phân phối nguồn cho nó); nếu tại một thời điểm nào đó bạn thấy mình có bản quyền duy nhất đối với mã, bạn có thể đặt tất cả các phiên bản trong tương lai thành nguồn đóng (mặc dù các phiên bản cũ tiếp tục nằm dưới GPL). Tùy thuộc vào số lượng nội dung độc quyền trong phiên bản cũ, bạn có thể có hoặc không gặp sự cố.
cpast 7/03/2015

1
Miễn là Laurent S là tác giả và chủ sở hữu bản quyền của tất cả các mã khác bên cạnh GPL, anh ta cũng an toàn. Anh ta có thể và được phép phát hành toàn bộ công việc theo các điều khoản của GPL3 chỉ trong trường hợp điều này có thể là kết quả sau này. Điều này có thể là không mong muốn, nhưng OP rõ ràng là an toàn trong mọi trường hợp (nếu bản quyền được sở hữu).
hakre

8

Tôi không nghĩ câu hỏi của bạn thực sự là về GPL. Đó là về nguyên mẫu và liệu nó sẽ được sử dụng trong tương lai làm cơ sở cho hệ thống phần mềm có thể giao được hay không.

Nếu bạn đang tạo một nguyên mẫu bỏ đi và bạn sẽ không sử dụng lại bất kỳ mã nào trong hệ thống có thể phân phối của mình, thì hãy tiếp tục và sử dụng thư viện GPL.

Ba cách tiếp cận bạn có thể thực hiện

Tuy nhiên, nếu bạn định phát triển nguyên mẫu (điều mà nhiều nhà quản lý thúc đẩy!), Bạn có ba cách tiếp cận bạn có thể thực hiện:

  1. Di chuyển các phần không cốt lõi vào các ứng dụng riêng biệt giao tiếp với lõi của bạn qua JSON hoặc API REST hoặc một số thư viện / ngôn ngữ Giao tiếp giữa các quá trình khác. Do đó, các phần không cốt lõi của bạn cũng có thể là GPL và bạn có thể sử dụng bất kỳ thư viện GPL nào trong đó.
  2. Thiết kế mã của bạn để bạn có thể trao đổi các thư viện. Điều này có nghĩa là tạo ra một mặt tiền che giấu các chi tiết thực hiện. Khi bạn đã sẵn sàng để chuyển sang thư viện độc quyền hoặc thư viện MIT / BSD.
  3. Không sử dụng mã GPL nào cả.

Tôi khuyên bạn nên đi theo cách tiếp cận đầu tiên bởi vì sau đó bạn có công việc nguồn mở mà bạn có thể sử dụng trong tương lai như là một phần của danh mục đầu tư chuyên nghiệp của bạn.

Cách tiếp cận thứ hai cũng tốt bởi vì đó là cách bạn nên thiết kế hệ thống, tạo ra các chức năng / lớp chính xác mà bạn cần và loại bỏ chúng cho đến khi bạn có thư viện hoặc mã tùy chỉnh điền vào chức năng đó.


2
Việc đưa mã GPL vào một quy trình khác không có nghĩa là nó không còn là một phần của chương trình, và do đó không còn phù hợp để cấp phép cho phần còn lại. Nó có thể giúp tách chúng đủ tốt mặc dù.
Ded

1
@Ded repeatator nếu chúng là các ứng dụng riêng biệt không đủ, chúng phải được coi là một cơ sở mã riêng biệt, bạn đã đúng. Kiểu như những gì Twitter làm với Bootstrap và những gì Facebook làm với tất cả các thư viện của nó. Nguồn mở không cốt lõi với mã độc quyền cốt lõi.
Rudolf Olah

@omouse, tôi không thể làm 1, vì đó là phần mềm nhúng. 2 là suy nghĩ đầu tiên của tôi, nhưng nhìn thấy những gì Ptolemy và meriton đề cập, có vẻ như tôi đang tạo ra các tác phẩm phái sinh, vì vậy 3 có lẽ là con đường để đi.
Laurent S

1
Re: "Tôi không nghĩ câu hỏi của bạn thực sự là về GPL": Tôi không đồng ý. Một giấy phép phần mềm chắc chắn có thể cấm loại sử dụng này. Một câu trả lời đã bỏ qua phần "GPL" của câu hỏi và chỉ xem đó là câu hỏi chung về giấy phép nguồn mở với các điều khoản hạn chế và hành vi lan truyền, sẽ phải dùng đến "chúng tôi không biết, bạn sẽ có để đọc các điều khoản của giấy phép ".
ruakh

Nếu bạn tạo một tác phẩm phái sinh và vứt nó đi, bạn vẫn tạo ra một tác phẩm phái sinh và bạn chỉ có thể làm điều đó với sự cho phép / giấy phép của chủ bản quyền gốc. Với GPL, bạn có giấy phép đó (nếu bạn không bao giờ phân phối tác phẩm phái sinh trước khi vứt nó đi). Với giấy phép khác, bạn có thể không có sự cho phép. Mặc dù bạn bị thiệt hại có thể khó khăn.
gnasher729

5

Tôi có thể nghĩ về hai khía cạnh để xem xét với phương pháp của bạn. Đầu tiên là đơn giản, bằng cách không phân phối dự án của bạn hoặc (hoặc là GPLv3 , làm cho nó có sẵn cho công chúng) trong khi bạn đang sử dụng mã được phát hành theo GPL, thật khó để thấy bạn sẽ được yêu cầu phân phối mã như thế nào theo giấy phép GPL cũng theo các điều khoản phân phối lại.

Khía cạnh thứ hai có thể có ý nghĩa hơn đối với bạn. Khi bạn tạo triển khai của riêng mình để thay thế thư viện GPL, bạn cần cẩn thận để không tạo ra một tác phẩm phái sinh. Mặc dù tôi chắc chắn rằng bạn có ý định tốt, nhưng không sao chép trực tiếp mã nguồn - bạn có nhiều khả năng hơn là không sao chép các phần quan trọng của API thư viện.

Nếu đây là sản phẩm thương mại, rủi ro này cần được xem xét và đánh giá bằng cách đọc kỹ giấy phép GPLv3 và khi có nghi ngờ, hãy hỏi ý kiến ​​pháp lý chuyên nghiệp.


4

Nếu bạn dự định viết mã của riêng mình để thay thế mã GPL, bạn sẽ gặp vấn đề tiềm ẩn vì bạn không viết mã trong môi trường phòng sạch. Bạn thực sự muốn có một người chưa bao giờ nhìn vào mã GPL viết bất kỳ thư viện thay thế nào. Mặt khác, nếu bạn muốn trao đổi thư viện GPL cho một thư viện đã được xuất bản theo giấy phép khác thì đây không phải là vấn đề, thư viện kia có lẽ đã được viết trong môi trường phòng sạch.


2

Nếu bạn cung cấp quyền truy cập vào các bản sửa đổi bằng mã GPL, chúng sẽ hoàn toàn là GPL. Nhưng bạn không muốn, vì đó sẽ không phải là nguồn đóng ...

Đối với bất kỳ trạng thái nào sau này không còn sử dụng bất kỳ mã GPL nào, việc bạn đã sử dụng mã GPL đôi khi trước đó đơn giản là không liên quan.


2

GPL chỉ được kích hoạt khi phân phối ... bạn có thể làm bất cứ điều gì bạn muốn nếu bạn không phát hành phiên bản sửa đổi hoặc công việc phái sinh.

Tôi có cảm giác rằng việc giữ lại thư viện GPL trong lịch sử Git của mình hay không có thể tạo ra sự khác biệt.

Nếu bạn có nghĩa là xuất bản nguồn của bạn lên một kho lưu trữ công cộng như GitHub , thì có, bạn có thể gặp vấn đề. Chỉ sử dụng git là không liên quan nếu nó là riêng tư.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.