Contributor
Licence Agreements
By Ross Gardler, Rowan
Wilson, Published: 04 January 2008, Reviewed: 02 August 2012
Bài được đưa lên
Internet ngày: 02/08/2012
Lời
người dịch: Ngược với những tuyên truyền nhảm nhí,
dù cố tình hay vô ý thức, của một số người về việc
thế giới phần mềm tự do nguồn mở (PMTDNM) là không
tôn trọng quyền sở hữu trí tuệ và/hoặc không quan tâm
tới quyền sở hữu trí tuệ, các dự án PMTDNM có
những nguyên tắc khắt khe để những người đóng góp
cho dự án PMTDNM tôn trọng các quyền sở hữu trí tuệ
thông qua việc ký kết các Thỏa thuận Giấy phép của
Người đóng góp - CLA (Contributor Licence Agreement) cho từng
đóng góp và hoặc cho tổng thể những đóng góp của họ.
Bài viết này thực sự rất cần cho những người quản
lý, các lập trình viên và những người có dự định
đóng góp cho các dự án PMTDNM.
Một Thỏa thuận Giấy
phép của Người đóng góp - CLA (Contributor Licence
Agreement) được khuyến cáo mạnh khi chấp nhận những
đóng góp của bên thứ 3 vào một dự án phát triển mở,
như một dự án phần mềm nguồn mở (PMNM). Để phân
phối lại những đóng góp đó, cần thiết phải đảm
bảo rằng dự án có các quyền cần thiết để làm thế.
Một CLA là một thỏa
thuận hạng nhẹ, được người nắm giữ bản quyền ký,
trao các quyền cần thiết đối với sự đóng góp để
được phân phối lại như một phần của dự án.
Các CLA cũng đơn giản
hóa qui trình cộng tác với các đối tác trong các dự án
khi họ có thể tạo thành một phần của một thỏa thuận
cộng tác rộng lớn hơn. Những thỏa thuận như vậy xác
định quyền chủ sở hữu của bản quyền trong các tác
phẩm được cộng tác sản xuất và, xa hơn, chúng mô tả
bất kỳ việc cấp phép bản quyền đặc thù nào trong
các tư liệu được dự án tạo ra. Tuy nhiên, một thỏa
thuận cộng tác có thể cũng chi tiết hóa những dàn xếp
tài chính và cấu trúc trong mối quan hệ đối tác, trong
khi một CLA tự nó hạn chế việc giải quyết các quyền
sở hữu trí tuệ (IPR) và vì thế được áp dụng rộng
rãi hơn.
Vì sao cần một
CLA?
Mục
đích của một CLA là để đảm bảo rằng người bảo
vệ các đẩu ra của một dự án có quyền sở hữu hoặc
sự nhượng lại cần thiết các quyền đối với tất cả
những đóng góp để cho phép họ phân phối theo giấy
phép được chọn. Trong một số trường hợp điều này
sẽ có ý nghĩa là người đóng góp sẽ chỉ định bản
quyền trong tất cả những đóng góp cho người sở hữu
dự án; trong các trường hợp khác, họ sẽ cấp một
giấy phép không thể bãi bỏ được để cho phép người
duy trì dự án sử dụng sự đóng góp đó. Các CLA cũng
có các vai trò trong việc nâng cao nhận thức về các vấn
đề IPR trong một dự án.
Một CLA rõ ràng xác
định giấy phép nào được trao hoặc các quyền nào được
chuyển giao khi một cá nhân hoặc tổ chức đóng góp IPR
cho một dự án. Sự thất bại hoặc để tập trung bản
quyền vào một tổ chức duy nhất hoặc để trao một
giấy phép cho khắp các đối tác thường gây ra những
tác động đáng kể cho sự quản lý các đầu ra của dự
án trong tương lai. Ví dụ, nếu nó trở nên cần thiết
để thay đổi giấy phép ở các đầu ra, thì sự đồng
thuận đầy đủ của tất cả những người nắm giữ
bản quyền sẽ được yêu cầu. Sự đồng thuận như vậy
có thể có thể bị từ chối hoặc nó có khả năng phải
liên hệ với một bên vì thế làm cho không có khả năng
(hoặc ít nhất là đắt giá) để xử lý. Ở những nơi
mà bản quyền từng được chỉ định cho một thực thể
duy nhất, hoặc những nơi mà quyền cấp lại phép cho các
tư liệu đã được trao, thì sẽ không cần liên hệ với
những người đóng góp riêng rẽ cá nhân.
Điều
quan trọng phải nhận thức được rằng thậm chí các
nhân viên có hợp đồng không tự động chỉ định bản
quyền trừ phi điều đó rõ ràng được nêu trong hợp
đồng của họ. Vì thế điều quan trọng rằng những
người quản lý dự án đảm bảo tất cả nhân viên hợp
đồng ký một CLA cho những đóng góp của họ, hoặc, như
một lựa chọn, có những điều kiện bằng văn bản
trong hợp đồng của họ.
Sự cần thiết nào
sẽ có trong một CLA?
CLA (hoặc giấy phép
trong nội bộ) cần để trao các quyền cho một người
chủ (hoặc cơ quan chủ quản) của dự án để cho phép
phát hành phần mềm theo yêu cầu. Trong kịch bản đơn
giản nhất, một CLA, trong thực tế, sẽ không được sử
dụng hoàn toàn; người đóng góp đơn giản chỉ định
bản quyền cho người sở hữu dự án. Khi được thực
hiện đúng, người đóng góp sẽ cần ký một tuyên bố
để có hiệu lực đó. Điều này có thể có một số
lợi ích cho dự án, bao gồm việc cho phép những vi phạm
bản quyền sẽ được thực hiện từ một thực thể duy
nhất. Theo bản chất tự nhiên, dù, một số người đóng
góp sẽ không muốn đơn giản bỏ đi IPR của họ, và đây
chính là những trường hợp mà một thỏa thuận giấy
phép là cần thiết. Dự án sẽ được trao các quyền rõ
ràng đối với IPR của những người đóng góp, và bổ
sung thêm sẽ được trao quyền để truyền (hoặc cấp
phép phụ) những sự nhượng lại đó cho các bên thứ 3.
Vì
thế người đóng góp cần phải - ít nhất là - trao các
quyền sẽ được trao cho người sử dụng đầu cuối khi
phân phối giấy phép (giấy phép cho bên ngoài) bổ sung
thêm vào quyền cấp phép phụ. Khi trao các quyền, là phổ
biến để trao một dải các quyền rất rộng lớn. Điều
này là để tránh nhu cầu phải quay lại với người đóng
góp để xin được phép thực hiện một hành động mong
muốn với sự đóng góp của họ, như việc phát hành
theo một giấy phép khác.
Một CLA cũng nên bao
gồm thông tin cá nhân về người ký nó, như một tên
hoàn chỉnh và địa chỉ thư điện tử. Hãy hiểu vệ
những tác động tiềm tàng mà việc lưu trữ các thông
tin này có thể có về luật bảo vệ dữ liệu ở nước
của bạn.
Ghi lại các CLA
Rất quan trọng để
ghi lại sự chỉ định quyền hoặc trao các quyền cho
từng sự đóng góp. Điều này có nghĩa là một dự án
phải theo dõi và ghi lại các CLA được những người
đóng góp đệ trình. Có 2 tiếp cận mà một dự án có
thể tiến hành khi ghi lại các CLA. Tiếp cận đầu là để
khẳng định rằng từng sự đóng góp từu một bên thứ
3 được đi với một CLA. Tiếp cận thứ 2 là để có
một CLA được ký và được đệ trình cho những người
quản trị dự án cho sự ghi nhận vĩnh viễn. Bất kể
dạng CLA được sử dụng, một dự án phải đảm bảo
rằng chúng được ghi lại một cách vĩnh viễn. Qui trình
nào là tốt nhất cho một dự án phụ thuộc vào cách mà
dự án chấp nhận những đóng góp của các bên thứ 3.
Thông thường, những
đóng góp cho các dự án nguồn mở đi qua 1 trong 2 qui
trình đó. Chúng thường được biết tới như là rà soát
lại - rồi – đệ trình và đệ trình - rồi - rà soát
lại. Cái tên tham chiếu tới trật tự của việc xử lý
các đóng góp.
Rà soát lại - rồi
- đệ trình
Trong một qui trình rà
soát lại - rồi - đệ trình, sự đóng góp được đệ
trình cho dự án ở dạng của một bản
vá phần mềm (bản
dịch tiếng Việt), thường thông qua một trình theo
dõi vấn đề hoặc một danh sách thư. Bản vá sau đó
được rà soát lại ngang hàng và được bình luận một
cách phù hợp. Một bản vá tiếp sau đó có thể được
đệ trình để trả lời cho các ý kiến phản hồi, tới
lượt nó sẽ được rà soát lại ngang hàng. Một khi bản
vá được phê chuẩn, nó sẽ được đệ trình (commit)
cho dự án; đó là, bản vá sẽ được áp dụng cho hệ
thống kiểm soát phiên bản (bản
dịch tiếng Việt) và vì thế sẽ xuất hiện trong các
phiên bản của phần mềm đó trong tương lai.
Vì
qui trình này đòi hỏi một bước đệ trình bản vá, có
khả năng phải yêu cầu từng đệ trình sẽ được đi
theo với một CLA được chỉ định. Một số dự án cho
phép sự chỉ định này sẽ là một ô kiểm tra đơn giản
trong mẫu đệ trình của trình theo dõi vấn đề. Liệu
việc ghi lại sự chấp nhận theo cách này có phù hợp
cho dự án hay không là thứ gì đó bạn sẽ cần thảo
luận nội bộ, và có khả năng với sự hỗ trợ pháp
lý, và liên quan trực tiếp tới khả năng chịu rủi ro
của dự án. Tiếp cận này được thấy trong một số
cộng đồng phát triển mở đáng kể, như của Quỹ Phần
mềm Apache (ASF). Tiếp cận lựa chọn khác có thể được
thấy trong dự án nhân Linux. Ở đây, các bản vá được
đệ trình tới một danh sách thư đặc biệt. Mỗi bản
vá phải có một văn bản CLA được gắn ở cuối thư
điện tử đệ trình đó.
Việc cho phép các CLA
sẽ được đệ trình cho từng đóng góp, vào thời điểm
đóng góp, là hiệu quả khi không cần phải chờ cho CLA
sẽ được dự án thừa nhận trước khi sự đóng góp đó
có thể được thực hiện. Việc hợp lý hóa qui trình đệ
trình này là sống còn nếu một dự án là để chào đón
những người đóng góp mới có mong muốn thậm chí thực
hiện sự đóng góp nhỏ nhất, khi nó đảm bảo rằng qui
trình ký một CLA là ít rầy rà hơn so với việc đệ
trình bản vá. Nếu không phải thế, thì nhiều người
đóng góp tiềm năng đơn giản sẽ không khó chịu khi
đóng góp.
Đệ trình - rồi -
rà soát lại
Trong
một qui trình đệ trình - rồi - rà soát lại, người
đóng góp có khả năng đệ trình những thay đổi trực
tiếp cho hệ thống kiểm soát phiên bản. Điều này sẽ
kích hoạt một thông báo cho cộng đồng rằng một thay
đổi đã được thực hiện và họ sau đó sẽ rà soát
lại ngang hàng cho mã được đệ trình đó. Trong một số
trường hợp, các bình luận sẽ tới và những thay đổi
sẽ được thực hiện; trong các trường hợp khác, đệ
trình đó sẽ đi quan sự rà soát lại mà không có sửa
đổi gì. Rõ ràng, đệ trình - rồi - rà soát lại chỉ
phù hợp cho những người đóng góp mà họ đã chỉ ra họ
có một sự hiểu biết rõ ràng về dự án và có khả
năng tiến hành những phán xét nhạy cảm kêu gọi những
gì nên hoặc không nên được đệ trình. Hầu hết các
dự án vận hành một chính sách đệ trình - rồi - rà
soát lại chỉ làm thế đối với các thành viên cốt lõi
của đội phát triển; các thành viên khác vận hành theo
một qui trình rà soát lại - rồi - đệ trình.
Vì qui trình này cho
phép những người đóng góp bổ sung thêm trực tiếp nội
dung cho dự án mà không đi qua một qui trình đóng góp
riêng rẽ, là không có khả năng để ép tuân thủ việc
ký CLA cho từng đóng góp. Vì thế là cần thiết để có
một CLA được ký và trong hồ sơ về những người đóng
góp như vậy. Tổng chi phí bị nâng cáo mà điều này tạo
ra cho cả dự án và người đóng góp là đáng với sự
đau đớn trong ngắn hạn, vì bất kỳ người đóng góp
nào cho dự án cũng tin phải có sự truy cập trực tiếp
tới hệ thống kiểm soát phiên bản có khả năng sẽ là
một người đóng góp đáng kể trong tương lai.
Các đệ trình có
liên quan cho các CLA
Bất kể cách một dự
án chọn để ghi các CLA, điều quan trọng một hồ sơ
CLA cho từng sự đóng góp được giữ trong trong tệp.
Điều này để đảm bào rằng bất kỳ sự tranh chấp
nào về quyền sở hữu đối với các đầu ra của dự
án cũng có thể được giải quyết nhanh chóng và dễ
dàng. Đó là, dự án phải có khả năng để xác định
ai đã thực hiện những đóng góp theo yêu cầu và chứng
minh rằng các quyền hoặc giấy phép cần thiết cho IPR có
bên trong nó đã được trao cho dự án.
Để duy trì vết kiểm
toán này, cần thiết phải đảm bảo rằng khi một bản
vá được áp dụng, nó được liên kết tới CLA thích
hợp. Một lần nữa qui trình cho điều này phụ thuộc
vào chính sách đệ trình của dự án.
Đối với qui trình
rà soát lại - rồi - đệ trình thì thường đối với
thông diệp lưu ý của đệ trình đó được người rà
soát lại và áp dụng bản vá đó tạo ra để duy trì một
tham chiếu tới hồ sơ đệ trình bao gồm CLA đó. Trong
trường hợp sự đệ trình từ một trình theo dõi vấn
đề, thì điều này thường sẽ là số của vấn đề
đó; trong trường hợp của một đệ trình trong danh sách
thư, thì điều này sẽ là một đường liên kết tới
các lưu trữ danh sách thư đó.
Đối với một qui
trình đệ trình - rồi - rà soát lại, là cần thiết để
đảm bảo rằng tên người sử dụng (username) của kiểm
soát phiên bản có liên quan tới một CLA được giữ
trong tệp.
Đánh giá rủi ro
Việc duy trì các CLA
không phải là một tác vụ khó; tuy nhiên nó làm gia tăng
nỗ lực được yêu cầu phải thực hiện và chấp nhận
những đóng góp của các bên thứ 3. Hầu hết những
người đóng góp sẽ bắt đầu nhỏ; đó là, họ sẽ
cung cấp một sửa lỗi đơn giản, hoặc một sự chỉnh
cho đúng lỗi chính tả. Sự cám dỗ vì thế để từ bỏ
yêu cầu các CLA đối với các đóng góp nhỏ. Điều này
làm dấy lên câu hỏi, 'Một CLA có phải có cho từng đóng
góp, dù nó nhỏ cỡ nào hay không?'
Một số đóng góp -
những sửa lỗi hoặc sử tài liệu cho đúng rất nhỏ
(đôi khi được gọi là 'đóng góp thoảng qua' - driveby
contributions) - là quá bé nhỏ để được bản quyền bảo
vệ. Trong trường hợp các đóng góp là lớn đáng kể,
thì một đánh giá rủi ro ngắn gọn phải được thực
hiện, cân nhắc rủi ro thiệt hại từ hành động pháp
lý đối với chi phí đối với dự án để có được
một CLA. Đối với những đóng góp nhỏ, rủi ro thiệt
hại từ hành động pháp lý có thể quá nhỏ. Đối với
các đống mã lớn hơn, như việc kết hợp chức năng
chính, thì các rủi ro có thể cao hơn nhiều.
Cùng
với một đánh giá rủi ro thực tế, một chính sách cắt
lọc và được lên kế hoạch giảm thiểu tốt là sống
còn. Nếu một số mã trong dự án của bạn trở thành
đối tượng tranh cãi về quyền sở hữu, thì thiện chí
để chấm dứt đóng góp tạm thời trong khi loại bỏ
hoặc thay thế mã sẽ đi cùng đường, hướng tới việc
giảm nhẹ bất kỳ thiệt hại tiềm tàng nào, và cả sự
không thỏa mãn trong những người sử dụng nữa.
Thỏa thuận Giấy
phép của Người đóng góp của Tập đoàn
Vì hầu hết các hợp
đồng lao động nói rằng tư liệu có bản quyền được
tạo ra trong quá trình lao động của một cá nhân thuộc
về người chủ của họ, có khả năng là một người
làm việc trong một dự án phát triển mở như một phần
công việc của họ sẽ cần một CLA được người chủ
của họ ký. Chúng thường được gọi là các 'Thỏa
thuận Giấy phép của Người đóng góp của Tập đoàn'
hoặc các CCLA.
Các CLA Giấy phép
Bản quyền
- Quỹ Phần mềm Apache - Thỏa thuận Giấy phép của Người đóng góp Cá nhân [http://www.apache.org/licenses/icla.txt]
- Đại học Washington - Thỏa thuận Giấy phép của Người đóng góp cho Lịch của Đại học Washington [http://www.washington.edu/ucal/CLicense.html]
Các CCLA Giấy phép
Bản quyền
- Quỹ Phần mềm Apache - Thỏa thuận Giấy phép của Người đóng góp của Tập đoàn [http://www.apache.org/licenses/cla-corporate.txt]
- Các Thỏa thuận Giấy phép của Người đóng góp chỉ là một thành phần của một mô hình điều hành (bản dịch tiếng Việt) của một dự án.
A
Contributor Licence Agreement (CLA) is strongly recommended when
accepting third party contributions to an open development project,
such as an open source software project. In order to redistribute
contributions, it is necessary to ensure that the project has the
necessary rights to do so. A Contributor Licence Agreement is a
lightweight agreement, signed by the copyright holder, that grants
the necessary rights for the contribution to be redistributed as part
of the project.
Contributor
Licence Agreements also simplify the process of collaborating with
partners on projects as they can form part of a broader collaboration
agreement. Such agreements define ownership of copyright in works
produced in collaboration and, furthermore, they describe any
licensing of specific copyright in materials generated by the
project. However, a collaboration agreement may also detail financial
and structural arrangements in the partnership, while a CLA limits
itself to addressing intellectual property rights (IPR) and is
therefore more widely applicable.
The
purpose of a CLA is to ensure that the guardian of a project’s
outputs has the necessary ownership or grants of rights over all
contributions to allow them to distribute under the chosen licence.
In some cases this will mean that the contributor will assign the
copyright in all contributions to the project owner; in other cases,
they will grant an irrevocable licence to allow the project
maintainer to use the contribution. CLAs also have roles in raising
awareness of IPR issues within a project.
A
CLA clearly defines what licence is granted or what rights are
transferred when an individual or organisation contributes IPR to a
project. Failure to either concentrate copyright in a single
organisation or to grant a licence across partners often results in
considerable complications for the future management of project
outputs. For example, if it becomes necessary to change the licence
on outputs, the full consent of all copyright holders is required.
Such consent may be withheld or it may be impossible to contact a
party thus making it impossible (or at least expensive) to proceed.
Where copyright has been assigned to a single entity, or where the
right to relicence the materials has been granted, there is no need
to contact individual contributors.
It
is important to realise that even contracted staff do not
automatically assign copyright unless it is explicitly stated in
their contract. It is therefore important that project managers
ensure all contract staff sign a CLA for their contributions, or
alternatively have suitable conditions written into their contract.
The
CLA (or inbound licence) needs to grant rights to a project’s owner
(or owning body) that enable the release of the software in question.
In the simplest scenario, a CLA is not, in fact, used at all; the
contributor simply assigns the copyright to the project owner. When
done properly, the contributor will need to sign a statement to that
effect. This can have a number of benefits for the project, including
allowing copyright infringements to be taken up by a single entity.
Naturally, though, some contributors will not want to simply give
away their IPR, and it is in these cases that a licence agreement is
needed. The project will be granted certain rights over the
contributor’s IPR, and in addition be granted the right to pass on
(or sub-license) these grants to third parties.
Thus
the contributor needs to - at minimum - grant the rights that will be
granted to the end user in the distribution licence (the outbound
licence) in addition to the right to sub-license. When granting
rights it is common to grant a very broad range of rights. This is in
order to avoid the need to return to the contributor for
authorisation to take a desired action with their contribution, such
as releasing under a different licence.
A
CLA should also contain personal information about the person that
signs it, such as a complete name and mailing address. Beware of the
potential implications that storing this information could have in
terms of the data protection law in your country.
It
is very important to record the assignment of copyright or grant of
rights for each contribution. This means a project must track and
record CLAs submitted by contributors. There are two approaches a
project can take when recording CLAs. The first is to insist that
every contribution from a third party is accompanied by a CLA. The
second is to have a CLA signed and submitted to project
administrators for permanent record. Regardless of the type of CLA in
use, a project must ensure that they are recorded permanently. Which
process is the best for a project depends on how the project accepts
third party contributions.
Generally,
contributions to open source projects go through one of two
processes. These are commonly known as review-then-commit and
commit-then-review. The name refers to the order of processing of
contributions.
In
a review-then-commit process, the contribution is submitted to the
project in the form of a software
patch, usually via an issue tracker or a mailing list. The patch
is then peer-reviewed and commented on as appropriate. A subsequent
patch may be submitted in response to the feedback, which in turn
will be peer reviewed. Once the patch has been approved, it will be
committed to the project; that is, the patch will be applied to the
revision
control system and thus will appear in future releases of the
software.
Since
this process requires a patch submission step, it is possible to
require each submission to be accompanied by a signed CLA. Some
projects allow this assignment to be a simple check box in the issue
tracker submission form. Whether recording acceptance in this way is
suitable for your project will be something you will need to discuss
internally, and possibly with legal support, and relates directly to
the project’s tolerance for risk. This approach is found in some
significant open development communities, such as the Apache Software
Foundation. An alternative approach can be found in the Linux kernel
project. Here, patches are submitted to a special mailing list. Each
patch must have the CLA text appended to the end of the submission
email.
Allowing
CLAs to be submitted for each contribution, at the time of
contribution, is efficient in that there is no need to wait for the
CLA to be acknowledged by the project before the contribution can be
made. This streamlining of the submission process is critical if a
project is to welcome new contributors wishing to make even the
smallest contribution, as it ensures that the process of signing a
CLA is less cumbersome than submitting the patch. If it is not, then
many potential contributors simply will not bother to contribute.
In
a commit-then-review process, the contributor is able to commit the
changes directly to the revision control system. This will trigger a
notification to the community that a change has been made and they
will then peer-review the committed code. In some cases, comments
will be forthcoming and changes may be made; in other cases, the
commit will pass review without modification. Clearly,
commit-then-review is only appropriate for contributors who have
shown they have a clear understanding of the project and are able to
make sensible judgement calls about what should/should not be
committed. Most projects that operate a commit-then-review policy
only do so for core members of the development team; other members
operate under a review-then-commit process.
Since
this process allows contributors to add content directly to the
project without going through a separate contribution process, it is
not possible to enforce the signing of the CLA for each contribution.
Therefore it is necessary to have a CLA signed and on file for such
contributors. The increased overhead this creates for both the
project and the contributor is worth the short-term pain, since any
contributor the project trusts to have direct access to the revision
control system is likely to be a significant contributor in the
future.
Regardless
of how a project chooses to record CLAs, it is important that a
record of the CLA for each contribution is kept on file. This is to
ensure that any dispute with respect to ownership of the project
outputs can be resolved quickly and easily. That is, the project must
be able to identify who made the contributions in question and prove
that the necessary copyrights or licence to the IPR contained within
it were granted to the project.
In
order to maintain this audit trail, it is necessary to ensure that
when a patch is applied, it is linked to the appropriate CLA. Again
the process for this depends on the commit policy of the project.
For
review-then-commit it is usual for the commit log message created by
the person reviewing and applying the patch to contain a reference to
the submission record containing the CLA. In the case of submission
from an issue tracker, this will usually be the issue number; in the
case of a mailing list submission, this will be a link to the mailing
list archives.
For
a commit-then-review process, it is necessary to ensure that the
revision control username is associated with a CLA kept on file.
Maintaining
CLAs is not a difficult task; however it does increase the effort
required to make and accept third-party contributions. Most
contributors will start small; that is, they will provide a simple
bug-fix, or a spelling correction. The temptation is therefore to
waive the requirement of CLAs for small contributions. This gives
rise to the question, ‘Must a CLA be in place for every
contribution, no matter how small?’
Some
contributions - very minor bug-fixes or corrections to documentation
(sometimes called ‘driveby contributions’) - are too
insubstantial to be protected by copyright. In the case of
contributions that are substantial, a brief risk-assessment must be
made, weighing the risk of loss from legal action against the cost to
the project of acquiring a CLA. For small contributions, the risk of
loss from legal action would be vanishingly small. For larger chunks
of code, incorporating major functionality, the risks would be much
higher.
Along
with a realistic assessment of risk, a well-planned take-down and
excision policy is vital. If some code in your project becomes the
subject of controversy over ownership, a willingness to cease
distribution temporarily while removing or replacing the code will go
a long way towards mitigating any potential legal losses, and also
dissatisfaction among users.
Since
most employment contracts state that copyright material generated in
the course of an individual’s employment belongs to their employer,
it is likely that a person who works on an open development project
as part of their job will need a CLA signed by their employer. These
are often called ‘Corporate Contibutor Licence Agreements’ or
CCLAs.
- The Apache Software Foundation - Individual Contributor License Agreement [http://www.apache.org/licenses/icla.txt]
- The University of Washington - Contributor License Agreement for UW Calendar [http://www.washington.edu/ucal/CLicense.html]
- The Apache Software Foundation - Corporate Contributor License Agreement [http://www.apache.org/licenses/cla-corporate.txt]
Contributor
Licence Agreements are just one component of a project’s governance
model.
Dịch: Lê Trung Nghĩa
Không có nhận xét nào:
Đăng nhận xét
Lưu ý: Chỉ thành viên của blog này mới được đăng nhận xét.