Sân chơi bình đẳng: phát triển một nền kinh tế pha trộn cho mua sắm phần mềm

Levelling the playing field: developing a mixed economy for software procurement

By Paul Anderson, Intelligent Content, Published: 15 May 2008, Reviewed: 14 May 2012

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

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

Lời người dịch: Gần đây cũng từng có những dự thảo chính sách nêu lên cấu trúc của công ty có khả năng để được tham gia vào các vụ thầu mua sắm của chính phủ. Điều này sẽ không khuyến khích, nếu không nói là sẽ loại trừ các công ty nguồn mở, vốn xây dựng dựa vào mô hình kinh doanh các dịch vụ xung quanh các sản phẩm phần mềm của cộng đồng. Những chính sách như vậy “không tính tới thực tế rằng phần mềm được phát triển như một cộng đồng, và làm thế nào người ta đo đếm được 'cấu trúc công ty' của một đội phát triển nguồn mở?”. Bài còn đưa ra nhiều suy luận rất đáng để cho các nhà quản lý, ra quyết định và thực thi chính sách mua sắm của khu vực nhà nước và khu vực giáo dục, cũng như các công ty nguồn mở của Việt Nam tham khảo và suy ngẫm. Kể cả khi đánh giá năng lực công ty, thì các tiêu chuẩn là khác nhau đối với các công ty nguồn đóng và nguồn mở. Xem thêm: Mô hình Độ chín Bền vững của Phần mềm.

Báo cáo từ hội thảo Mua sắm của OSS Watch được tổ chức ở Trường Kinh doanh Saïd, Đại học Oxford, ngày 18/03/2008, của Paul Anderson, Intelligent Content.

