Quản lý cấp phép nguồn mở trong phát triển Android thế nào

How to Manage Open Source Licensing in Android Development

Peter Vescuso All Articles

Law Technology News, May 31, 2011

Theo: http://www.law.com/jsp/lawtechnologynews/PubArticleLTN.jsp?id=1202495469387&slreturn=1&hbxlogin=1

Bài được đưa lên Internet ngày: 31/05/2011

Lời người dịch: “Android là một dự án nguồn mở phức tạp được làm từ hơn 165 thành phần con; 80.000 tệp riêng rẽ; và 2 GB mã nguồn với 19 giấy phép khác nhau. Kho mã nguồn tiến hóa nhanh chóng, với một phiên bản chính ra đời cứ trung bình mỗi 3 tháng”. Việc quản lý các giấy phép của Android vì thế là phức tạp. Để tránh bị kiện tụng pháp lý, bì này đưa ra những khuyến cáo cho các công ty kiếm lời dựa trên nền tảng Android như (1) Áp dụng và tăng cường một chính sách nguồn mở và mã nguồn của bên thứ 3; (2) Xác định và theo dõi tất cả các mã nguồn được sử dụng của bên thứ 3; (3) Các qui trình bằng tay là không đủ nhanh để giúp trong việc phát hiện mã nguồn ẩn hoặc gây trở ngại tiềm tàng; (4) Tự động hóa việc giám sát và theo dõi Android và các thành phần của nó và (5) Kiểm soát việc sử dụng lại và tiêu chuẩn hóa các thành phần.

Không có câu hỏi rằng các thiết bị di động đang thay đổi thế giới mà chúng ta đang sống. Mọi thứ mà chúng ta quen sử dụng trên máy tính để bàn và xách tay của chúng ta - thư điện tử, mua trực tuyến, các ứng dụng tải về, gọi bữa ăn - chúng ta bây giờ làm trên các thiết bị di động của chúng ta, nhiều, nhiều nữa. Nhiều những gì đang xảy ra trong thế giới di động đang xảy ra trên các điện thoại Android từ các nhà sản xuất như Samsung, Dell, Motorola, LG, Sony-Ericsson, và HTC.

Nhưng tính phổ biến của Android không bị hạn chế cho các nhà lập trình và sản xuất di động. Nó cũng đang mở rộng sang các máy tính bảng, HDTV, và thậm chí ô tô; danh sách các ứng dụng cho Android tiếp tục gia tăng (250.000 khi bài này đang được viết).

Bất chấp tính sử dụng và mềm dẻo của nó, Android là một dự án nguồn mở phức tạp được làm từ hơn 165 thành phần con; 80.000 tệp riêng rẽ; và 2 GB mã nguồn với 19 giấy phép khác nhau. Kho mã nguồn tiến hóa nhanh chóng, với một phiên bản chính ra đời cứ trung bình mỗi 3 tháng.

Nhân Linux được tạo ra với giấy phép GPLv2, Android là một dự án của Google và thể hiện một đường riêng trong nhân Linux. Bất chấp gốc rễ của nó trong GPL, quá thừa thãi các thành phần của Android có một số lượng các giấy phép khác nhau, không phải tất cả bọn chúng được phê chuẩn bởi tổ chức Sáng kiến Nguồn Mở OSI, cơ quan tiêu chuẩn cho định nghĩa nguồn mở. Trong khi đa số các mã nguồn Android được Google đóng góp được quản lý theo giấy phép Apache 2.0, thì một số các thành phần mà các lập trình viên di động dựa vào được quản lý theo các giấy phép khác. Xem thêm, “Những thách thức pháp lý trong phát triển Android”.

nhiều thành phần phần mềm nguồn mở (PMNM) của Android được nhóm thành 2 loại: bên trong và bên ngoài (xem Hình 1).

There's no question that mobile devices are changing the world we live in. The things that we used to do on our desktop or laptop -- e-mail, buy online, download apps, make dinner reservations -- we now do on our mobile devices, and much, much more. Much of what's happening in the mobile world is happening on Android phones from manufacturers like Samsung, Dell, Motorola, LG, Sony-Ericsson, and HTC.

