Các thỏa thuận Giấy phép của Người đóng góp

Contributor Licence Agreements

By Ross Gardler, Rowan Wilson, Published: 04 January 2008, Reviewed: 02 August 2012

Theo: http://www.oss-watch.ac.uk/resources/cla

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 trng 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, 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 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 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.

Why is a CLA necessary?

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. Whe-re copyright has been assigned to a single entity, or whe-re 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 al-ternatively have suitable conditions written into their contract.

What needs to be in a CLA?

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.

Recording CLAs

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 f-rom 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.

Review-then-commit

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 al-ternative 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.

Commit-then-review

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 cre-ates 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.

Associating commits to CLAs

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 cre-ated by the person reviewing and applying the patch to contain a reference to the submission record containing the CLA. In the case of submission f-rom 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.

Risk-assessment

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 f-rom legal action against the cost to the project of acquiring a CLA. For small contributions, the risk of loss f-rom 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.

Corporate Contributor Licence Agreements

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.

Copyright Licence CLAs

• 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]

Copyright Licence CCLAs

• 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

letrungnghia.foss@gmail.com