Làm thế nào bạn mua sắm thứ gì đó là tự do? Đây là một câu hỏi khó làm bận tâm các chuyên gia phần mềm nguồn mở (PMNM) và các nhà quản lsy mua sắm khu vực nhà nước, và đã hình thành chủ đề của hội thảo của OSS Watch tại Đại học Oxford đã diễn ra tại Oxford ngày 18/03/2008. Trong khi PMNM là sẵn sàng thông qua một giấy phép đảm bảo nó được cung cấp miễn phí (hoặ chi phí thấp), thì chi phí giấy phép chỉ là một phần nhỏ của tổng chi phí sở hữu - TCO (Total Cost of Ownership của một giải pháp CNTT.

Dù vậy, bức tranh PMNM như một lựa chọn tự do thì đây là một trong nhiều chuyện hoang đường mà đã bùng lên xung quanh nguồn mở và đã làm cho nó khó mua sắm, đặc biệt trong giáo dục và các cơ quan nhà nước khác. Sự xô đẩy chính tới suy nghĩ ở hội nghị là, so với phần mềm nguồn đóng, PMNM không hưởng một sân chơi bình đẳng khi nói tới việc mua sắm.

Vì thế vì sao PMNM không có được sự đối xử công bằng? Một phần câu trả lời nằm ở thực tế rằng, qua nhiều năm, PMNM và phần mềm tự do (PMTD) đã được xem như một sản phẩm thích hợp - một chút, tốt, geeky (cho dân chuyên nghiệp). Có một sự thừa nhận chung rằng khó để triển khai, liên quan tới nhiều thành phần nhỏ được đặt vào cùng nhau, không mở rộng phạm vi tốt và chỉ không 'sẵn sàng cho doanh nghiệp'. Yếu tố chi phí cũng kích thích cho sự thừa nhận này. Mọi người tin tưởng rằng PMNM là miễn phí, và, vì điều này, nó không thể thực sự tốt như các phần mềm sở hữu độc quyền, thứ 'phải trả tiền'. Giả thiết là nếu PMNM thực sự tốt như phần mềm sở hữu độc quyền, thì chắc chắn mọi ntuwowif có thể lấy tiền cho nó, đúng thế không?

Các câu chuyện hoang đường dạng đó và những rào cản về tổ chức có liên quan tới nguồn mở là phức tạp và bện lại với nhau, và hiệu ứng mạng là sự tiếp nhận PMNM trong khu vực nhà nước còn chưa được cao như đáng ra nó phải có. Việc gỡ rối cho các vấn đề đó để có được sân chơi bình đẳng trong mua sắm đã hình thành nên chủ đề của hội thảo của OSS Watch mà đã lôi cuốn được đa số rộng rãi các nhân viên khu vực nhà nước, các lập trình viên và các công ty phần mềm có liên quan trong các giải pháp nguồn mở.

Ross Gardler, người quản lý OSS Watch, đã mở đầu cuộc hội thảo bằng việc phác họa một số lý do vì sao quan trọng để đưa PMNM vào bất kỳ thảo luận mua sắm nào. Trước hết, có chiến lược rộng lớn hơn và ngữ cảnh 'chính trị': một số lượng đang gia tăng các chính phủ, cơ quan giáo dục và các cơ quan khu vực nhà nước đang sử dụng nguồn mở và việc phác thảo những khuyến cáo và chính sách bắt buộc rằng ít nhất nó phải được cân nhắc một cách nghiêm túc¹.

Thứ 2, hội thảo đã học được rằng có một số lý do vì sao nguồn mở nên được cân nhắc về giá trị của nó. Vì bản chất tự nhiên mở sẵn có của nó, PMNM đưa ra tính mềm dẻo và an ninh được cải thiện². Tuy nhiên, về mặt chiến thuật, việc đưa ngay PMNM vào một qui trình đánh giá khi mua sắm có thể có những lợi ích, thậm chí nếu nó không phải là người thắng cuộc cuối cùng. Ross đã nói với hội thảo: 'Bạn có thể sử dụng nó như một công cụ mặc cả. Bằng việc khuyến khích các công ty nguồn mở nhảy vào thị trường và tham gia vào [qui trình] mua sắm, bạn đang đặt sức ép lên các nhà cung cấp [nguồn đóng] phải trở thành các nhà cung cấp tốt hơn, để giảm các chi phí của họ và làm cho các giải pháp của họ áp dụng được nhiều hơn cho các nhu cầu riêng rẽ của bạn'.

Chi phí

Có áp lực đáng kể để tiết kiệm tiền trong mua sắm phần mềm giáo dục. PMNM là tự do đối với những hạn chế cấp phép hầu hết có tính trừng phạt và các phí giấy phép liên tục mà tạo thành một phần đáng kể của chi phí mua sắm các phần mềm sở hữu độc quyền. Tuy nhiên, đây không phải trường hợp mà PMNM là hoàn toàn tự do không mất chi phí. Có nhiều chi phí bổ sung và thường là không trực tiếp sẽ phải xem xét đối với toàn bộ vòng đời của một ứng dụng nguồn mở - thường được biết như là Tổng Chi phí Sở hữu - TCO (Total Cost of Ownership) - và chúng nên luôn là yếu tố đặc trung trong các qui trình mua sắm.

Matthew Dovey, Giám đốc chương trình JISC, Nghiên cứu Điện tử (e-Research), đã viện lý rằng chi phí là một trong nhiều chuyện hoang đường của nguồn mở: '[Có một chuyện hoang đường rằng] PMNM là tự do, hoặc dạng tự do, và rằng [chúng ta có thể] giả thiết Tổng Chi phí Sở hữu là 0. [Thực tế] các đầu mục ngân sách là khá khác nhau, nhưng nó sẽ vẫn mất tiền'.

Simon Mather, từ Ufi (Đại học về công nghiệp), đã thảo luận về nhiều chi phí ít rõ ràng hơn đó khi trình bày kinh nghiệm của ông về việc chuyển đổi công nghệ của viện trường của ông từ môi trường Windows ASP của Microsoft sang một môi trường nguồn mở dựa vào Java và Linux. Ông đã lưu ý tới các chi phí trực tiếp và gián tiếp của dịch vụ và sự duy trì liên tục, nhưng ông cũng đã chỉ ra rằng với PMNM thì nhà cung cấp không sinh ra bất kỳ doanh số nào từ phí giấy phép ở trước đó. Hệ quả là, nhiều công ty nguồn mở kiếm sống từ một loạt khác nhau các mô hình kinh doanh mà được cấu trúc xung quanh việc cung cấp các dịch vụ sau bán hàng, huấn luyện và hỗ trợ tài liệu.

Bổ sung thêm, và thứ gì đó mà ít có khả năng định lượng hơn, là các chi phí đầu tư vào huấn luyện để phát triển sự tinh thông trong nội bộ. Điều này cho phép các nhân viên trở thành nhiều hơn là chỉ một người tiêu dùng thụ động của một sản phẩm sở hữu độc quyền - sao cho họ có thể vừa sử dụng phần mềm, vừa tham gia với các cộng đồng hỗ trợ trực tuyến, và hiểu cách để giải quyết những thách thức về quản lý công việc theo một cách thức linh động hơn và chủ động tích cực hơn. Tuy nhiên, như Simon đã chỉ ra, các chi phí đó, trong khi khó để định lượng, lại có thể được xem xét như một phần của một sự đầu tư dài hạn: 'Chúng ta đang đầu tư vào tương lai của chúng ta. Nguồn mở thực sự đóng góp khổng lồ cho các khả năng kỹ thuật của chúng ta và không chỉ về những gì chúng ta tùy biên thích nghi trong cơ sở mã của chúng ta. Nó cũng là về văn hóa trong đội phát triển và đội đó đang làm việc với mã và làm việc với cộng đồng và hiểu cộng đồng đang đi đâu'.

Độ chín

Thậm chí nếu được chấp nhận rằng các giải pháp nguồn mở sẽ có một vai trò trong mua sắm của khu vực nhà nước, thì rõ ràng là không phải tất cả các PMNM là y như nhau và rằng có những mức độc về độ chín phần mềm. Ross Gardler đã nói với hội thảo: 'Không phải tất cả nguồn mở là như nhau. Chỉ giống như không phải tất cả nguồn đóng là như nhau. Nếu [bạn] đi lên kho nguồn mở SourceForge thì bạn có thể thấy thứ gì đó giống như 150.000 dự án trên đó³. Dù tôi không bao giờ đã thực hiện một phân tích đầy đủ, thì chỉ một phần nhỏ của các dự án đó là thực sự hữu dụng, bền vững và liên tục hoạt động'.

Điều gì điều này thực sự nói lên, là sự khác biệt giữa các dự án nguồn mở chưa chín muồi và các giải pháp hạng chuyên nghiệp, được rèn rũa tốt mà chúng có một cộng đồng tuyệt vời những người sử dụng và lập trình viên, và một hồ sơ theo dõi tốt đối với việc đưa ra lộ trình được nghĩ chu đáo cẩn thận. Tuy nhiên, đáng lưu ý rằng các yêu cầu cho sự chín muồi đó là công việc 2 chiều. Andy McKay, từ Blue Fountain, đã nói trong phiên thảo luận nhóm rằng thường có một 'lỗ hổng mua sắm lớn' mà nhiều tổ chức và cơ quan không đi qua. Họ được chuẩn bị để tải về phần mềm tự do, nhưng sau đó họ không được chuẩn bị để tham gia vào các cộng đồng phát triển và hỗ trợ được xây dựng xung quanh nó, cũng không sử dụng một công ty dịch vụ là bên thứ 3 để giúp họ sử dụng được nó. Điều này có nghĩa là họ thường thất bại để có được lợi ích đầy đủ của PMNM và điều này sau đó có thể đóng góp vào một cảm giác vỡ mộng với PMNM.

Các diễn giả các khác nhau cũng đã chỉ ra rằng khái niệm nguồn mở vẫn còn gây tranh cãi. Ví dụ, có thứ gì đó được biết như là nguồn mở què quặt, nơi mà một cơ quan thực sự phải trả tiền cho một phí giấy phép cho sản phẩm đầy đủ, hơn là sử dụng phiên bản thử nghiệm với chi phí bị cắt bớt, tự do để tải về. Mark Taylor, Chủ tịch của Nhóm công nghiệp (Consortium) Nguồn mở, đã đưa ra một thông điệp cốt tử, viện lý rằng có một sự khác biệt giữa các công ty mà tham gia đầy đủ với các đặc tính và các qui trình của sự phát triển nguồn mở và các công ty mà các sản phẩm của họ đơn giản 'có một lớp bụi quảng cáo marketing huyền ảo về nó'.

Một cách để nắm bắt được với tất cả điều này là hãy sử dụng một trong số các Khung đánh giá. Chúng là những qui trình chính thức, được viết tốt thành tài liệu cho dạng ra quyết định này và chúng tạo thuận lợi cho qui trình rà soát lại PMNM và tính bền vững của nó, đánh giá đối với các chỉ tiêu và tạo ra các điểm trọng số. Các khung công việc nổi tiếng đó bao gồm: Mô hình Độ chín PMNM - OSMM (Open Source Maturity Model) từ CapGemni, OSMM từ Navica, Định phẩm chất và Lựa chọn PMNM - QSOS (Qualification and Selection of Open Source software), và mô hình Xếp hạng Tính sẵn sàng của Doanh nghiệp – RRR (Business Readiness Rating).

Các nhà cung cấp

Nhiều nhà cung cấp nguồn mở và thị trường dịch vụ được tạo nên từ các tay chơi nhỏ hơn, và điều này thường biến đổi thành một sự thừa nhận của thị trường như là 'bị phân mảnh'. Như John Lane của Imperial College, đưa ra: 'Một trong những rào cản lớn đối với mua sắm nguồn mở là sự sợ hãi rằng bạn sẽ không có khả năng tương tác với các bên thứ 3 bên ngoài tổ chức của bạn nếu bạn chọn thứ gì đó không phải là một trong những tay chơi lớn. [Về cơ bản đây là] lý lẽ cũ mèm - “Bạn không bao giờ bị đuổi việc vì mua của IBM” - và bạn phải vượt qua được cây cầu này'.

Một cách theo đó điều này đang được giải quyết là thông qua sự tạo ra các nhóm công ty (Consortia) - các nhóm các công ty mà họ đồng ý trình bày công việc của họ cùng nhau và những người thường làm việc trong mối quan hệ đối tác. Tuy nhiên, điều này cũng làm việc theo cách khác được. Ross Gardler đã nói cho hội thảo rằng OSS Watch đang tích cực 'khuyến khích các viện trường [giáo dục] tạo ra một chính sách nguồn mở', và điều này từng được tăng cường bằng một thành viên của khán thính phòng, người đã nhắc tới các nhóm mua sắm trong giáo dục trung học và cao hơn như Nhóm Mua sắm các Đại học ở Luân Độ - LUPC (London Universities Purchasing Consortium), một phần của dịch vụ⁴ Mua sắm web do JISC cấp vốn và Nhóm Mua sắm của các Đại học miền Nam - SUPC (Southern Universities Purchasing Consortium).

Tuy nhiên, nhiều diễn giả cũng đồng ý rằng thị trường đó đã đang thay đổi và rằng, rất thường thấy, các qui trình mua sắm là không đủ mềm dẻo để điều khiển điều này. Ví dụ, Vince Blogg của Hubstone, đã viện lý rằng: '[Mua sắm] không cần thay đổi để phản ánh cách mà toàn bộ thị trường tư vấn, nguồn mở và đóng, đang thay đổi. Nhiều công việc hơn đang được các doanh nghiệp nhỏ hơn và các doanh nghiệp siêu nhỏ đã và đang làm'.

Điều này đã được Mark Taylor khẳng định thêm, ông còn là diễn giả chính thứ 2, khi ông đã chỉ ra cách mà thị trường cung ứng đang thay đổi. Ông đã nói rằng có một số lượng đang gia tăng nhanh chóng các nhà cung cấp PMNM và họ khác nhau từ các công ty lớn qua các công ty đa quốc gia và một số cái tên lớn nhất trong nền công nghiệp máy tính: 'Thậm chí Microsoft đang có những khoảng khắc nguồn mở của nó'.

Mark cũng nhanh chóng phân biệt giữa 'thương mại' và 'sở hữu độc quyền': '[Một số người] phân biệt giữa các công ty thương mại và không thương mại, điều ngụ ý đang là nguồn mở là không phải là thương mại. Nhưng thực tế sự khác biệt là giữa sở hữu độc quyền và không sở hữu độc quyền và điều này là những gì chúng ta nhận thức được'. Quan điểm của ông rằng điều quan trọng phải nhận thức được rằng các giải pháp nguồn mở có thể các công ty thương mại cung cấp và có khả năng để cung cấp sự hỗ trợ và các dịch vụ cần thiết (huấn luyện, …) và là người cũng có thể hành động như bên thứ 3 trong các thỏa thuận hợp đồng.

Một trong những rào cản đáng kể trong khía cạnh này là bản thân qui trình mua sắm. Để tham gia vào lời mời thầu chính thức - ITT (Invitation to Tender) và qui trình đấu thầu (bao gồm một bảng câu hỏi thẩm định chất lượng trước, hoặc PQQ (Pre-Qualification Questionnaire), các nhà cung cấp tiềm năng cần phải biết về ITT trước hết. Michael Farrman, từ Alfresco, đã chỉ ra: 'Một [đặc tính của] các nhà cung cấp phần mềm truyền thống là họ có các đội bán hàng trực tiếp lớn, công việc của họ một phần là tìm kiếm các vụ thầu đó'. Đây là một thách thức lớn cho nền công nghiệp nguồn mở khi mà mô hình bán hàng là khác và nó phải biết để trở thành sống được một cách thương mại. Lars Ronning của Zimbra đã nói: 'Chúng tôi không có lực lượng bán hàng cần thiết để đi ra và lúc nào cũng theo dõi thị thường được'.

Một nhà cung cấp gợi ý rằng nếu các qui trình mua sắm cho phép nó, thì việc thông báo cho các công ty về vụ thầu sắp tới có thể sẽ giúp được. Điều này taoja ra một số tranh luận đáng kể giữa những người thảo luận trong các phiên theo nhóm khi họ tranh luận về tác động mà những hạn chế khác nhau, như các qui tắc cạnh tranh của Liên minh châu Âu (EU), có về cách mà các viện trường có thể đi xa tới đâu để đưa các công ty nguồn mở vào trong qui trình đấu thầu.

Mike Fraser, giám đốc OSS Watch, người có liên quan tới các qui trình mua sắm tại Oxford, đã bình luận: '[Chúng tôi cần chắc chắn] chúng tôi không đặt ra một cách ngẫu nhiên các khoảng trong ITT mà có thể loại trừ các nhà cung cấp PMNM. Trong [qui trình] mua sắm truyền thống thường có một số trang về công ty và doanh số, những gì hợp lệ là nó sẽ phá sản trước khi bạn có được các yêu cầu chức năng'.

Sự nhấn mạnh này vào cấu trúc công ty vì thế đôi khi đã làm tổn hại đối với đánh giá các kỹ năng và khả năng thực hiện công việc. Nó cũng không tính tới thực tế rằng phần mềm được phát triển như một cộng đồng, và làm thế nào người ta đo đếm được 'cấu trúc công ty' của một đội phát triển nguồn mở?

Sân chơi bình đẳng

Vì thế, biết rằng có những rào cản trong các viện trường đối với sự mua sắm nguồn mở, và biết rằng nó nên được cân nhắc, những khuyến cáo hoặc cách thức trong đó các viện trường có thể cải thiện các qui trình đó là gì? Làm thế nào có thể có được một sân chơi bình đẳng? Một số khuyến cáo được đưa ra từ những diễn giả chính và các thảo luận nhóm.

Một trong những khuyến cáo là từ một thảo luận xung quanh tầm quan trọng của các tiêu chuẩn mở và sự chuyển dữ liệu về lâu dài. Boris Devouge, từ Red Hat, đã viện lý một cách nhiệt tình rằng: 'Một trong những câu hỏi đầu tiên khi sử dụng tiền nhà nước sẽ là: Bạn có đang sử dụng các tiêu chuẩn mở không? Liệu dữ liệu của chúng tôi có an toàn không? Bạn cần biết rằng [với] giải pháp bạn đang bảo vệ bây giờ, [điều đó] trong thời gian 10 năm nữa nó không lấy của bạn 40 lần nhiều hơn khi chuyển đổi dữ liệu ở đâu đó. Điều này rất thường xuyên bị bỏ qua trong các tài liệu mua sắm mà tôi nhận được từ chính phủ, các trường học, các trường đại học [yêu cầu chúng tôi] điền là một yêu cầu. Nó sẽ là câu hỏi số 1. [Vào lúc này], 5 hoặc 6 câu hỏi đầu tiên là giấy phép của bạn là gì, bạn có đưa ra được giấy phép rộng rãi hay không, … Qui trình đó, ngay từ ban đầu, là dựa vào phần mềm nguồn đóng. Điều này cần phải tiến hóa'.

Những khuyến cáo khác đã kết luận:

• giao tiếp tốt hơn với các nhà quản lý cao cấp xuyên khắp giáo dục trung và cao học (HE/FE) như đối với những lợi ích và cạm bẫy tiềm tàng của việc sử dụng các giải pháp nguồn mở⁵.
• những nỗ lực tiếp tục nên được thực hiện để cam kết tham gia với các nhóm như LUPC và SUPC trong một qui trình chính thức. Cũng cảm thấy rằng các viện trường giáo dục nên cam kết tham gia với các nhóm đang được các nhà cung cấp giải pháp nguồn mở thương mại tạo ra để giúp họ hiểu những yêu cầu đặc thù của giáo dục sao cho các thành viên của họ có thể tham gia vào với qui trình mua sắm.
• các cơ quan CNTT-TT giáo dục với khái quát chung của lĩnh vực này như UCISA và BECTA nên hỗ trợ các viện trường bằng việc huấn luyện và tri thức theo yêu cầu để cải thiện các mức truy cập cho các giải pháp và công ty nguồn mở. Công việc có thể được tiến hành để cải thiện ITT và các qui trình của bảng câu hỏi trước khi mua sắm (PPQ) trong các viện trường. Từng có cảm giác rằng một nói tốt lành để bắt đầu có thể là rà soát lại ITT.

Để tóm tắt lại, cảm giác chung là nhân sự mua sắm cần phải được huấn luyện tốt hơn để hiểu nguồn mở là gì, vì sao nó có thể giúp phân phối một giải pháp tốt hơn, cách đưa nó vào một đánh giá mua sắm có thể làm sắc nhọn các vụ thầu đối với các công ty nguồn đóng và, đặc biệt, các vấn đề phải làm với sự chuyển đổi dữ liệu và các chi phí về dài hạn.

Matthew Dovey đã gói ghém lại điều này một cách ngăn nắp: 'Chúng tôi [JISC và OSS Watch] không vẫy một biểu ngữ nói PMNM sẽ cứu thế giới. Chúng tôi muốn cố vấn cho khu vực này về những vấn đề thực khi nói về việc chọn nguồn mở so với nguồn đóng theo các giá trị của nó và không theo bất kỳ bè phái tôn giáo nào Những gì chúng tôi muốn thấy cuối cùng là một nền kinh tế pha trộn'.

A report from the OSS Watch Procurement workshop held at the Saïd Business School, The University of Oxford, 18 March 2008, by Paul Anderson, Intelligent Content.

How do you procure something that’s free? This is a conundrum that is preoccupying open source software experts and public sector procurement managers, and formed the subject of Oxford University’s OSS Watch workshop held in Oxford on 18 March 2008. While open source software (OSS) is available via a licence that ensures it is provided free of charge (or at low cost), the licence cost only makes up a small part of the total cost of ownership (TCO) of an IT solution. Nevertheless, the image of OSS as a free option this is one of the many myths that have sprung up around open source and which have made it difficult to procure, particularly in education and other public institutional settings. The main thrust of the thinking at the conference was that, compared to closed source software, OSS doesn’t enjoy a level playing field when it comes to procurement.

So why doesn’t open source software get a fair deal? Part of the answer lies in the fact that, over the years, open source and free software has come to be seen as a niche product - a bit, well, geeky. There’s a general perception that it is difficult to implement, involves lots of smaller components being put together, does not scale well and is just not ‘enterprise ready’. The cost factor has also fuelled this perception. People believe that OSS is free of charge, and, because of this, that it can’t really be just as good as ‘paid for’, proprietary software. The assumption is that if OSS really were as good as proprietary software, then surely people would charge for it, wouldn’t they?

These and other myths and organisational barriers associated with open source are complicated and intertwined, and the net effect is that the take-up of OSS across the public sector has not been as high as it should be. Untangling these issues in order to level the procurement playing field formed the subject of the OSS Watch workshop, which attracted a wide variety of public sector staff, software developers and companies involved in open source solutions.

Ross Gardler, Manager of OSS Watch, opened the workshop by outlining a number of reasons why it is important to include OSS in any procurement discussions. Firstly, there is the wider strategic and ‘political’ context: a growing number of governments, educational agencies and public sector bodies are using open source and outlining recommendations and policies that mandate that it should at least be seriously considered1.

Secondly, the workshop learned that there are a number of reasons why open source should be considered on its merits. Due to its inherently open nature, OSS provides flexibility and enhanced security2. Tactically, however, just including OSS in a procurement evaluation process can have benefits, even if it’s not the final winner. Rosstold the workshop: ‘You can use it as a bargaining tool. By encouraging open source companies to enter the market place and engage with your procurement [process], you are putting pressure on those [closed source] suppliers to be better suppliers, to reduce their costs and to make their solutions more applicable to your individual needs.’

Cost

There is considerable pressure to save money on educational software procurement. Open source software is free from the most punitive licensing restrictions and the ongoing licence fees that form a considerable part of the cost of procuring proprietary software. However, it is not the case that OSS is completely free of cost. There are many additional and often indirect costs to be considered over the full life cycle of an open source application - commonly known as Total Cost of Ownership (TCO) - and these should always be factored in to procurement processes.

Matthew Dovey, JISC Programme Director, e-Research, argued that cost was one of the many myths of open source: ‘[There is a myth that] OSS is free, or sort of free, and that [we can] assume the Total Cost of Ownership is zero. [Actually] the budget headings are slightly different, but it will still cost money.’

Simon Mather, from Ufi (University for industry), discussed many of these less obvious costs when presenting his experience of migrating his institution’s technology from the proprietary Microsoft Windows ASP environment to an open source environment based on Java and Linux. He noted the direct and obvious costs of ongoing service and maintenance, but he also pointed out that with OSS the supplier doesn’t generate any revenue from the upfront licence fee. Consequently, many open source companies make a living from a variety of business models that are structured around providing after-sales services, training and documentation support.

In addition, and something that is less quantifiable, are the costs of investing in training to develop in-house expertise. This enables staff to become more than just a passive consumer of a proprietary product - so that they can both use the software and engage with the online support communities, and understand how to address the managerial challenges of working in a more agile and more proactive way. However, as Simon pointed out, these costs, while difficult to quantify, can be considered part of a long-term investment: ‘We are investing in our future. Open source really does contribute enormously to our technical capabilities and it’s not just about what we adopt in our code base. It is also about culture within the development team and that the team is working with the code and working with the community and understanding where that community is going.’

Maturity

Even if it is accepted that open source solutions should have a role in public sector procurement, it is clear that not all open source software is the same and that there are degrees of software maturity. Ross Gardler told the workshop: ‘Not all open source is equal. Just as not all closed source is equal. If [you] go to the SourceForge open source repository you would see something like 150,000 projects on there3. Although I have never done a full analysis, only a very small proportion of these projects are genuinely useful, sustainable and continuing with activity.’

What this really boils down to, is the difference between immature open source projects and well-forged, enterprise-class solutions which have an excellent community of users and developers, and a good track record of delivering a well-thought-out roadmap. However, it is worth noting that these requirements for maturity work both ways. Andy McKay, from Blue Fountain, said in the panel sessions that there is often a ‘buying chasm’ that many organisations and institutions don’t cross. They are prepared to download the free software, but then they are not prepared to engage with the development and support communities built around it, nor to employ a third-party service company to help them make use of it. This means they often fail to get the full benefit of the open source software and this may then contribute to a feeling of disillusionment with OSS.

Various speakers also pointed out that the term open source has been disputed. For example, there is something known as crippled open source, where an institution has to actually pay a licence fee for the full product, rather than use the cut-down, free to download, trial version. Mark Taylor, President of the Open Source Consortium, issued a caveat emptor message, arguing that there is a distinction between those companies that are fully engaged with the open source development ethos and processes and those whose products simply ‘have the magic marketing pixie dust on it’.

One way of getting to grips with all of this is to use one of a number of Evaluation Frameworks. These are well-documented, formal processes for this kind of decision-making and they facilitate the process of reviewing OSS and its sustainability, assessing against criteria and producing weighted scores. Well-known frameworks include: OS Maturity Model (OSMM) from CapGemni, OSMM from Navica, QSOS (Qualification and Selection of Open Source software), and the Business Readiness Rating model (BRR).

Suppliers

Much of the open source supplier and service market is made up of smaller players, and this often translates into a perception of the marketplace as being ‘fragmented’. As John Lane of Imperial College, put it: ‘One of the big barriers to open source procurement is the fear that you will not be able to interact with third parties outside your organisation if you choose something that isn’t one of the big players. [In essence it is] the old argument – “You never get sacked for buying IBM” - and you have to cross that bridge.’

One way in which this is being addressed is through the creation of consortia – groups of companies who have agreed to present their work together and who often work in partnership. However, this also works the other way around. Ross Gardler told the workshop that OSS Watch is actively ‘encouraging [educational] institutions to create an open source policy’, and this was reinforced by a member of the audience who mentioned higher and further education procurement consortia such as LUPC (the London Universities Purchasing Consortium, part of the JISC-funded Procureweb service4) and SUPC (Southern Universities Purchasing Consortium).

However, many speakers agreed that the market was changing and that, all too often, procurement processes were insufficiently flexible to handle this. Vince Blogg, for example, of Hubstone, argued that: ‘[Procurement] does need to change to reflect the way the whole consultancy market, open and closed source, is changing. Much more work is being undertaken by smaller enterprises and micro-businesses’.

This was reinforced by Mark Taylor, who was also the second keynote speaker, when he pointed out how the supply market is changing. He stated that there are a rapidly growing number of suppliers of open source software and these vary from micro-companies through to large multinationals and some of the biggest names in the computer industry: ‘Even Microsoft is having its open source moments.’

Mark was also quick to make the distinction between ‘commercial’ and ‘proprietary’: ‘[Some people] make a distinction between commercial and non-commercial companies, the implication being that open source is non-commercial. But actually the distinction is between proprietary and non-proprietary and this is what we recognise.’ His point was that it is important to be aware that open source solutions can be provided by commercial companies that are able to provide the necessary support and services (training, etc.) and who can also act as the third party in contractual arrangements.

One of the significant barriers in this respect is the procurement process itself. In order to participate in the formal invitation to tender (ITT) and tendering process (including a Pre-Qualification Questionnaire, or PQQ), potential suppliers need to know about the ITT in the first place. Michael Farman, from Alfresco, pointed out: ‘A [characteristic of] traditional software vendors is that they have large, direct sales teams whose job is partly to look for these tenders.’ This is a big challenge to the open source industry as its sales model is different and it has to be in order to be commercially viable. Lars Ronning of Zimbra, said: ‘We don’t have the sales force that is necessary to go out and track the market all the time.’

One supplier suggested that if procurement processes allowed it, then notifying companies of a forthcoming tender would help. This resulted in some considerable debate among panellists as they discussed the effect that various restrictions, such as EU competition rules, have on how far institutions can go to involve open source companies in the tendering process.

Mike Fraser, OSS Watch director, who is involved in procurement processes at Oxford, commented: ‘[We need to make sure] we don’t inadvertently put items in the ITT which may exclude OSS suppliers. In a traditional procurement [process] there is usually quite a number of pages about the company and its turnover, what’s the likelihood that it will not go bust, before you get to the functional requirements.’

This focus on company structure is therefore sometimes made at the expense of the assessment of skills and ability to do the job. It also doesn’t take account of the fact that the software is developed as a community, and how should one measure the ‘corporate structure’ of a virtual, open source development team?

Levelling the playing field

So, given that there are barriers within institutions to the procurement of open source, and given that it should be considered, what are the recommendations or ways in which institutions can improve their processes? How can the playing field be levelled? A number of recommendations came out of the keynote speakers and panel discussions.

One of the key recommendations came out of a discussion around the importance of open standards and long-term migration of data. Boris Devouge, from RedHat, argued passionately that: ‘One of the very first questions when using public money should be: Are you using open standards? Is my data safe? You need to know that [with] the solution you are advocating now, [that] in ten years’ time it’s not going to cost forty times as much to migrate the data somewhere. This is so often overlooked in the procurement papers that I receive from government, schools, universities [asking us] to field a request. It should be the number one question. [At the moment], the first five or six questions are what is your licence, do you provide site-wide licence, etc. The process, right from the start, is based on closed source software. This needs to evolve.’

Other recommendations included:

• better communication with senior managers across HE/FE as to the potential benefits and pitfalls of making use of open source solutions5
• further efforts should be made to engage with consortia such as LUPC and SUPC in a formal process. It was also felt that educational institutions should engage with the consortia being formed by commercial open source solution providers to help them to understand the special requirements of education so that their members could engage with the procurement process.
• educational ICT bodies with an overview of the sector such as UCISA and BECTA should assist institutions with the training and knowledge required to improve the levels of access for open source solutions and companies. Work could be undertaken to improve the ITT and the pre-purchase questionnaire (PPQ) processes within institutions. It was felt that a good place to start would be to review the ITT.

To sum up, the general feeling was that procurement staff need to be better trained in what open source is, why it can help deliver a better solution, how its inclusion in a procurement evaluation can sharpen the bids from closed source companies and, in particular, issues to do with data migration and long-term costs.

Matthew Dovey encapsulated this neatly: ‘We [JISC and OSS Watch] don’t wave a banner saying OSS will save the world. We want to advise the sector on the true issues when it comes to choosing open source versus closed source so that we have a level playing field and so that the software that is finally chosen is chosen on its merits and not on any religious faction. What we want to see ultimately is a mixed economy.’

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Liệu Bắc Triều Tiên có Stuxnet của riêng mình?

Does North Korea Have Its Own Stuxnet?

Sidney Raphael, March 21, 2013

Theo: http://www.americanthinker.com/blog/2013/03/does_north_korea_have_its_own_stuxnet.html

Bài được đưa lên Internet ngày: 21/03/2013

Lời người dịch: Các cuộc tấn công không gian mạng vừa qua vào các hệ thống tài chính ngân hàng của Hàn Quốc, ngoài lý do chính trị có liên quan tới cuộc tập trận chung Mỹ - Hàn, còn một lý do khác mà nhiều quốc gia cảm thấy bất an, là những đồn đoán về phiên bản Stuxnet của riêng Bắc Triều Tiên. Nếu điều đó là đúng, thì “Không có bất kỳ bàn tay nào trong các sự kiện ngày hôm qua, Bill Gates có lẽ có lý do để nói “Tôi đã nói với bạn rồi”, trong khi những người gửi tiền vào các ngân hàng tại Hàn Quốc ngồi bất tỉnh trong sự biến mất các dữ liệu tài khoản tiết kiệm của họ”. Và một lần nữa, nguyên nhân có liên quan trực tiếp - Windows, lần này là Windows 7: “Có lẽ những gì đã xảy ra ngày hôm qua khi ai đó đã chuyển một bộ chuyển mạch switch vào một hệ điều hành như Windows 7, một sản phẩm của Microsoft, và các bản sao bootleg làm tắt”.

Hôm thứ tư, các báo cáo về sự đánh sập các hệ thống máy tính, bao gồm cả các máy ATM, một số ngân hàng chính của Hàn Quốc đã truyền cảm hứng cho các câu chuyện về việc thâm nhập của chế độ Bắc Triều Tiên. Vài ngân hàng và các doanh nghiệp khác đã bị đánh sập vài giờ đồng hồ ở Hàn Quốc, gây ra sự gián đoạn nghiêm trọng đời sống dân sự và của các doanh nghiệp.

Các nguồn tin trên thế giới đồ rằng những vụ đánh sập đó là có bàn tay của Bắc Triều Tiên, nước đã công bố sự không hài lòng của mình về cuộc tập trận gần đây của Hàn Quốc với sự cộng tác của Mỹ.

Một số nhà bình luận, như một nhà bình luận từ Fox News, đồ rằng có lẽ Bắc Triều Tiên đã có kế hoạch ăn cắp các chương trình phá hủy trong các máy tính của Hàn Quốc, và đã làm bật dậy các chương trình cài cắm trước đó như một lời cảnh báo cho Hàn Quốc. Trên thực tế, sự đồ đoán là Bắc Triều Tiên đã làm tuyệt với phiên bản Stuxnet của riêng mình, một chương trình máy tính bí ẩn mà Mỹ và Israel được cho là đã bí mật cài vào các hệ thống máy tính của Iran. Nếu sự đồ đoán này về các khả năng của Bắc Triều Tiên chứng minh được là đúng, thì điều này có thể đưa ra một mối đe dọa nghiêm trọng về khủng bố không gian mạng cho Hàn Quốc, và có thể các phần khác của thế giới, kể cả Mỹ.

Một nguồn tin quan trọng của Nhật (NikkeiBP) có nhiều hơn giải thích trần tục cho sự đánh sập các ngân hàng của Hàn Quốc. Dường như là nhiều cơ quan của Hàn Quốc, bao gồm cả các ngân hàng được nhấn mạnh trong bản tin ngày hôm qua, sử dụng các chương trình máy tính bootleg để chạy các hoạt động của họ, thay vì các chương trình được ủy quyền (và đắt hơn nhiều). Có lẽ những gì đã xảy ra ngày hôm qua khi ai đó đã chuyển một bộ chuyển mạch switch vào một hệ điều hành như Windows 7, một sản phẩm của Microsoft, và các bản sao bootleg làm tắt. Điều này có thể là cái giá mà các cơ quan của Hàn Quốc đang trả cho việc cố thử tiết kiệm và quá thông minh nửa vời.

Nếu các câu chuyện của người Nhật chứng minh đúng là như vậy, thì sự đồ đoán sợ hãi có liên quan tới Stuxnet của Bắc Triều Tiên có thể được đặt cho phần còn lại. Hơn nữa, những nếu phiên bản của Nhật chứng minh là đúng, thì nhiều người khác sẽ có lý do để toát mồ hôi.

Nếu các chương trình bootleg khác cũng bị tổn thương đánh sập như được nêu với các chương trình của các ngân hàng Hàn Quốc, thì các cơ quan khác có thể hôn từ biết các hoạt động của họ với ý định chợt nảy ra về bất kỳ kẻ thù nào hoặc đối thủ cạnh tranh nào. Ví dụ, nếu các cơ quan của Iran đang cố tránh trả tiền cho Microsoft và các đại lý khác của Quỷ Satan, thì nó có thể không lấy một Stuxnet để vô hiệu hóa chúng. Một sự thiết lập lại đơn giản của một hệ điều hành có lẽ làm được công việc đó.

Không có bất kỳ bàn tay nào trong các sự kiện ngày hôm qua, Bill Gates có lẽ có lý do để nói “Tôi đã nói với bạn rồi”, trong khi những người gửi tiền vào các ngân hàng tại Hàn Quốc ngồi bất tỉnh trong sự biến mất các dữ liệu tài khoản tiết kiệm của họ.

On Wednesday, reports of the shutdown of the computer systems, including ATMs, of some major South Korean banks inspired stories of hacking by the North Korean regime. Several banks and other businesses shut down for several hours in South Korea, causing serious disruption of business and civilian life.

News sources around the world speculated that these shutdowns were the handiwork of North Korea, which has announced its displeasure at the recent military maneuvers practiced by South Korea in cooperation with the US.

Some commentators, such as one from Fox News, speculated that perhaps North Korea had planted stealth disruptive programs in South Korean computer systems, and were triggering these pre-planted programs as a warning to South Korea. In essence, the speculation is that North Korea has perfected its own version of Stuxnet, the mysterious computer program which the US and Israel are said to have secreted into the computer systems of Iran. If this speculation about the capabilities of North Korea prove to be true, this would represent an enormous threat of cyber-terror to South Korea, and perhaps other parts of the world, including the US.

An important Japanese news source (NikkeiBP) has a much more mundane explanation for the South Korean bank shutdown. It seems that many South Korean institutions, including the banks highlighted in yesterday's news, use bootleg computer programs to run their operations, instead of authorized (and much more expensive) programs. Perhaps what happened yesterday was that someone flipped a switch on an operating system like Windows7, a Microsoft product, and the bootleg copies shut down. This could be the price these South Korean institutions are paying for trying to be frugal and too clever by half.

If these Japanese stories prove to be the case, the scary speculation concerning a North Korean Stuxnet can be put to rest. But, also, if the Japanese version proves to be correct, many other people will have reason to sweat.

If other bootleg programs are as vulnerable to shutdown as the alleged South Korean bank programs, other institutions can kiss their operations goodby at the whim of any enemy or competitor. For example, if Iranian institutions are trying to avoid payments to Microsoft and other agents of the Great Satan, it would not take a Stuxnet to disable them. A simple reset of an operating system might do the job. 

Without having any hand whatsoever in yesterday's events, Bill Gates might have reason to say "I told you so," while bank depositors in South Korea sit stunned at the disappearance of their savings account data.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

Dạng giấy phép nào tôi nên chọn?

What kind of licence should I choose?

By Rowan Wilson, Published: 23 May 2011, Reviewed: 14 May 2012

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

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

Lời người dịch: Chọn giấy phép cho phần mềm tự do nguồn mở của bạn là một việc không dễ, vì có rất nhiều loại giấy phép và chúng có những đặc trưng khác nhau, dù có 2 dòng chính là copyleft và dễ dãi (permissive). Dù thế nào, thì thông thường suy nghĩ chọn giấy phép cũng là làm sao đề phần mềm được nhiều người sử dụng dễ dàng nhất, điều thường là trái ngược với phần mềm sở hữu độc quyền khi luôn cấm đoán bạn thực hiện một hành động nào đó, như sao chép, tùy biến, phân phối và/hoặc phân phối lại. “Tài liệu này đã trình bày một số khác biệt giữa các giấy phép PMTDNM khác nhau, để giúp bạn xem xét dạng giấy phép nào bạn có thể muốn áp dụng cho mã của riêng bạn. Các ví dụ được cung cấp để bổ sung thêm dạng những cân nhắc có thể đặc trưng trong qui trình lựa chọn của riêng bạn. Tuy nhiên, bạn nên lưu ý, rằng không có một giấy phép nào có thể cho mọi sự kết hợp các tính năng, và vì thế có lẽ là cần thiết phải thỏa hiệp về một hoặc vài chủng loại các tính năng để thực sự chọn một giấy phép đang tồn tại sẵn trước rồi. Để đạt được điều này, có thể là hữu dụng để xếp hạng các tính năng mà bạn mong muốn theo trật tự về tầm quant trọng”.

Có nhiều giấy phép phần mềm tự do nguồn mở (PMTDNM), và trong khi chúng tất cả có ý định một cách rộng rãi tạo thuận lợi cho những điều y hệt nhau, thì chúng cũng có một số khác biệt. Một số khác biệt chính có thể được nhóm cùng vào các chủng loại, và tài liệu này hành động như một sự giới thiệu các chủng loại đó. Đọc xong tài liệu này, bạn sẽ có khả năng hiểu các quyết định nào bạn nên tiến hành để chọn một giấy phép cho mã của bạn.

Giữ dòng chính thống

Sáng kiến Nguồn Mở (OSI) - một tổ chức phi lợi nhuận được hình thành để giáo dục về nguồn mở - duy trì một danh sách các giấy phép mà họ thấy đang 'được sử dụng phổ biến và rộng rãi hoặc với các cộng đồng mạnh'. Mục tiêu của danh sách đó là để nhấn mạnh các giấy phép mà có khả năng trả lời cho các nhu cầu của nhiều người cấp phép mới đối với nguồn mở. Danh sách đó cũng giúp thực hiện nhiệm vụ lựa chọn giấy phép nguồn mở trở nên có khả năng quản lý được; danh sách đầy đủ của hơn 60 giấy phép có thể là làm thoái chí, và có nhiều giấy phép theo hầu hết cách cách thức tương tự về chức năng với một hoặc nhiều giấy phép được liệt kê 'được sử dụng phổ biến và rộng rãi'.

Việc sử dụng một giấy phép mà nhiều người khác sử dụng có một số ưu điểm. Nếu các điều khoản của giấy phép đó bị thách thức, sẽ có một lượng lớn những người cấp phép với một sự quan tâm trong việc đầu cấp vốn cho một câu trả lời đối với thách thức đó. Việc sử dụng một trong những giấy phép 'được sử dụng phổ biến và rộng rãi' cũng làm cho có khả năng hơn rằng các giấy phép của bạn sẽ là quen thuộc rồi với các điều khoản mà bạn đang chào. Dù như nhau, thì các nhà cấp phép không nên cảm thấy 'bị khóa trói' vào chỉ việc sử dụng một giấy phép 'được sử dụng phổ biến và rộng rãi'. Một số tính năng chúng tôi thảo luận bên dưới chỉ hiện diện trong kho rộng lớn hơn của tất cả các giấy phép được OSI phê chuẩn.

Dễ dãi và copyleft

Tất cả các giấy phép tự do nguồn mở cho phép những người khác làm những phiên bản được sửa đổi đối với mã của bạn, và làm các phiên bản được sửa đổi đó sẵn sàng cho những người khác. Giấy phép mà bạn chọn có thể làm cho các điều kiện về cách mà điều này sẽ xảy ra - đặc biệt những giấy phép có thể được sử dụng trong các phiên bản được sửa đổi. Những điều kiện đó có thể giúp giữ cho mã của bạn tự do, nhưng chúng cũng có thể đặt một số người không sử dụng được mã của bạn. Những điều kiện như vậy đôi khi được gọi là các điều kiện 'copyleft', một cách chơi chữ với từ bản quyền 'copyright'.

Các giấy phép nguồn mở không tìm cách kiểm soát cách mà mã được sửa dổi được cấp phép thường được tham chiếu tới như là các giấy phép 'dễ dãi'. Trong khi mã gốc ban đầu được bao trùm bằng một giấy phép dễ dãi nằm dưới giấy phép dễ dãi đó, thì bất kỳ sửa đổi nào đối với nó có thể được phân phối theo bất kỳ giấy phép nào mà người sửa đổi chọn, nguồn mở hay là không. Điều này có nghĩa là mã được cấp phép dễ dãi có thể tạo thành nền tảng của các sản phẩm nguồn đóng. Một số viện lý rằng điều này làm cho các giấy phép dễ dãi 'tự do' hơn so với các giấy phép copyleft, theo đó mọi người mà sửa đổi mã là tự do hơn để chọn những gì họ làm với nó. Những người khác viện lý rằng thiếu một yêu cầu rằng những sửa đổi sẽ là nguồn mở ngụ ý rằng các giấy phép dễ dãi là ít 'tự do' hơn. Khi những thảo luận về các lý tưởng tự do - và đặc biệt ý tưởng bắt buộc phải là tự do - về cơ bản là triết lý mà chúng nằm ngoài phạm vi của tài liệu này. Tuy nhiên, đáng lưu ý rằng có các quan điểm khác nhau trong thế giới tự do nguồn mở về cái gì là 'tự do' theo nghĩa của sự tự do thực sự ngụ ý.

Ví dụ: Như một phần của nghiên cứu của bà, Anne tạo ra một tiêu chuẩn cho việc ghi một dạng đặc biệt đối tượng dữ liệu phức tạp. Bà cũng viết mã để tạo và phân tích các tệp gắn với tiêu chuẩn đó. Anne hiểu sâu sắc rằng tiêu chuẩn đã trở nên được sử dụng một cách rộng rãi, khi những tiêu chuẩn của thiểu số là ít hữu dụng hơn nhiều. Vì thế bà quyết định rằng bà sẽ phát hành mã theo một giấy phép dễ dãi. Anne tin tưởng rằng bằng việc cho phép những người sáng tạo của cả các dự án nguồn đóng và nguồn mở sử dụng cùng y hệt mã để tạo ra và đọc các đối tượng dữ liệu, thì sự hiểu biết và tính hiệu quả của tiêu chuẩn đều sẽ được giúp cùng.

Copyleft mạnh và yếu

Bạn có nên chọn đưa vào các điều kiện cấp phép copyleft để sử dụng lại mã của bạn hay không, có một sự lựa chọn tiếp để được thực hiện. Các giấy phép copyleft được chia rộng rãi thành 2 loại 'sức mạnh': mạnh và yếu. Các điều kiện của copyleft mạnh chỉ thị rằng khi một mẩu phần mềm có chứa một số mã của bạn, thì phần mềm như một tổng thể phải được phân phối theo giấy phép của bạn, nếu nó được phân phối hoàn toàn. Hiệu ứng của điều này sẽ là việc mã nguồn đối với tất cả các bổ sung được làm tới mã đó cũng sẽ là sẵn sàng.

Copyleft yếu, mặt khác, ngụ ý rằng khi phần mềm có chứa một số mã của bạn, thì một số phần của phần mềm đó phải được phân phối theo giấy phép của bạn, nếu phần mềm đó được phân phối hoàn toàn. Các phần khác có thể được phân phối theo các giấy phép khác, thậm chí dù chúng tạo thành một phần của tác phẩm mà là - như một tổng thể - một phiên bản được sửa đổi của mã của bạn. Một hiệu ứng của điều này sẽ là việc mã nguồn đối với một số bổ sung được làm từ những người khác cho phần mềm của bạn có thể sẽ không sẵn sàng như nguồn mở. Hiệu ứng khác có thể là mọi người có thể thấy nó dễ dàng hơn để 'thương mại hóa' mã của bạn bằng việc bổ sung thêm các thành phần đóng và bán các giấy phép cho các phần đóng đó.

Để chọn một giấy phép copyleft yêu đặc thù, bạn cũng phải quyết định chính xác các phần nào của mã của bạn sẽ giữ lại giấy phép của bạn và các dạng bổ sung nào có thể mang một giấy phép của việc chọn phần chỉnh sửa.

Sự phân chia này có thể xảy ra cùng một lúc ở 3 mức độ:

• Mức module mà các giấy phép copyleft yếu chỉ thị rằng phần phụ ('module') của từng chức năng của mã trong phần mềm được cân nhắc một cách tách bạch. Ở những nơi mà một module có vài mã của bạn, nó phải mang giấy phép của bạn. Ở những nơi nó không mã của bạn, thì người chủ của mã đó sẽ chọn giấy phép của riêng họ cho module đó.
• Mức tệp mà các giấy hép copyleft yếu chỉ thị rằng từng bộ của mã và dữ liệu mà là khác biệt theo hệ thống tệp của máy tính được cân nhắc một cách tách biệt. Ở những nơi một tệp có chứa một số mã của bạn, nó phải mang giấy phép của bạn. Ở những nơi nó không có, thì chủ của mã đó sẽ chọn giấy phép của riêng họ.
• Mức giao diện thử viện mà các giấy phép copyleft yếu thường được sử dụng ở những nơi mà mã của bạn là một thư viện phần mềm (một bộ sưu tầm chức năng phần mềm có khả năng được các chương trình khác sử dụng thông qua một giao diện được đồng ý). Những sửa đổi của thư viện của bạn phải mang giấy phép của bạn, nếu chúng được phân phối. Các chương trình sử dụng thư viện của bạn, và có thể được phân phối cùng với nó, không cần sử dụng giấy phép của bạn.

Ví dụ: Barry viết một mẩu mã C xem xét các website qua một kết nối mạng và tạo ra các sơ đồ tệp hình ảnh của các liên kết giữa các trang của chúng. Barry muốn phát hành mã của anh theo một giấy phép copyleft vì anh muốn bắt buộc truy cập tới mã nguồn của tất cả những sửa đổi chương trình của anh mà được phát hành. Tuy nhiên, Barry cũng muốn một sự khác biệt lớn của các dự án có khả năng sử dụng chương trình của anh - một phần vì anh tin tưởng điều này sẽ khuyến khích những sửa đổi hữu ích và những tối ưu hóa tác phẩm của anh mà anh muốn thấy. Barry quyết định đóng gói chương trình của anh như một thư viện và sử dụng giấy phép copyleft yếu GNU LGPLv2.1 mức giao diện thư viện lên nó, vì dường như với anh thì điều này thể hiện một sự cân bằng tốt giữa việc khuyến khích sử dụng lại của cả các dự án nguồn đóng và nguồn mở, trong khi vẫn chỉ thị phát hành được mã nguồn của những sửa đổi tới các phần mà anh có quan tâm - mã của riêng anh và chức năng mà nó cụ thể hóa.

Quyền tài phán

'Quyền tài phán' tham chiếu tới một vị trí hoặc lãnh thổ đặc thù và hệ thống luật của nó. Ở những nơi một giấy phép chỉ định một quyền tài phán, thì người cấp phép và (những) người được cấp phép đồng ý rằng các điều khoản trong giấy phép sẽ được hiểu theo tham chiếu tới luật của quyền tài phán đó và rằng hành động pháp lý đưa ra - ví dụ - từ sự vi phạm các điều khoản giấy phép sẽ diễn ra trong quyền tài phán đó.

Trong khi quyền tài phán là một vấn đề quan trọng, thì có thể đáng lưu ý rằng theo truyền thống thì những người chủ của PMTDNM không có xu hướng tìm kiếm những thiệt hại về tiền từ những người vi phạm các điều khoản cấp phép của họ, mà thay vào đó tìm kiếm để ép người vi phạm hoặc tuân thủ các điều khoản hoặc chấm dứt sử dụng mã của họ theo yêu cầu. Đối với các mục đích đó thường không cần thiết để dùng tới việc thực sự mang một vi phạm ra tòa, đặc biệt nếu họ có một hồ sơ công khai và uy tín để bảo vệ. Đơn giản thường yêu cầu sự tuân thủ có thể là có hiệu lực, và nếu không được, thì việc đưa ra công khai sự vi phạm có thể giúp đạt được sự tuân thủ. Không phải tất cả các giấy phép PMTDNM chỉ định một quyền tài phán. Trên thực tế hầu hết là im lặn về chủ đề này. Trong các trường hợp đó thì bất kỳ quyền tài phán nào cũng có thể được lựa chọn khi và nếu cần thiết, dù hoàn toàn có khả năng là người mà bạn đang cố mang ra tòa sẽ hoặc là phớt lờ bạn hoặc tranh cãi về sự lựa chọn vị trí của bạn nếu nó không phù hợp với họ. Cuối cùng một số giấy phép PMTDNM nói rằng quyền tài phán hoặc tùy vào người cấp phép hoặc tự động theo của người cấp phép (ở những nơi mà họ sinh sống hoặc về nguyên tắc đang làm việc).

Ví dụ: Đại học Crabapple hiểu sâu sắc để viết một chính sách về phát hành nguồn mở, như một sự cúng vốn cực kỳ lớn chỉ định điều này như một điều kiện tiên quyết. Các luật sư trong Crabapple quyết định rằng một mẩu chính của chính sách này phải là việc xức dầu của một giấy phép đặc biệt như lựa chọn được các cơ quan ưu tiên khi việc cấp phép cho phần mềm như nguồn mở. Trong cuộc gặp đầu tiên để thảo luận giấy phép nào sẽ chọn, được chỉ ra rằng chính sách đảm bảo của cơ quan không bao trùm hành động pháp lý ở nước ngoài. vì thế nó đã quyết định rằng một tính năng cơ bản của giấy phép được xức dầu phải là giấy phép nó ép tuân thủ một quyền tài phán địa phương cho bất kỳ hành động pháp lý nào gây ra từ sự phân phối phần mềm mà nó bao trùm.

Các bằng sáng chế

Liệu bạn hoặc cơ quan bạn có sở hữu bất kỳ bằng sáng chế nào không? Nếu bạn có, và bạn phát hành một số mã thể hiện chúng theo một giấy phép PMTDNM, thì bạn rất có khả năng sẽ trao các quyền sử dụng bằng sáng chế phù hợp đó (trong kết nối với mã đó) cho bất kỳ ai chọn sử dụng nó - thậm chí nếu giấy phép đó không nói rõ ràng như thế. Trong nhiều quyền tài phán, ví dụ tại Anh và Mỹ, việc cấp phép cho ai đó để tiến hành một hành động nhất định (như việc sao chép hoặc tùy biến mã của bạn) cũng có thể ngụ ý cấp phép cho họ để lấy tất cả các bước cần thiết khác để thực hiện hành động đó. Các bước ngụ ý được cấp phép đó có thể hầu hết nhất định bao gồm sử dụng bằng sáng chế phần mềm được thể hiện của bạn. Nên được lưu ý rằng mọi người mà tùy biên mã của bạn không thể mở rộng chức năng của nó để nắm lấy các bằng sáng chế phần mềm khác của bạn - bạn trao các quyền chỉ cho các bằng sáng chế được thể hiện trong mã mà bạn đã phát hành, chức không phải bất kỳ dạng mã tới sau nào có thể lấy. Một số giấy phép PMTDNM không nói gì về chủ đề trao bằng sáng chế - dù như được lưu ý điều này có thể không ngụ ý rằng họ không trao các quyền của bằng sáng chế. Một số giấy phép PMTDNM trao rõ ràng các quyền của bằng sáng chế cần thiết để sử dụng, tùy biến và phân phối phần mềm đó.

Giấy phép PMTDNM của bạn cũng có thể bao gồm những gì đôi khi được gọi là một mệnh đề 'trả đũa về bằng sáng chế'. Những phần đó của một giấy phép về cơ bản nói rằng bất kỳ ai mà mang hành động pháp lý nói rằng phần mềm được cấp phép bao gồm một trong những bằng sáng chế phần mềm của họ sẽ mất giấy phép bạn đã được trao để sao chép, sử dụng, tùy biên và phân phối mã. Một mệnh đề như vậy có ý định can ngăn mọi người khỏi việc mang dạng hành động pháp lý này vào.

Ví dụ: Giáo sư Dopaska đã tạo ra một quy trình do phần mềm thể hiện cho việc dự đoán bạo động dân sự mà đại học của ông tin tưởng có thể được trao bằng sáng chế. Giáo sư hiểu sâu sắc sẽ phát hành sự thể hiện bằng phần mềm qui trình này theo giấy phép dễ dãi Apache License, v2, khi mà ông mong muốn thấy qui trình đó được sử dụng khắp mọi nơi để cải thiện uy tín hàn lâm của ông. Nhân viên chuyển giao tri thức tại cơ quan của Giáo sư Dopaska không hiểu về ý tưởng này, khi họ muốn có được bằng sáng chế và xây dựng một công ty được xoay ra từ nó, và tin tưởng rằng phát hành nguồn mở sẽ làm xói mòn doanh thu cấp phép của sự đầu cơ này.

Sự ghi công được cải thiện

Tất cả các giấy phép PMTDNM chỉ định rằng bất kỳ ai mà phân phối hoặc tùy biến phần mềm phải ghi công các tác giả gốc ban đầu của phần mềm ở đâu đó trong phát hành của họ. Một số giấy phép PMTDNM đi xa hơn thế, và chỉ định rằng sự ghi công phải được thực hiện ở dạng đặc biệt và xuất hiện trong các sự việc đặc biệt, ví dụ trong giao diện người sử dụng của phần mềm mỗi lẫn nó được chạy. Dạng qui định này đôi khi được gọi là 'sự ghi công được cải thiện' hoặc 'badgeware'.

Ví dụ: Edward tạo ra một công cụ cho việc ảo hóa tần suất xuất hiện các từ trong tài liệu theo một cách thức lôi cuốn. Edward phỏng đoán rằng công cụ đó có thể sẽ được sử dụng rộng rãi, nhưng không đủ cơ bản cho hầu hết nghiệp vụ cốt lõi của người sử dụng để hỗ trợ một mô hình cấp phép có trả tiền. Sự thật là, những gì Edward thực sự muốn đạt được là sự công khai cho tư vấn quảng cáo mà ông quản lý và vì nó mã đã được viết. Edward quyết định phát hành công cụ của ông theo giấy phép Common Public Attribution License v1 vì giấy phép này bắt buộc hiển thị một URL, một hình đồ họa và một mệnh đề chi công mỗi lần phần mềm được chạy. Edward đưa ra URL, logo và dòng quảng cáo trên site từ vấn của ông cùng với phần mềm sao cho những người sử dụng sẽ giúp quảng cáo doanh nghiệp của ông khi họ sử dụng và sử dụng lại mã của ông.

Khe hở về tính riêng tư

Nếu ai đó sử dụng mã của bạn để tạo một dịch vụ trực tuyến hoặc một giải pháp nội bộ, có thể tùy biến và cải thiện nó, thì hầu hết các giấy phép PMTDNM không chỉ định rằng nguồn đối với phiên bản được tùy biến hoặc cải thiện phải được phát hành. Hầu hết các giấy phép PMTDNM làm nó thành một điều kiện phân phối rằng mã nguồn sẽ được phân phối lại. Nói chung việc không làm cho các dịch vụ sẵn sàng qua một mạng, cả việc không sử dụng mã, việc không triển khai mã trong một cơ quan duy nhất được xác định như là sự phân phối bên trong các giấy phép đó.

Mọt số người trong cộng đồng PMTDNM cảm thấy rằng hiện tượng này, đôi khi được gọi là 'khe hở của nhà cung cấp dịch vụ ứng dụng – ASP' hoặc 'khe hở về tính riêng tư' cần phải được chỉnh sửa. Lý lẽ của họ là tính công bằng chỉ thị rằng tất cả những người hưởng lợi từ mã phải đóng góp tác phẩm của họ ngược về cho thế giới, thậm chí nếu họ không, nói nghiêm túc, phân phối mã. Để giải quyết vấn đề này, một số giấy phép PMTDNM thực hiện phát hành mã nguồn với điều kiện không chỉ cho phát tán mà còn cho triển khai nội bộ và/hoặc tiến hành các dịch vụ có sẵn qua mạng bằng việc sử dụng phần mềm. Các dạng điều kiện đó vì thế đặc biệt phù hợp cho mã mà có khả năng sẽ được sử dụng trong nội bộ hoặc như một cơ sở cho một dịch vụ mạng.

Ví dụ: Fareeda muốn xây dựng một doanh nghiệ cung cấp một các dễ dàng cho những người sử dụng để xây dựng các video âm nhạc trình bày các slide phức tạp từ các ảnh của họ trên các site mạng xã hội. Bà thấy một mẩu phần mềm nguồn mở theo giấy phép GNU Affero GPL v3, nó đưa ra một cách thuận tiện để điều hành yêu cầu mà site của bà phải giao tiếp với nhiều site bên ngoài khác. Nhìn vào giấy phép đó, Fareeda phát hiện rằng các điều khoản của nó bắt buộc rằng - nếu bà sửa đổi mã mà nó bao trùm và sử dụng nó như là cơ sở của một dịch vụ được cung cấp qua một mạng như bà có ý định - thì bà cũng phải làm cho mã nguồn đối với những sửa đổi của bà sẵn sàng cho những người sử dụng dịch vụ. Fareeda bây giờ phải quyết định liệu mô hình kinh doanh của bà sẽ có bị ảnh hưởng, được trợ giúp hay bị xói mòn vì trách nhiệm pháp lý tiềm tàng này hay không.

Không quảng cáo

Một số giấy phép PMTDNM rõ ràng cấm sử dụng các tên tác giả để quảng cáo một sản phẩm hoặc dịch vụ dựa vào mã của các tác giả đó.

Ví dụ: Như một phần của một dự án nhà nước cấp vốn, Đại học Gerhentz tạo mã tự động tùy biến các giao diện người sử dụng theo các kích cỡ hiển thị tùy ý. Đại học hiểu rõ rằng việc cấp vốn nhà nước dẫn tới lợi ích tối đã của nhà nước trong cả các phần mềm nguồn đóng và mở, và vì thế muốn phát hành mã theo một giấy phép nguồn mở dễ dãi. Tuy nhiên Gerhentz không muốn được xem là đang chứng thực cho các sản phẩm có chứa mã của họ, vì họ cảm thấy rằng điều này có thể tiềm tàng làm hại cho uy tín của đại học. Vì thế được quyết định rằng giấy phép BSD License sẽ đưa ra cả khả năng sử dụng lại rộng rãi và khóa trong sử dụng quảng cáo mà họ tìm kiếm.

Kết luận

Tài liệu này đã trình bày một số khác biệt giữa các giấy phép PMTDNM khác nhau, để giúp bạn xem xét dạng giấy phép nào bạn có thể muốn áp dụng cho mã của riêng bạn. Các ví dụ được cung cấp để bổ sung thêm dạng những cân nhắc có thể đặc trưng trong qui trình lựa chọn của riêng bạn. Tuy nhiên, bạn nên lưu ý, rằng không có một giấy phép nào có thể cho mọi sự kết hợp các tính năng, và vì thế có lẽ là cần thiết phải thỏa hiệp về một hoặc vài chủng loại các tính năng để thực sự chọn một giấy phép đang tồn tại sẵn trước rồi. Để đạt được điều này, có thể là hữu dụng để xếp hạng các tính năng mà bạn mong muốn theo trật tự về tầm quant trọng. OSS Watch có thể giúp bạn chọn một giấy phép phù hợp nhất cho các đặc tính mong muốn nhất của bạn - hãy liên hệ.

There are many free and open source software licences, and while they all broadly attempt to facilitate the same things, they also have some differences. Some of the major differences can be grouped together into categories, and this document acts as an introduction to these categories. Having read this document, you should be able to understand which decisions you should take in order to select a licence for your code.

Staying mainstream

The Open Source Initiative - a non-profit organisation formed to educate about open source - maintains a list of licences that they see as being ‘popular and widely used or with strong communities’. The purpose of the list is to highlight those licences which are likely to answer the needs of many licensors new to open source. The list also helps to make the task of open source licence selection seem manageable; the full list of more than 60 licences can be daunting, and contains many licences which are in most ways similar in function to one or more of the ‘popular and widely used’ listed licences.

Using a licence that many others use has some advantages. If the terms of the licence are challenged, there will be a larger pool of licensors with an interest in funding a response to the challenge. Using one of the ‘popular and widely used’ licences also makes it more likely that your licensees will already be familiar with the terms you are offering. Equally though, licensors should not feel ‘locked in’ to only using a ‘popular and widely used’ licence. Some of the features we discuss below are only present in the wider pool of all OSI-approved licences.

Permissive and copyleft

All free and open source licences allow others to make modified versions of your code, and to make these modified versions available to others. The licence you choose can make conditions about how this happens - specifically what licences can be used on these modified versions. These conditions can help keep your code free, but they can also put some people off reusing your code. Such conditions are sometimes called ‘copyleft’ conditions, in a play on the word ‘copyright’.

Open source licences that do not seek to control how modified code is licensed are often referred to as ‘permissive’ licences. While the original code covered by a permissive licence stays under that permissive licence, any modifications to it can be released under any licence that the modifier chooses, open source or not. This means that permissively licensed code can form the basis of closed source products. Some argue that this makes permissive licences more ‘free’ than copyleft licences, in that people who modify the code are freer to choose what they do with it. Others argue that the lack of a requirement that modifications be open source means that permissive licences are less ‘free’. As discussions of ideas of freedom - and particularly the idea of compulsion to be free - are essentially philosophical they fall outside the scope of this document. It is worth noting, however, that there are differing views within the free and open source world about what ‘free’ in the sense of freedom really means.

Example: As part of her astrophysics research Anne creates a standard for recording a specific kind of complex data object. She also writes code to create and parse files that adhere to the standard. Anne is keen that the standard becomes widely used, as minority standards are far less useful. Therefore she decides that she will release the code under a permissive licence. Anne believes that by allowing creators of both closed and open source projects to use the same code to create and read the data objects, uptake and efficacy of the standard will both be helped along.

Strong and weak copyleft

Should you choose to include copyleft licensing conditions on reuse of your code, there is a further choice to be made. Copyleft licences are broadly divided into two ‘strengths’: strong and weak. Strong copyleft conditions dictate that when a piece of software contains some of your code, the software as a whole must be distributed under your licence, if it is distributed at all. The effect of this will be that the source code to all additions made to the code will be available.

Weak copyleft, on the other hand, means that when software contains some of your code, some parts of the software must be distributed under your licence, if the software is distributed at all. Other parts may be distributed under other licences, even though they form part of a work which is - as a whole - a modified version of your code. One effect of this will be that the source code to some additions made by others to your software may not be available as open source. Another effect may be that people may find it easier to ‘productise’ your code by adding closed components and selling licences to these closed parts.

To choose a specific weak copyleft licence, you must also decide precisely which parts of your code will retain your licence and what kinds of additions can bear a licence of the modifier’s choosing. This division can happen at one of three levels:

• Module level weak copyleft licences dictate that each functional sub-section (‘module’) of code within the software is considered separately. Where a module contains some of your code, it must bear your licence. Where it does not, the owner of that code gets to choose their own licence for that module.
• File level weak copyleft licences dictate that each collection of code and data that is distinct according to the computer’s file system is considered separately. Where a file contains some of your code, it must bear your licence. Where it does not, the owner of that code gets to choose their own licence.
• Library interface level weak copyleft licences are generally used where your code is a software library (a collection of software functionality which is usable by other programs via an agreed interface). Modifications of your library must bear your licence, if they are distributed. Programs that use your library, and are perhaps distributed alongside it, need not use your licence.

Example: Barry writes a piece of C code that examines websites over a network connection and generates image file diagrams of the links between their pages. Barry wants to release his code under a copyleft licence because he wants to mandate access to the source code of all modifications of his program that are released. However, Barry also wants a wide variety of projects to be able to use his program - partly because he believes this will encourage the useful modifications and optimisations of his work that he wants to see. Barry decides to package his program as a library and use the library interface level weak copyleft licence the GNU LGPLv2.1 on it, as it seems to him that this represents a good balance between encouraging reuse by both closed and open source projects while mandating the release of source of modifications to the parts he is interested in - his own code and the functionality it embodies.

Jurisdiction

A ‘jurisdiction’ refers to a specific location or territory and its system of law. Where a licence specifies a jurisdiction, the licensor and the licensee(s) agree that the terms in the licence are to be understood in reference to that jurisdiction’s law and that legal action resulting - for example - from breach of the licence’s terms will take place in that jurisdiction.

While jurisdiction is an important issue, it may be worth noting that traditionally free and open source software owners do not tend to seek monetary damages from those who infringe their licensing terms, but seek instead to compel the infringer to either abide by the terms or terminate their use of the code in question. For these purposes it is often unnecessary to resort to actually taking an infringer to court, particularly if they have a public profile and reputation to protect. Often simply requesting compliance can be effective, and if that fails, publicising the infringement can help achieve compliance. Not all free and open source software licences specify a jurisdiction. In fact most are silent on the subject. In these cases any jurisdiction can be selected when and if necessary, although it is quite possible that the person you are trying to take to court will either ignore you or dispute your choice of location if it does not suit them. Finally some free and open source software licences state that the jurisdiction is either up to the licensor or automatically that of the licensor (where they reside or principally do business).

Example: Crabapple University is keen to write a policy on open source release, as an extremely large endowment specifies this as a pre-condition. Lawyers within Crabapple decide that a key piece of this policy must be the anointing of a specific licence as the institution’s preferred option when licensing out software as open source. At the first meeting to discuss which licence to choose, it is pointed out that the institutional insurance policy does not cover legal action abroad. It is therefore decided that an essential feature of the anointed licence must be that it enforces a local jurisdiction for any legal action resulting from the release of software it covers.

Patents

Do you or your institution own any software patents? If you do, and you release some code that embodies them under a free or open source software licence, then you are very likely to be granting rights to use the relevant patent (in connection with that code) to anyone who chooses to use it - even if the licence does not explicitly say so. In many jurisdictions, for example the UK and the US, licensing someone to take a particular action (like copying or adapting your code) can also impliedly license them to take all other steps necessary to take that action. These impliedly licensed steps would almost certainly include use of your embodied software patent. It should be noted that people who adapt your code cannot expand its functionality to capture other software patents of yours - you grant rights only to the patents embodied in the code you released, not any subsequent form the code may take. Some free and open source software licences say nothing on the subject of patent grants - although as noted this may not mean that they grant no patent rights. Some free and open source software licences explicitly grant patent rights necessary to use, adapt and distribute the software.

Your free or open source software licence can also include what is sometimes called a ‘patent retaliation’ clause. These sections of a licence essentially say that anyone who brings legal action alleging that the licensed software embodies one of their software patents will lose the licence you have granted to copy, use, adapt and distribute the code. Such a clause is intended to dissuade people from bringing this kind of legal action.

Example: Professor Dopaska has created a software-embodied process for predicting civil unrest that his university believes is patentable. The professor is keen to release the software embodiment of this process under the permissive Apache License, v2, as he wishes to see the process used ubiquitously to enhance his academic reputation. Knowledge transfer staff at Professor Dopaska’s institution are not keen on this idea, as they wish to obtain the patent and build a spin-out company around it, and believe that the open source release will undermine the licensing income of this venture.

Enhanced attribution

All free or open source software licences specify that anyone who distributes or adapts the software must give credit to the original authors of the software somewhere in their distribution. Some free or open source software licences go further than this, and specify that the credit must take a particular form and appear in specific instances, for example on the software’s user interface every time it is run. This kind of stipulation is sometimes called ‘enhanced attribution’ or ‘badgeware’.

Example: Edward creates a tool for visualising the frequency of occurences of words in documents in an attractive way. Edward surmises that the tool will probably be used widely, but is not essential enough to most users’ core business to support a paid licensing model. In truth, what Edward really wants to achieve is publicity for the promotional consultancy he runs and for which the code was written. Edward decides to release his tool under the Common Public Attribution License v1 as this mandates the display of a URL, a graphic and an attribution phrase every time the software is run. Edward provides his consultancy site’s URL, logo and strapline along with the software so that users will help promote his business when they use and reuse his code.

The privacy loophole

If someone uses your code to create an online service or an in-house solution, perhaps adapting and improving it, most free and open source software licences do not specify that the source to the adapted or improved version must be released. Most free and open source software licences make it a condition of distribution that source code be released. In general neither making services available over a network, nor using the code, nor deploying the code within a single institution is defined as distribution within these licences.

Some within the free and open source software community feel that this phenomenon, sometimes called the ‘ASP (application service provider) loophole’ or ‘privacy loophole’ needs to be fixed. Their argument is that fairness dictates that all those who benefit from the code must contribute their work back to the world, even if they are not, strictly speaking, distributing the code.To address this issue, some free or open source software licences make release of the source code a condition not only for distribution but also for internal deployment and/or making services available over a network using the software. These kinds of conditions are therefore particularly suited to code which is likely to be used in-house or as a basis for a networked service.

Example: Fareeda wants to build a business providing an easy way for users to build complex slide show music videos from their photographs on social networking sites. She finds a piece of open source software under the GNU Affero GPL v3 which provides a convenient way to handle the requirement that her site must interface with many external sites. Looking into the licence, Fareeda discovers that its terms mandate that - if she modifies the code it covers and uses it as the basis of a service provided over a network as she intends - she must also make the source code to her modifications available to service users. Fareeda must now decide if her business model will be unaffected, aided or undermined by this potential responsibility.

No promotion

Some free and open source software licences explicitly forbid the use of the authors’ names to promote a product or service based upon the authors’ code.

Example: As part of a publicly-funded project Gerhentz University creates code which automatically adapts user interfaces to arbitrary display sizes. The institution is keen that the public funding leads to the maximum public benefit both in open and closed source software, and so wishes to release the code under a permissive open source licence. However Gerhentz does not wish to be seen to be endorsing products that contain their code, as they feel that this may potentially damage the institution’s reputation. Therefore it is decided that the BSD License will provide both the wide reusability and block on promotional use that they seek.

Conclusion

This document has presented some of the key differences between the various free and open source licences, in order to help you consider what kind of licence you might want to apply to your own code. Examples are provided to flesh out the kind of considerations that might feature in your own selection process. You should note, however, that there is not a licence for every possible combination of features, and so it may well be necessary to compromise on one or more category of features in order to actually choose a pre-existent licence. To achieve this it can be helpful to rate the features you desire in order of importance. OSS Watch can help you choose a licence which best fits your most desired characteristics - just get in touch.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com

April xuất bản bản dịch tiếng Anh chính sách phần mềm tự do của Pháp

April publishes English translation of France's free software policy

Submitted by Gijs Hillenius on March 20, 2013

Theo: https://joinup.ec.europa.eu/news/april-publishes-english-translation-frances-free-software-policy

Bài được đưa lên Internet ngày: 20/03/2013

Chính sách của chính phủ Pháp về phần mềm tự do bây giờ có sẵn bằng tiếng Anh. Bản dịch đã được xuất bản sớm nay từ April, một tổ chức bảo vệ của Pháp. Đây không phải là một bản dịch chính thứ. Tuy nhiên, các chuyên gia đã tham gia trong việc tạo ra văn bản gốc tiếng Pháp đã không thấy sự hiểu lầm nào, nhóm bảo vệ này đã bình luận. Nhóm hy vọng các cơ quan hành chính nhà nước khác sẽ sử dụng chỉ dẫn đó vì lợi ích của họ.

Lời người dịch: Bạn có thể tải về chính sách phần mềm tự do của Pháp, được phê chuẩn vào tháng 09/2012 tại: http://www.april.org/files/20130319-ayrault-memorandum-english-translation.pdf

The French government policy on free software is now available in English. The translation was published earlier today by April, a French advocacy organisation. It is not an official translation. However, experts involved in the creation of the original French text have not found misinterpretations, the advocacy group commented. The group hopes other public administrations will use the guideline to their benefit.

Chỉ dẫn đã được Thủ tướng Pháp Jean - Marc Ayrault ký vào tháng 9 năm ngoái, với tên hiệu Pháp là 'Thông tư Ayrault'. Tài liệu đã được một nhóm làm việc liên bộ viết, được Ban Lãnh đạo Định hướng Liên bộ về các hệ thống thông tin và truyền thông - DISIC ("Direction interministérielle des systèmes d'information et de communication", Interdepartmental Direction Directorate of information systems and communication) tổ chức.

April ngay lập tức đã bắt đầu làm cho tài liệu sẵn sàng một cách rộng rãi. Nó trước hết cung cấp một bản sao văn bản, vì tài liệu chính sách là sẵn sàng trên website của chính phủ chỉ như một PDF có ảnh, không phải là văn bản sửa đổi được. Nhóm này sau đó đã chuyển từ văn bản sang Etherpad, cho phép những người dịch cộng tác trong văn bản tiếng Anh.

Hơn 20 người tình nguyện đã dịch hầu hết các văn bản trong ít hơn 1 tháng, nhưng một ít khái niệm được chứng minh là có khác. April, trong lời giới thiệu của họ về chỉ dẫn được dịch này: “Tài liệu tiếng Pháp sử dụng từ 'shuche' hoặc biểu thị 'souche libre' mà là hơi khó một chút để dịch sang tiếng Anh. Trong hầu hết các trường hợp, 'souche' hoặc 'souche libre' đơn giản tham chiếu tới phần mềm tự do”.

Một bản rà soát lại đã được thực hiện vào tháng trước, sau đó văn bản đã được trình bày cho DISIC.

Các lời khen ngợi

Thông tu Ayrault có nhiều sự rà soát lại tích cực từ những người đã tham gia trong PMTDNM. Lionel Allorge, chủ tịch của April, đã gọi chỉ dẫn này là tin tốt lành cho hành chính Pháp. “Chúng tôi rất vui vì được thể hiện trong thông tư này để làm việc cùng nhau với các cộng đồng phần mềm tự do và các công ty của họ”. Patrice Bertrand, chủ tịch của Ủy ban Phần mềm Tự do Pháp, đại diện cho các hãng phần mềm tự do, nói: “Những tuyên bố chính thức là hiếm khi rõ ràng và có cam kết như lần này”. Alexandre Zapolsky, CEO của nhà cung cấp dịch vụ CNTT nguồn mở Pháp Linagora, đã kết luận rằng chính phủ Pháp đã “chọn phần mềm tự do, hỗ trợ một nền công nghiệp của tương lai, sự tạo công ăn việc làm, sự tăng trưởng và tính cạnh tranh”.

The guideline was signed last September by France's Prime Minister Jean-Marc Ayrault, hence the French nickname 'Circulaire Ayrault'. The document has been written by an interdepartmental working group, organised by DISIC ("Direction interministérielle des systèmes d'information et de communication", Interdepartmental Direction Directorate of information systems and communication).

April immediately started making the document widely available. It first provided a transcription of the text, since the policy document is available on the government's website only as a PDF containing images, not editable text. The group later transferred the text to Etherpad, allowing translators to collaborate on the English text.

Over twenty volunteers translated most of the text in less than a month, but a few terms proved tricky. April, in their introduction to the translated guideline: "The French document uses the word 'souche' or the expression 'souche libre' which is a bit difficult to translate into English. In most case, 'souche' or 'souche libre' simply refers to free software."

A final review took place the past month, after which the text was presented to DISIC.

Compliments
The Circulaire Ayrault got many positive reviews from those involved in free and open source software. Lionel Allorge, president of April, called the guideline good news for the French administration. "We are very pleased about the will expressed in this circular to work together with free software communities and its companies." Patrice Bertrand, chair of the French Free Software Council, representing free software firms, said: "Official pronouncements are rarely as clear and committed as this one." Alexandre Zapolsky, CEO of the French open source IT service provider Linagora, concluded that the French government has "chosen for free software, supporting an industry of the future, job creation, growth and competitiveness."

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com