But Android's popularity is not limited to mobile developers and manufacturers. It's also being extended to tablets, HDTVs, and even cars; the list of applications for Android continues to grow (250,000 as of this writing).

Despite its utility and flexibility, Android is a complex open-source project made up of more than 165 subcomponents; 80,000 individual files; and 2 gigabytes of code covered by 19 different licenses. The code base evolves rapidly, with a major release occurring on average every three months.

Created with the GNU General Public License version 2 licensed Linux kernel, Android is a Google project and represents a separate path in the Linux kernel. Despite its roots in the GPL, Android's plethora of components have a number of different licenses, not all of which are approved by the Open Source Initiative, the standards body for the open source definition. While the majority of Android code contributed by Google is governed by the Apache 2.0 license, a number of components mobile developers rely on are governed by other licenses. See Sidebar, "Legal Challenges in Android Development."

Android's rich variety of open source software components are grouped into two categories: internal and external (see Figure 1).

Hình 1: Chi tiết các thành phần bên trong dự án Android.

Figure 1: Breakdown of the components inside the Android project. Click image to enlarge.

Các thành phần bên trong là những thành phần được Google tạo ra đặc biệt cho dự án Android; các thành phần bên ngoài phần lớn là các dự án nguồn mở khác. 2 thành phần chính bên ngoài - nhân Linux và WebKit - được quản lý theo các giấy phép qua lại được lẫn nhau (GPLv2 và LGPL). Bổ sung thêm vào 2 thành phần bên ngoài chính, có 30 hoặc hơn các thành phần bên trong (bao gồm dbus, grub, emma, e2fsprogs, bluez, Bison), cũng sử dụng các giấy phép qua lại nhau được. 28 thành phần sử dụng GPL và 5 sử dụng LGPL, trong khi những thứ khác sử dụng các giấy phép không phải nguồn mở như giấy phép OpenSSL và Bzip2.

Tất cả chúng có nghĩa là có sự phức tạp hơn bên dưới lớp vỏ mà bạn có thể mong đợi. Vì thế quản lý hàng trăm các thành phần, nhiều giấy phép, và có liên quan tới các trách nhiệm thể hiện những thách thức đối với các lập trình viên và các nhà sản xuất thiết bị mà sử dụng Android, cũng như các công ty bên thứ 3 mà họ phát triển các thành phần phần mềm cho các nhà sản xuất thiết bị.

Hệ sinh thái nhiều lớp của Android thể hiện sự phát triển nhiều nguồn và bổ sung thêm sự phức tạp cho nền tảng Android. Các lập trình viên độc lập có thể đóng góp mã nguồn theo một loạt các giấy phép. Các nhà sản xuất thiết bị cầm tay có thể các thành phần phần mềm để chạy trên đỉnh của hệ điều hành Android, bổ sung vào việc sửa đổi và gia tăng kho mã nguồn của Android để phù hợp với một thiết kế phần cứng hoặc phần mềm đặc biệt. Các công ty phát triển phần mềm thương mại tạo ra các ứng dụng của bên thứ 3 có thể làm tất cả những thứ ở trên: bổ sung thành phần của riêng họ vào các thành phần của Android, sử dụng một loạt các giấy phép và sửa đổi hoặc gia tăng kho mã nguồn của Android. Với sự phức tạp này tới cả giấy phép và những thách thức quản lý sở hữu trí tuệ IP. Một số ví dụ như:

The internal components are those created by Google specifically for the Android project; the external components are by and large other open source projects. Two major external components -- the Linux kernel and WebKit -- are governed by reciprocal licenses (GPLv2 and the Lesser General Public License). In addition to the two major external components, an additional 30 or more internal components (including dbus, grub, emma, e2fsprogs, bluez, Bison), also use reciprocal licenses. Twenty eight components use the GPL and five use the LGPL, while others use non-open-source licenses such as the OpenSSL and the Bzip2 license.

All of which means there is more complexity under the covers than you might expect. Hence the management of hundreds of components, multiple licenses, and associated obligations presents challenges for developers and device manufacturers that use Android, as well as the third-party companies that develop software components for device manufacturers.

