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

Howto Manage Open Source Licensing in Android Development

Peter Vescuso AllArticles

Law Technology News, May31, 2011

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

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

Lờingười dịch: “Android là một dự án nguồn mở phứctạp được làm từ hơn 165 thành phần con; 80.000 tệpriê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ảnchí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ếncáo cho các công ty kiếm lời dựa trên nền tảng Androidnhư (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õitấ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úptrong việc phát hiện mã nguồn ẩn hoặc gây trở ngạitiềm tàng; (4) Tự động hóa việc giám sát và theo dõiAndroid và các thành phần của nó và (5) Kiểm soát việcsử dụng lại và tiêu chuẩn hóa các thành phần.

Không có câu hỏirằ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ụngtrên máy tính để bàn và xách tay của chúng ta - thư điệntử, 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 độngcủa chúng ta, nhiều, nhiều nữa. Nhiều những gì đangxảy ra trong thế giới di động đang xảy ra trên các điệnthoạ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ếncủ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áytính bảng, HDTV, và thậm chí ô tô; danh sách các ứngdụ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ồnmở 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épkhác nhau. Kho mã nguồn tiến hóa nhanh chóng, với mộtphiên bản chính ra đời cứ trung bình mỗi 3 tháng.

Nhân Linux được tạora với giấy phép GPLv2, Android là một dự án của Googlevà thể hiện một đường riêng trong nhân Linux. Bất chấpgốc rễ của nó trong GPL, quá thừa thãi các thành phầncủ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 địnhnghĩa nguồn mở. Trong khi đa số các mã nguồn Android đượcGoogle đó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ữngthách thức pháp lý trong phát triển Android”.

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

There'sno 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, buyonline, download apps, make dinner reservations -- we now do onour mobile devices, and much, much more. Much of what's happening inthe mobile world is happening on Android phones f-rom manufacturerslike Samsung, Dell, Motorola, LG, Sony-Ericsson, and HTC.

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

Despiteits utility and flexibility, Android is a complex open-source projectmade up of more than 165 subcomponents; 80,000 individual files; and2 gigabytes of code covered by 19 different licenses. The code baseevolves rapidly, with a major release occurring on average everythree months.

Cre-atedwith the GNUGeneral Public License version 2 licensed Linux kernel, Androidis a Google project and represents a separate path in the Linuxkernel. Despite its roots in the GPL, Android's plethora ofcomponents have a number of different licenses, not all of which areapproved by the Open Source Initiative, the standards body for theopen source definition. While the majority of Android codecontributed by Google is governed by the Apache 2.0 license, a numberof components mobile developers rely on are governed by otherlicenses. See Sidebar, "LegalChallenges in Android Development."

Android'srich variety of open source software components are grouped into twocategories: internal and external (see Figure 1).

Figure1: Breakdown of the components inside the Android project. Clickimage to enlarge.

Các thành phần bêntrong là những thành phần được Google tạo ra đặc biệtcho 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épqua lại được lẫn nhau (GPLv2 và LGPL). Bổ sung thêm vào2 thành phần bên ngoài chính, có 30 hoặc hơn các thànhphầ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 khinhững thứ khác sử dụng cácgiấy phép không phải nguồn mở như giấy phép OpenSSLvà 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ạncó thể mong đợi. Vì thế quản lý hàng trăm các thànhphần, nhiều giấy phép, và có liên quan tới các tráchnhiệm thể hiện những thách thức đối với các lậptrình viên và các nhà sản xuất thiết bị mà sử dụngAndroid, cũng như các công ty bên thứ 3 mà họ phát triểncác thành phần phần mềm cho các nhà sản xuất thiếtbị.

Hệ sinh thái nhiềulớp của Android thể hiện sự phát triển nhiều nguồnvà bổ sung thêm sự phức tạp cho nền tảng Android. Cáclập trình viên độc lập có thể đóng góp mã nguồntheo một loạt các giấy phép. Các nhà sản xuất thiếtbị cầm tay có thể các thành phần phần mềm để chạytrên đỉnh của hệ điều hành Android, bổ sung vào việcsử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 đặcbiệt. Các công ty phát triển phần mềm thương mại tạora 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ácgiấy phép và sửa đổi hoặc gia tăng kho mã nguồn củaAndroid. 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ư:

Theinternal components are those cre-ated by Google specifically for theAndroid project; the external components are by and large other opensource projects. Two major external components -- the Linux kerneland WebKit -- are governed by reciprocal licenses (GPLv2 and theLesser General PublicLicense). In addition to the two major external components, anadditional 30 or more internal components (including dbus, grub,emma, e2fsprogs, bluez, Bison), also use reciprocal licenses. Twentyeight components use the GPL and five use the LGPL, while others usenon-open-sourcelicenses such as the OpenSSL and the Bzip2 license.

Allof which means there is more complexity under the covers than youmight expect. Hence the management of hundreds of components,multiple licenses, and associated obligations presents challenges fordevelopers and device manufacturers that use Android, as well as thethird-party companies that develop software components for devicemanufacturers.

TheAndroid community includes Google, independent applicationdevelopers, third-party companies that develop software for mobileand embedded devices, and manufacturers that adopt Android as theoperating system for a given mobile or embedded device.

Android'smany-tiered ecosystem represents multisource development at its best,yet it adds complexity to the Android platform. Independentdevelopers may contribute code under a variety of licenses. Handsetmanufacturers may develop software components to run on top of theAndroid operating system, in addition to modifying and augmenting theAndroid code base to suit a particular hardware or software design.Commercial software development companies creating third-partyapplications may do all of the above: add their own component toAndroid components, use a variety of licenses and modify or augmentthe Android code base. With this complexity comes both license and IPmanagement 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 handsetmanufacturer has modified Android code to take advantage of softwareor hardware feature designs, not knowing how the code and variouscomponents are integrated with their proprietary code, they may findthat they have violated some of the upstream licenses or even berequired to make their proprietary code available under an opensource license such as the GPLv2.

•Although the supply chain starts with Google, many other members ofthe supply chain can al-ter the components used in the software whileretaining the “Android" name. This fragmentation means thateach “version" of Android must be reviewed to understand whatcomponents are being used in it. Even “Android" f-rom the samevendor can change over time; for example, Motorola noted that theyexpect to provide over 300 up-dates to their version of Android thisyear.
• Swapping out one Android component for another cancre-ate legal problems. Google re-wrote some of Android's componentsto use the more permissive Apache license. Toolbox is one suchexample, written to replace the popular open-source componentBusyBox, which has the most enforced open-source license. The BusyBoxsoftware has been the source of at least seven lawsuits and manydisputes that were settled without litigation. A developer may betempted to replace Toolbox for the more familiar BusyBox andunwittingly cre-ate a legal problem.
• Any enhancements orchanges a company makes to Android code are protected by copyright(and potentially patent) protection. Companies need to understand ifthis new code is also subject to the terms of some of the licenses inAndroid, such as the GPLv2, which requires all modifications to bedistributed solely under the GPLv2.

•If a new Android-based device contains commercial third-partyproprietary code, the developer might be in danger of integratingsuch third-party code with open-source licensed code in a mannerwhich would require the proprietary code to be licensed under anopen-source license. If the application a software developer cre-atesfor the Android platform is not a final product but is to beintegrated as a component in a customer's final product (e.g., atablet or a TV), the developer should ensure that the integrationwill not cre-ate a problem with the other software components of thelarger project.

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

Giả thiết mỗi trongsố 19 giấy phép khác nhau trong Android bị bẻ ra thànhnhững bổn phận tương ứng và những bổn phận này đượcchỉ định tới từng sự sử dụng thành phần, hơn 1.700bổn phận sẽ diễn ra. Trong số đó, hơn 1.000 bổn phậnlà có liên quan tới luật pháp, trong khi khoảng 700 là cácbổn phận dạng của các lập trình viên. May thay, hầuhết các công ty không cần khẳng định tuân thủ vớihơ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ổnphận pháp lý thường liên quan tới việc áp dụng mộtsự từ bỏ sự đảm bảo, hạn chế tính pháp lý, bảovệ 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ìnhviê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ộtbổ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àiliệ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ạora công việc cho đội pháp lý. Trong thực tế, các bổnphận mức lập trình viên thường cần phải được quảnlý, không ở mức thành phần, mà ở mức tệp. Trong mộtmôi trường năng động cao như của Android, nơi mà cáctệp thường được cập nhật từ các kho Web, thì việcgiữ theo các bổn phận giấy phép có thể làm nản chí.

Một số nhà sảnxuất, như Samsung, làm một công việc đáng phục về quảnlý các bổn phận pháp lý và tri thức. Ví dụ, điệnthoại Samsung Vibrant (SGH-t959) dựa trên Android có một phầntri 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ườinắm giữ bản quyền. Đối với nhiều người, tri thứcnày là đặc biệt đối với các tệp riêng rẽ hoặc đốivới một danh sách các tệp. Để tuân thủ với các bổnphận này, Samsung đưa ra một tải về các tệp trong Trungtâm Phiên bản Nguồn Mở của hãng, nơi mà bất kỳ aicũng có thể truy cập tới được chúng. Bất kỳ tệpnà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ềnvà những người khác. Đối với nhiều người đóng gópcho 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ầnmềm của họ. Các công ty nên - và có thể dễ dàng - đặtcác công cụ cùng với và các qui trình để chắc chắntri thức này là có.

Theseissues are no different f-rom managing open-source software in othersituations, but the complexity of Android, the rapidity of itschange, and the variety of different versions of Android make it aunique management challenge.

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

However,even the most permissive license typically has an obligation ofacknowledgment and other obligations (marking modification,redistribution requirements, documentation requirements, etc.) thatcan add work to the software developer's backlog of tasks, which thencre-ates work for the legal team. In fact, developer-level obligationsoften need to be managed, not at the component level, but at the filelevel. In a highly dynamic environment like Android's, whe-re filesare frequently up-dated f-rom Web repositories, keeping track oflicense obligations can be daunting.

Somemanufacturers, like Samsung, do an admirable job of managing legalobligations and acknowledgments. For example, the Android-basedSamsung Vibrant (SGH-t959) phone has a legal acknowledgment sectionfor 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 offiles. To comply with its obligations, Samsung provides a download ofthe files on its OpenSource Release Center whe-re anyone can access them. Any filesthat do not comply with file-level obligations could be relativelyapparent to the copyright holders and others. For many contributorsto the open-source community, this acknowledgment is all they ask inreturn for the use of their software. Companies should -- and caneasily – put together tools and processes to make sure thisacknowledgement happens.

Cuối cùng, nhữngthực tiễn tốt nhất đòi hỏi rằng một lập trình viênhoặ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ủahọ 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àmgiả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áoliên quan tới Android, các luật sư làm việc với các côngty 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 organizationunderstands which licenses, components, copyrights, and files are intheir code and what obligations result f-rom that mix of third-partysoftware. The most effective method of managing this complexity iswith tools that provide automated code scanning and reviews toincrease the efficiency of development organizations and reduce riskin an otherwise complex process. In all cases, the legal team musthave oversight.

Toavoid litigation involving Android, attorneys working with companiesthat use Android should follow best practices for ensuring licensecompliance:

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

•Identify and trackall third-party code used.Check all sources for open-source code. Develop a best practice thatdescribes how to manage inbound code, a standard process for managingthird-party and OSS code, which is documented so the entireorganization can understand and support.

•Manual processes arenot fast enough to aid in the discovery of hidden or potentiallyencumbered code.The more automation is in the place, the better able a developer willbe to take advantage of OSS code. Automation also minimizes theimpact of OSS compliance policies, allowingdevelopers 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 ítgậ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ưởnglợi từ cơ hội này, thì các nhà tư vấn pháp lý cầnnhớ trong đầu những sự phức tạp và những bổn phậncủa các giấy phép để chỉ dẫn cho các khách hàng lộiqua nước tối tăm. Cuối cùng, dù, các công ty và các lậptrình viên có thể thấy thành công khổng lồ với Androidvà, 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ậnpháp lý.

•Automate monitoringand tracking of Android and its components.Establishing a workflow process which includes legal components easesdevelopment processes, especially considering Android's frequentreleases (occurring roughly every three months). In addition,remember to integrate with other systems, especially building andchanging management tools, which are natural and convenient places toscan for third party and open-source software code and identifyconflicts early.

•Control componentreuse and standardization.Cre-ate an approved set of components that is accessible and usable bythe entire development team but is also monitored for changes inlegal and other obligations.

Theremay be a few bumps in the road for the Android platform, but it'shere to stay. For companies to benefit f-rom the opportunity, legaladvisers need to bear in mind its complexities and licenseobligations to guide clients through its somewhat murky waters.Ultimately, though, companies and developers can find tremendoussuccess with Android and, with the right training and tooling, easilymanage, track, and comply with legal obligations.

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

letrungnghia.foss@gmail.com