Hôm nay tôi có một điều bất ngờ tồi tệ khi biết về một số tác động của giấy phép GPL, chủ yếu là tôi không thể sử dụng nó một cách tự do như tôi nghĩ.
Bây giờ tôi biết.
Tôi nên biết những gì khác, và rộng rãi hơn, mọi nhà phát triển nên biết gì về những thứ pháp lý như vậy?
Bạn có thể tách nhân viên, dịch giả tự do, người đóng góp cho các dự án mã nguồn mở (v.v.) hoặc đưa ra câu trả lời rộng hơn.
Câu trả lời:
Mười hai cân nhắc pháp lý để phát triển phần mềm
Phần mềm có bản quyền nếu nó được cung cấp cho công chúng. Không cần thiết phải đặt thông báo bản quyền trên ứng dụng hoặc trong mã nguồn. Chủ sở hữu bản quyền là (các) tác giả hoặc công ty trả tiền cho (các) tác giả.
Bản quyền của phần mềm có thể được chỉ định bởi chủ sở hữu bản quyền, hoặc nó có thể được giữ lại bởi chủ sở hữu và phần mềm có thể được cấp phép cho người dùng hoặc người dùng bởi chủ sở hữu.
Các thư viện được sử dụng trong quá trình phát triển có thể có những hạn chế trong việc sử dụng và phân phối chúng. GPL không làm cho thư viện trở thành một miền công cộng, cũng như thực tế là thư viện không đi kèm với một nền tảng phát triển. Bạn nên đọc và hiểu giấy phép trước khi bạn phân phối ứng dụng của mình. Một số thư viện yêu cầu thanh toán tiền bản quyền, mặc dù điều này đã trở nên ít phổ biến hơn trong những năm gần đây.
Các vụ kiện về bằng sáng chế phần mềm là những vụ kiện tào lao. Tất nhiên, bạn không nên cố ý vi phạm bằng sáng chế phần mềm. Tuy nhiên, có một cơ hội nhỏ nhưng thực sự là một số công ty sẽ kiện bạn vì vi phạm bằng sáng chế của họ. Điều này có thể xảy ra ngay cả khi bạn phát triển phần mềm của mình một cách độc lập, bạn chưa bao giờ nghe nói về bằng sáng chế và bằng sáng chế bao gồm một kỹ thuật hiển nhiên trực quan và gần như hoàn toàn không liên quan đến phần mềm của bạn. Bạn không thể làm gì nhiều để tránh điều này, với các chính sách USPTO hiện tại, ngoài việc mua bảo hiểm. Tin tốt là những kẻ lừa đảo bằng sáng chế thường kiện các công ty lớn có nhiều tiền.
Nếu bạn sử dụng một nhân viên hoặc người làm việc tự do để phát triển phần mềm, bạn nên làm rõ bằng văn bản, ai là người sở hữu bản quyền đối với ứng dụng, bao gồm cả mã nguồn. Một số dịch giả tự do và các công ty phát triển hợp đồng coi mã nguồn là tài sản riêng của họ, khiến công ty phụ thuộc vào (các) nhà phát triển ban đầu. Điều này là hợp pháp nếu nó nằm trong thỏa thuận phát triển.
Nếu bạn có một nhân viên phát triển phần mềm "không công khai", bạn nên nói rõ ai sở hữu phần mềm đó và loại phần mềm nào mà nhân viên đó có thể viết và phân phối bên ngoài công ty.
Nếu bạn là nhân viên hoặc người làm nghề tự do phát triển phần mềm, bạn nên làm rõ ai sẽ sở hữu bản quyền đối với ứng dụng của bạn, trước khi bạn bắt đầu phát triển. Ngoài ra, bạn nên biết hoặc làm rõ ai là người sở hữu phần mềm do bạn tự viết. Một số công ty có các điều khoản trong thỏa thuận lao động yêu cầu quyền sở hữu đối với bất kỳ phần mềm nào do nhà phát triển viết trong thời gian làm việc, dù ở nhà hay tại nơi làm việc. Nhiều công ty có các điều khoản không cạnh tranh trong các thỏa thuận lao động hạn chế phần mềm mà một nhân viên có thể sản xuất để phân phối bên ngoài công ty. Đôi khi những hạn chế này khá rộng.
Nhãn hiệu là tên hoặc biểu tượng, không phải bản thân phần mềm. Nếu bạn phân phối phần mềm, bạn nên (a) đảm bảo rằng tên ứng dụng và "nhãn hiệu" hoặc thiết kế của tên không "tương tự một cách khó hiểu" với các ứng dụng khác, và (b) đăng ký nhãn hiệu của bạn. Ngày sử dụng đầu tiên rất quan trọng trong việc giải quyết xung đột, vì vậy bạn nên ghi lại thời điểm ứng dụng được sử dụng lần đầu trong thương mại.
Khi bạn đặt tên cho ứng dụng, hãy kiểm tra các nhãn hiệu đã đăng ký, nhưng cũng kiểm tra Google. Đơn đăng ký sử dụng tên lần đầu có thể lấy tên và nhãn hiệu của bạn sau khi đơn đăng ký của bạn thành công, ngay cả khi họ chưa đăng ký nhãn hiệu và bạn có.
Khi bạn sử dụng hoặc ký hợp đồng hoặc thỏa thuận, hãy đảm bảo rằng cả hai bên đều hiểu rõ về nó. Trong một thỏa thuận lao động, việc đề cập trước bất kỳ khu vực nhạy cảm nào có thể tránh được nhiều vấn đề sau này. Trong một thỏa thuận phát triển, nếu cả hai bên biết ai sở hữu mã nguồn, hoặc ai chịu trách nhiệm nâng cấp hoặc ai chịu trách nhiệm bảo trì, v.v., đi vào dự án phát triển, thì khả năng xảy ra vụ kiện sau khi đăng ký sẽ ít hơn nhiều. đã được hoàn thành. Trong thỏa thuận phân phối, hãy đảm bảo rằng nhà phân phối hiểu rõ trách nhiệm và thời hạn của thỏa thuận.
Mọi ứng dụng không tầm thường đều có lỗi (hoặc "cân nhắc thiết kế" :-)). Bất kỳ thỏa thuận người dùng hoặc thỏa thuận phân phối nào cũng phải nói rõ rằng bạn không chịu trách nhiệm về phần mềm không có lỗi và bạn không thể được mong đợi để sửa tất cả các lỗi. Nói rõ rằng các thay đổi, sửa chữa và nâng cấp được thực hiện theo tùy chọn (hoặc nỗ lực tốt nhất) của nhà phát triển và nêu rõ ai là người trả tiền cho các bản sửa lỗi và nâng cấp.
Ngay cả sau khi bạn tham khảo ý kiến luật sư về các thỏa thuận phát triển và phân phối phần mềm, bạn nên đọc các thỏa thuận từ các công ty phần mềm khác và xem luật sư của họ đã đưa ra những gì.
Tôi không phải là luật sư, và đây không phải là lời khuyên pháp lý.
Some freelancers and contract development companies consider the source code their own property, leaving the company dependent on the original developer(s). This is legal if it's in the development agreement.Nếu bạn là một freelancer không làm việc tốt hơn, bạn nên tính thêm phí. Nếu bạn dành thời gian để thiết kế một hệ thống cơ sở sạch sẽ tại sao bạn lại cho phép họ mang nó đến một cửa hàng bán đồ thân để gặt hái phần thưởng? Bạn đã đầu tư vào cơ sở mã, đây là cách bạn thực hiện đầu tư của mình thành công. Ngoài ra, điều này cho phép bạn sử dụng lại logic thông thường ở những nơi khác cho khách hàng tiếp theo của bạn.
Khi nghi ngờ, hãy liên hệ với luật sư.
Tôi không phải là luật sư nhưng theo thời gian, tôi đã thu thập được một số quy tắc nhỏ từ những người hợp pháp mà bạn có thể sử dụng để tiết kiệm thời gian:
.dll/ .socủa thư viện là một trong những cách bạn có thể 'sử dụng' mã LGPL-ed mà không có bất kỳ nghĩa vụ nào, ngoại trừ thông báo bản quyền thích hợp.Việc liên hệ với người bảo trì dự án Nguồn mở thường giúp ích cho bạn. Họ ở vị trí tốt nhất để tư vấn cho bạn về ý định ban đầu của giấy phép cũng như quan điểm của họ về mã nguồn mở. Đôi khi các nhà bảo trì sẵn sàng phát hành phần mềm theo nhiều giấy phép để giúp bạn. Thường thì không. Phụ thuộc vào người sở hữu bản quyền.
Dự án KDE có một ma trận tiện dụng
Tôi nghĩ Hướng dẫn Pháp lý về Phát triển Web & Phần mềm của Luật sư Stephen Fishman là những gì bạn đang tìm kiếm.
Ôn tập
Một cuốn sách tuyệt vời! Câu trả lời gần như mọi câu hỏi pháp lý mà bạn có thể tưởng tượng và một số câu trả lời bạn sẽ chưa bao giờ nghĩ đến. - John Dvorak, Tạp chí PC
Bao gồm mọi chi tiết có thể tưởng tượng quan trọng đối với một phương tiện vô hình và đang phát triển nhanh chóng như vậy. - Doanh nhân
Cuốn sách này đã vượt qua bài kiểm tra cá nhân của tôi về hướng dẫn pháp lý - với điểm cao hơn bất kỳ hướng dẫn pháp lý nào khác. - Jeff Duntemann, Biên tập viên, Tạp chí Kỹ thuật PC
Mô tả Sản phẩm
Bảo vệ quyền lợi của bạn và công việc khó khăn của bạn!
Các luật liên quan đến phát triển trang web và phần mềm rất phức tạp và khó hiểu, nhưng nếu bạn không gỡ rối chúng, bạn có thể phải trả hàng ngàn đô la phí luật sư và các vụ kiện.
May mắn thay, Hướng dẫn Pháp lý về Phát triển Web & Phần mềm giải mã lĩnh vực pháp luật phức tạp này, một cách thấu đáo và bằng tiếng Anh thân thiện với người đọc. Nó cũng cung cấp các hợp đồng, thỏa thuận và biểu mẫu pháp lý trên CD-ROM, với hướng dẫn từng bước để điền chúng, vì vậy bạn có thể bảo vệ phần mềm và trang web của mình mà không phải trả tiền chuộc cho luật sư.
Sử dụng Hướng dẫn Pháp lý về Phát triển Web & Phần mềm để tìm hiểu:
- loại bảo vệ pháp lý nào bạn cần
- điểm mạnh và hạn chế của từng loại bảo vệ
- cách tránh vi phạm
- những điều khoản nào bạn cần khi soạn thảo một thỏa thuận
- cách xin phép sử dụng tài liệu của người khác
Bạn sẽ tìm thấy hướng dẫn đầy đủ, từng bước để soạn thảo:
- thỏa thuận lao động
- thỏa thuận nhà thầu và nhà tư vấn
- thỏa thuận phát triển
- thỏa thuận cấp phép
Phiên bản thứ 5 của Hướng dẫn Pháp lý về Phát triển Web & Phần mềm được cập nhật hoàn toàn để cung cấp các án lệ mới nhất và các bản sửa đổi theo luật định.
Một số gợi ý khác:
Nếu là người làm việc tự do hoặc nhà thầu: hãy đảm bảo rằng bạn có bảo hiểm trách nhiệm pháp lý và biết những gì được bảo hiểm theo đó.
Ví dụ: của tôi không bao gồm trách nhiệm pháp lý đối với những sai sót trong mã có thể làm lộ số thẻ tín dụng. Vì vậy, tôi không chạm vào thứ đó nữa!
Đối với nhân viên: chúng tôi có thể đưa ra lời khuyên đầu tiên cho khách hàng của bạn - chẳng hạn như họ / chúng tôi có thể sử dụng thành phần chúng tôi muốn trong ứng dụng của họ không?
Đối với dịch giả tự do: chúng tôi phải có khả năng đưa ra lời khuyên mạnh mẽ cho khách hàng của bạn; và chọn các thành phần chúng tôi có thể sử dụng cho các ứng dụng mà chúng tôi phát triển cho chúng.
Tất nhiên, lời của bạn không tốt bằng những lời khuyên mà luật sư có thể cho bạn; nhưng bạn đã có thể giúp một vòng đầu tiên; ví dụ, để nói "chúng tôi chắc chắn không thể sử dụng điều này vì nó có nghĩa là ..."
Cuối cùng, luật sư sẽ biết nhiều về các trường hợp góc - nhưng nếu bạn có thể giúp một chút ...
Đối với những người đóng góp PMNM: biết một số khác biệt giữa các giấy phép miễn phí có thể quan trọng nếu bạn quan tâm mọi người có thể làm gì với mã của bạn (phân phối lại? Sửa đổi? Sử dụng nó trong ứng dụng thương mại? Sử dụng nó trong ứng dụng độc quyền?)
Một câu trả lời đã khẳng định rằng luật không giống như luật. Tôi không đồng ý.
Trong những ngày đầu, IBM trả tiền cho các lập trình viên theo hướng dẫn. (Một người mà tôi biết nói rằng anh ta đã làm việc với một lập trình viên làm giàu theo cách này. Rõ ràng anh ta không biết cách sử dụng thanh ghi chỉ mục của máy; anh ta đã viết một quy trình không bộ nhớ lưu trữ thủ công số 0 trong mỗi địa chỉ bộ nhớ.)
Cũng có một thời gian (cách đây rất lâu) khi luật sư được trả công bằng chữ. Điều này đã giúp phổ biến các thực hành như xưng hô với mọi người như là "những người tương tự được đánh giá cao nhất" và các câu nói dài dòng khác.
Tôi vừa đọc một câu trả lời trên SO nói rằng VB.NET 2008 vẫn cho phép số dòng . Bạn vẫn có thể chạy DOS thuần túy trên PC hiện đại. Và có nhiều sự thật cho trò đùa rằng tất cả các chương trình COBOL đều bị đánh lừa khỏi một tổ tiên chung bởi những thay đổi gia tăng. Khả năng tương thích ngược và "lý do lịch sử", có đầy rẫy trong lĩnh vực của chúng tôi.
Điều này có thể so sánh với lĩnh vực luật pháp. Có những luật tạo ra những thay đổi nhỏ (hoặc lớn) đối với các luật khác. Bạn đã có một loại phụ thuộc-địa ngục. Có một số luật lịch sử vô lý (ở Hobart, Tasmania, việc một người đàn ông mặc váy phụ nữ sau khi mặt trời lặn là bất hợp pháp - bởi vì ngày xưa, những kẻ bị kết án sẽ ăn mặc như phụ nữ và những người ngồi trong cốc) mà không ai có thể thi hành, giống như có một số tính năng lịch sử trong phần mềm mà không ai sử dụng nữa.
Các luật thường có các điều kiện không mong muốn (lỗi!), Được sử dụng theo những cách sáng tạo (hack!), Chứa các lỗ hổng (lỗ hổng bảo mật!), Một số trong số đó là cố ý (cửa hậu!), Được sửa đổi (bản vá!) Hoặc bị lật tẩy (gỡ cài đặt!) .
Có, luật (không giống như mã) có thể được giải thích. Nhưng tôi nghĩ rằng điều này giống như bảo trì mã. Nó giúp điều chỉnh luật theo các chuẩn mực xã hội mới.
Để trả lời câu hỏi trực tiếp: mọi nhà phát triển nên biết rằng luật giống như một dự án phần mềm khổng lồ đến kỳ lạ đã được phát triển hàng trăm năm. (Trên thực tế, mỗi quốc gia có dự án riêng và họ giải quyết vấn đề theo những cách khác nhau.) Về lý thuyết, sau khi đọc giấy phép, bạn sẽ biết bạn có thể và không thể làm gì với mã của mình. Nhưng nếu một lập trình viên có năng lực không thể phát hiện ra tất cả các lỗi trong mã của mình chỉ bằng cách đọc nó, thì cơ hội nào để một người không phải là luật sư phân tích các trường hợp góc và vùng xám của một văn bản pháp luật?
Giống như với mã nguồn phần mềm, bạn thường có thể hiểu được ý chính của một tài liệu pháp lý bằng cách đọc nó, nhưng nếu bạn cần biết điều gì đó cụ thể, hãy hỏi chuyên gia .
NOLO (tôi không làm việc cho họ) xuất bản một tập hợp pháp hay về cách ghi sách cho giáo dân.
http://www.nolo.com/products/a-legal-guide-to-web-&-software-development-SFT.html
Tôi sẽ trả lời câu này giống như cách mà tôi sẽ trả lời "mọi luật sư nên biết gì về lập trình?" Điều đó có nghĩa là, hãy biết rằng không có cách nào bạn có thể biết lĩnh vực chuyên sâu đủ tốt để làm được nhiều việc hơn những điều đơn giản nhất. Tìm một chuyên gia.
Bạn nên biết các quyền và nghĩa vụ cơ bản của giấy phép mà bạn sẽ sử dụng. Nó không quá khó, và ngay cả khi có rất nhiều trong số đó, bạn chỉ cần đọc kỹ những thứ bạn sẽ sử dụng hoặc chạm vào. Chỉ cần đọc chúng, trong hầu hết các trường hợp, chúng khá rõ ràng.
Bất cứ điều gì khác bạn có thể cần, tốt, điều đó tùy thuộc. Cấp bằng sáng chế? Nhãn hiệu? Nếu bạn cần những điều này, rất có thể bạn đang ở trong một công ty và có bộ phận pháp lý làm việc này cho bạn.
Tôi luôn giả định rằng các nhà phát triển của một dự án muốn bất kỳ phần mềm nào sử dụng công việc của họ được phát hành theo cùng một giấy phép. Đọc Câu hỏi thường gặp và các trang pháp lý của họ để biết thêm thông tin và đừng ngần ngại liên hệ với nhà phát triển / người bảo trì nếu bạn vẫn không chắc chắn.
Nếu bạn muốn giúp hiểu chi tiết của thỏa thuận cấp phép, hãy nói chuyện với luật sư.
6.Nếu bạn có một nhân viên phát triển phần mềm "không công khai", bạn nên nói rõ ai sở hữu> phần mềm đó, và loại phần mềm nào mà nhân viên đó có thể viết và phân phối bên ngoài công ty.
quyền tự do ngôn luận như đã nêu trong hầu hết các hiến pháp (đặc biệt là nếu nhà phát triển thực hiện tự do không cần đồng hồ) có thể khiến các điều khoản đó thất bại thảm hại tại các tòa án
Luật không giống như luật. Nó không phải là một tập hợp các bước và quy tắc được đúc kết tốt để có thể hiểu rõ ràng.