The Android community includes Google, independent application developers, third-party companies that develop software for mobile and embedded devices, and manufacturers that adopt Android as the operating system for a given mobile or embedded device.

Android's many-tiered ecosystem represents multisource development at its best, yet it adds complexity to the Android platform. Independent developers may contribute code under a variety of licenses. Handset manufacturers may develop software components to run on top of the Android operating system, in addition to modifying and augmenting the Android code base to suit a particular hardware or software design. Commercial software development companies creating third-party applications may do all of the above: add their own component to Android components, use a variety of licenses and modify or augment the Android code base. With this complexity comes both license and IP management challenges. Some examples include:

• Với Android, chuỗi cung ứng bắt đầu với Google. Nếu một nhà sản xuất thiết bị cầm tay đã sửa đổi mã nguồn của Android để tận dụng thiết kế tính năng phần mềm hoặc phần cứng, không biết hàng loạt các thành phần và mã nguồn được tích hợp với mã nguồn sở hữu độc quyền của họ, thì họ có thể thấy rằng họ đã vi phạm một số giấy phép thượng nguồn hoặc thậm chí bị yêu cầu làm cho mã nguồn sở hữu độc quyền của họ sẵn sàng theo một giấy phép nguồn mở như GPLv2.

• Mặc dù chuỗi cung ứng bắt đầu với Google, nhiều thành viên khác của chuỗi cung ứng có thể sửa các thành phần được sử dụng trong phần mềm trong khi vẫn giữ tên là “Android”. Sự phân mảnh này có nghĩa là từng “phiên bản” của Android phải được rà soát lại để hiểu những thành phần nào đang được sử dụng trong nó. Thậm chí “Android” từ cùng một nhà cung cấp có thể thay đổi theo thời gian; ví dụ, Motorola đã lưu ý rằng họ mong đợi cung cấp hơn 300 cập nhật cho phiên bản Android của họ trong năm nay.

• Việc hoán đổi một thành phần của Android với thành phần khác có thể tạo ra những vấn đề pháp lý. Google đã viết lại một số thành phần của Android để sử dụng giấy phép Apache cho phép hơn. Hộp công cụ là một ví dụ như vậy, được viết để thay thế thành phần nguồn mở phổ biến BusyBox, mà nó có giấy phép nguồn mở mạnh nhất. Phần mềm BusyBox từng là nguồn của ít nhất 7 vụ kiện và nhiều tranh cãi mã đã được dàn xếp mà không có vụ kiện. Một lập trình viên có thể bị cuốn hút để thay thế hộp công cụ cho BusyBox quen hơn và ngẫu nhiên tạo ra một vấn đề về pháp lý.

• Bất kỳ cải tiến hoặc thay đổi nào một công ty tạo ra cho mã nguồn của Android được bảo vệ bằng bảo vệ bản quyền (và bằng sáng chế một cách tiềm tàng). Các công ty cần hiểu nếu mã nguồn mới này cũng tuân theo những điều khoản của một số giấy phép trong Android, như GPLv2, mà nó đòi hỏi tất cả các sửa đổi sẽ được phân phối chỉ theo GPLv2.

• Nếu một thiết bị mới dựa trên Android có chứa mã nguồn sở hữu độc quyền thương mại của bên thứ 3, thì lập trình viên có thể có nguy cơ đối với việc tích hợp mã nguồn như vậy của bên thứ 3 với mã nguồn được cấp phép nguồn mở theo một cách thức mà nó có thể yêu cầu mã nguồn sở hữu độc quyền sẽ phải cấp phép theo một giấy phép nguồn mở. Nếu ứng dụng mà một lập trình viên phần mềm tạo ra cho nền tảng Android không phải là một sản phẩm cuối cùng nhưng sẽ được tích hợp như một thành phần trong một sản phẩm cuối cùng của khách hàng (như, một máy tính bảng hoặc một TV), thì lập trình viên nên chắc chắn rằng sự tích hợp đó sẽ không tạo ra một vấn đề với các thành phần phần mềm khác của dự án lớn hơn.

• With Android, the supply chain starts with Google. If a handset manufacturer has modified Android code to take advantage of software or hardware feature designs, not knowing how the code and various components are integrated with their proprietary code, they may find that they have violated some of the upstream licenses or even be required to make their proprietary code available under an open source license such as the GPLv2.

• Although the supply chain starts with Google, many other members of the supply chain can alter the components used in the software while retaining the “Android" name. This fragmentation means that each “version" of Android must be reviewed to understand what components are being used in it. Even “Android" from the same vendor can change over time; for example, Motorola noted that they expect to provide over 300 updates to their version of Android this year.
• Swapping out one Android component for another can create legal problems. Google re-wrote some of Android's components to use the more permissive Apache license. Toolbox is one such example, written to replace the popular open-source component BusyBox, which has the most enforced open-source license. The BusyBox software has been the source of at least seven lawsuits and many disputes that were settled without litigation. A developer may be tempted to replace Toolbox for the more familiar BusyBox and unwittingly create a legal problem.
• Any enhancements or changes a company makes to Android code are protected by copyright (and potentially patent) protection. Companies need to understand if this new code is also subject to the terms of some of the licenses in Android, such as the GPLv2, which requires all modifications to be distributed solely under the GPLv2.

• If a new Android-based device contains commercial third-party proprietary code, the developer might be in danger of integrating such third-party code with open-source licensed code in a manner which would require the proprietary code to be licensed under an open-source license. If the application a software developer creates for the Android platform is not a final product but is to be integrated as a component in a customer's final product (e.g., a tablet or a TV), the developer should ensure that the integration will not create a problem with the other software components of the larger project.

Những vấn đề này là không khác với việc quản lý PMNM trong các tình huống khác, nhưng sự phức tạp của Android, sự thay đổi nhanh, và một loạt các phiên bản khác nhau của Android làm cho nó là một sự thách thức quản lý có một không hai.

Giả thiết mỗi trong số 19 giấy phép khác nhau trong Android bị bẻ ra thành những bổn phận tương ứng và những bổn phận này được chỉ định tới từng sự sử dụng thành phần, hơn 1.700 bổn phận sẽ diễn ra. Trong số đó, hơn 1.000 bổn phận là có liên quan tới luật pháp, trong khi khoảng 700 là các bổn phận dạng của các lập trình viên. May thay, hầu hết các công ty không cần khẳng định tuân thủ với hơn 1.700 bổn phận; nhiều bổn phận pháp lý có thể rà soát lại được khi rà soát giấy phép nội bộ. Các bổn phận pháp lý thường liên quan tới việc áp dụng một sự từ bỏ sự đảm bảo, hạn chế tính pháp lý, bảo vệ thương hiệu, hoặc tiến hành các hành động khác mà chúng thường không bổ sung công việc cho các lập trình viên - nhưng có thể cho đội pháp lý.

Tuy nhiên, thậm chí hầu hết giấy phép dạng cho phép nhất thường có một bổn phận hiểu và các bổn phận khác (đánh dấu sửa đổi, các yêu cầu phân phối lại, các yêu cầu tài liệu, ...) mà chúng có thể bổ sung công vệc cho việc bổ sung thêm các tác vụ của lập trình viên, mà sau đó tạo ra công việc cho đội pháp lý. Trong thực tế, các bổn phận mức lập trình viên thường cần phải được quản lý, không ở mức thành phần, mà ở mức tệp. Trong một môi trường năng động cao như của Android, nơi mà các tệp thường được cập nhật từ các kho Web, thì việc giữ theo các bổn phận giấy phép có thể làm nản chí.

Một số nhà sản xuất, như Samsung, làm một công việc đáng phục về quản lý các bổn phận pháp lý và tri thức. Ví dụ, điện thoại Samsung Vibrant (SGH-t959) dựa trên Android có một phần tri thức pháp lý cho tất cả nguồn mở trong điện thoại (mà là hơn 8.000 dòng), đặc biệt có hàng trăm người nắm giữ bản quyền. Đối với nhiều người, tri thức này là đặc biệt đối với các tệp riêng rẽ hoặc đối với một danh sách các tệp. Để tuân thủ với các bổn phận này, Samsung đưa ra một tải về các tệp trong Trung tâm Phiên bản Nguồn Mở của hãng, nơi mà bất kỳ ai cũng có thể truy cập tới được chúng. Bất kỳ tệp nào không tuân thủ với các bổn phận mức tệp có thể rõ ràng liên hệ tới những người nắm giữ bản quyền và những người khác. Đối với nhiều người đóng góp cho cộng đồng nguồn mở, thì tri thức này là tất cả những gì họ yêu cầu để đổi lấy sự sử dụng phần mềm của họ. Các công ty nên - và có thể dễ dàng - đặt các công cụ cùng với và các qui trình để chắc chắn tri thức này là có.

These issues are no different from managing open-source software in other situations, but the complexity of Android, the rapidity of its change, and the variety of different versions of Android make it a unique management challenge.

Assuming each of the 19 different licenses in Android is broken out into its respective obligations and those obligations are assigned to each component usage, over 1,700 obligations come into play. Of these, over 1,000 obligations are law related, while around 700 are developer- type obligations. Fortunately, most companies don't need to confirm compliance with over 1,700 obligations; many legal obligations can be reviewed once during an internal license review. Legal obligations typically involve accepting a disclaimer of warranty, limiting liability, protecting trademarks, or taking other actions that generally do not add work for developers -- but may for the legal team.

However, even the most permissive license typically has an obligation of acknowledgment and other obligations (marking modification, redistribution requirements, documentation requirements, etc.) that can add work to the software developer's backlog of tasks, which then creates work for the legal team. In fact, developer-level obligations often need to be managed, not at the component level, but at the file level. In a highly dynamic environment like Android's, where files are frequently updated from Web repositories, keeping track of license obligations can be daunting.

Some manufacturers, like Samsung, do an admirable job of managing legal obligations and acknowledgments. For example, the Android-based Samsung Vibrant (SGH-t959) phone has a legal acknowledgment section for all open source in the phone (which is over 8,000 lines long), specifically acknowledging hundreds of copyright holders. For many, this acknowledgment is specific to individual files or to a list of files. To comply with its obligations, Samsung provides a download of the files on its Open Source Release Center where anyone can access them. Any files that do not comply with file-level obligations could be relatively apparent to the copyright holders and others. For many contributors to the open-source community, this acknowledgment is all they ask in return for the use of their software. Companies should -- and can easily – put together tools and processes to make sure this acknowledgement happens.

Cuối cùng, những thực tiễn tốt nhất đòi hỏi rằng một lập trình viên hoặc tổ chức phát triển hiểu được các giấy phép, thành phần, bản quyền, và tệp nào trong mã nguồn của họ và những bổn phận nào có từ phần mềm trộn và của bên thứ 3 đó. Phương pháp hữu hiệu nhất để quản lý được sự phức tạp này là với các công cụ đưa ra việc quét và rà soát mã nguồn tự động để gia tăng hiệu quả của các tổ chức phát triển và làm giảm rủi ro trong một qui trình phức tạp. Trong tất cả mọi trường hợp, thì đội pháp lý phải có được sự hiểu biết rõ.

Để tránh kiện cáo liên quan tới Android, các luật sư làm việc với các công ty sử dụng Android nên tuân theo những thực tế tốt nhất để đảm bảo sự tuân thủ giấy phép:

• Áp dụng và tăng cường một chính sách nguồn mở và mã nguồn của bên thứ 3. Biết rằng bạn đang cố gắng làm với nguồn mở và phát triển một chính sách PMNM có nguyên tắc, bằng văn bản và thiết lập các thực tiễn.

• Xác định và theo dõi tất cả các mã nguồn được sử dụng của bên thứ 3. Hãy kiểm tra tất cả các nguồn cho mã nguồn mở. Hãy phát triển một thực tiễn tốt nhất mô tả cách quản lý mã nguồn bên trong, một qui trình tiêu chuẩn cho việc quản lý mã nguồn PMNM của bên thứ 3, mà nó được viết thành tài liệu sao cho toàn bộ tổ chức có thể hiểu và hỗ trợ được.

• Các qui trình bằng tay là không đủ nhanh để giúp trong việc phát hiện mã nguồn ẩn hoặc gây trở ngại tiềm tàng. Càng tự động hóa nhiều, càng tốt cho lập trình viên để tận dụng được ưu thế của mã nguồn của PMNM. Sự tự động hóa cũng làm giảm thiểu ảnh hưởng của các chính sách tuân thủ PMNM, cho phép các lập trình viên tập trung vào việc phát triển hơn là việc tìm lai lịch mã nguồn.

Ultimately, best practices require that a developer or development organization understands which licenses, components, copyrights, and files are in their code and what obligations result from that mix of third-party software. The most effective method of managing this complexity is with tools that provide automated code scanning and reviews to increase the efficiency of development organizations and reduce risk in an otherwise complex process. In all cases, the legal team must have oversight.

To avoid litigation involving Android, attorneys working with companies that use Android should follow best practices for ensuring license compliance:

• Adopt and enforce an open source and third-party code policy. Know what you are trying to do with open source and develop a disciplined, written OSS policy and set of practices.

• Identify and track all third-party code used. Check all sources for open-source code. Develop a best practice that describes how to manage inbound code, a standard process for managing third-party and OSS code, which is documented so the entire organization can understand and support.

• Manual processes are not fast enough to aid in the discovery of hidden or potentially encumbered code. The more automation is in the place, the better able a developer will be to take advantage of OSS code. Automation also minimizes the impact of OSS compliance policies, allowing developers to stay focused on developing rather than code provenance.

• Tự động hóa việc giám sát và theo dõi Android và các thành phần của nó. Việc thiết lập một tiến trình đưa vào các thành phần pháp lý làm dễ dàng cho các qui trình phát triển, đặc biệt xem xét các phiên bản thường xuyên của Android (xảy ra gần mỗi 3 tháng một lần). Hơn nữa, hãy nhớ tích hợp với các hệ thống khác, đặc biệt việc xây dựng và thay đổi các công cụ quản lý, mà chúng là những nơi tự nhiên và thuận tiện để quét đối với mã nguồn của bên thứ 3 và PMNM và xác định các xung đột sớm.

• Kiểm soát việc sử dụng lại và tiêu chuẩn hóa các thành phần. Hãy tạo một tập hợp các thành phần được phê chuẩn có thể truy cập được và sử dụng lại được bởi toàn bộ đội phát triển nhưng cũng giám sát được những thay đổi trong các bổn phận pháp lý và khác.

Có thể là một ít gập gềnh trên con đường đối với nền tảng Android, nhưng đây là chỗ để đỗ. Đối với các công ty hưởng lợi từ cơ hội này, thì các nhà tư vấn pháp lý cần nhớ trong đầu những sự phức tạp và những bổn phận của các giấy phép để chỉ dẫn cho các khách hàng lội qua nước tối tăm. Cuối cùng, dù, các công ty và các lập trình viên có thể thấy thành công khổng lồ với Android và, với việc huấn luyện và có các công cụ đúng, dễ dàng phản lý, theo dõi, và tuân thủ với các bổn phận pháp lý.

• Automate monitoring and tracking of Android and its components. Establishing a workflow process which includes legal components eases development processes, especially considering Android's frequent releases (occurring roughly every three months). In addition, remember to integrate with other systems, especially building and changing management tools, which are natural and convenient places to scan for third party and open-source software code and identify conflicts early.

• Control component reuse and standardization. Create an approved set of components that is accessible and usable by the entire development team but is also monitored for changes in legal and other obligations.

There may be a few bumps in the road for the Android platform, but it's here to stay. For companies to benefit from the opportunity, legal advisers need to bear in mind its complexities and license obligations to guide clients through its somewhat murky waters. Ultimately, though, companies and developers can find tremendous success with Android and, with the right training and tooling, easily manage, track, and comply with legal obligations.

Dịch tài liệu: Lê Trung Nghĩa

letrungnghia.foss@gmail.com