Thứ Năm, 30 tháng 5, 2013

Hướng dẫn làm thế nào với phần mềm tự do nguồn mở của OSS Watch

Các bạn độc giả thân mến!
Kể từ ngay sau khi nghỉ Tết nguyên đán năm Quý Tỵ 2013 ra, từ ngày làm việc đầu tiên của năm mới, chính xác là vào ngày thứ hai, 18/02/2013 cho tới ngày hôm nay, blog đã đăng tải khoảng hơn 80 bài + tài liệu liên quan được dịch sang tiếng Việt trong tổng số khoảng 100 bài + tài liệu liên quan của OSS Watch, nhà tư vấn về phần mềm tự do nguồn mở cho giáo dục cao đẳng và đại học và cho Văn phòng Nội các của Chính phủ Anh.
Cho dù cho tới nay, có một số vấn đề đã thay đổi với nước Anh, ví dụ như việc Chính phủ Anh đã xuất bản chính sách bắt buộc sử dụng các tiêu chuẩn mở trong mua sắm CNTT của tất cả các cơ quan chính phủ Anh kể từ ngày 01/11/2012, thì những nội dung của khoảng 100 bài + các tài liệu liên quan này vẫn hầu như còn nguyên giá trị để tham khảo rất tốt cho các nhóm người có các mức độ quan tâm khác nhau về phần mềm tự do nguồn mở ở Việt Nam.
Tại Việt Nam hiện nay, nhận thức về sự cần thiết phải ứng dụng và phát triển phần mềm tự do nguồn mở đã khác đáng kể so với vài năm trước đây. Tuy nhiên, điều mà đại đa số mọi người quan tâm nhất hiện nay là làm như thế nào cho đúng với phần mềm tự do nguồn mở, không phải một cách nói chung chung, mà là cho từng nhóm người cụ thể, từng nhóm vấn đề cụ thể.
Trong tháng 06/2013, hướng tới kỷ niệm 6 năm ngày blog này ra đời, 09/06/2007 – 09/06/2013, blog sẽ đăng tải các bài viết tổng hợp cho từng nhóm người và nhóm vấn đề cụ thể. Đặc biệt, từng bài tổng hợp sẽ có các đường dẫn tới các tài liệu trong loạt bài của OSS Watch đã được dịch sang tiếng Việt, để giúp bạn có tiếp cận được nhanh nhất tới các nội dung liên quan đó. Các bài tổng hợp theo các nhóm người cụ thể, nhóm các vấn đề cụ thể gồm:
  1. Các trường hợp điển hình
  2. Quyền sở hữu trí tuệ, việc cấp phép và các bằng sáng chế
  3. Dành cho lập trình viên
  4. Chiến lược và chính sách
  5. Dành cho các nhà làm chính sách chiến lược về CNTT
  6. Xây dựng các cộng đồng
  7. Dành cho các nhà quản lý CNTT và các nhân viên kỹ thuật
  8. Phát triển phần mềm nguồn mở
  9. Người sử dụng đầu cuối trong giới hàn lâm nghiên cứu
  10. Nguồn mở cho những người mới bắt đầu hoàn toàn
Trong số các bài tổng hợp này, chỉ có các nội dung dành cho 'Quyền sở hữu trí tuệ, việc cấp phép và các bằng sáng chế' là còn chưa được hoàn chỉnh vì còn thiếu hầu như tất cả các nội dung của khoảng 10 giấy phép phần mềm tự do nguồn mở được đề cập tới trong loạt bài này chưa được dịch. Chúng sẽ được tiếp tục dịch sang tiếng Việt và đăng trên blog trong tháng 6 này để phục vụ các bạn độc giả.
Mời các bạn đón xem.
Hà Nội ngày 31/05/2013
Blogger: Lê Trung Nghĩa

Các câu hỏi thường gặp


Frequently Asked Questions
By OSS Watch, Published: 12 December 2006, Reviewed: 06 November 2012
Bài được đưa lên Internet ngày: 06/11/2012
Về OSS Watch
OSS Watch là ai?
OSS Watch là một dịch vụ tư vấn phần mềm nguồn mở (PMNM) cho khu vực giáo dục cao đẳng và đại học (HE/FE) của nước Anh. Chúng tôi được Ủy ban các Hệ thống Thông tin Chung - JISC (Joint Information System Comittee) cấp vốn, nghĩa là các dịch vụ của chúng tôi là tự do cho khu vực HE và FE.
Chúng tôi giúp các viện trường và các dự án liên quan tới giáo dục trong việc sử dụng và phát triển phần mềm tự do nguồn mở (PMTDNM). Chúng tôi cung cấp một loạt dịch vụ bao gồm:
OSS Watch đã được tạo ra khi nào và vì sao?
Trong năm 2003 khi OSS Watch đã bắt đầu, đã từng có rất ít sự hiểu biết trong khu vực hàn lâm của nước Anh về nguồn mở là gì và cách mà một người có thể tham gia vào với nó. OSS Watch đã được thành lập để xem xét tình hình và đưa ra các khuyến cáo có thể xúc tác cho khu vực này để hưởng lợi đầy đủ từ PMNM.
Qua các năm, trọng tâm đã chuyển từ việc tạo một sự hiểu biết mức cơ bản qua tới sự mua sắm chi tiết về pháp lý (bản dịch tiếng Việt) và cam kết tham gia (bản dịch tiếng Việt) tư vấn và hỗ trợ. Gần đây hơn chúng tôi đã nhấn mạnh tới cách mà PMNM có thể được duy trì bền vững (bản dịch tiếng Việt) và cách mà các mô hình kinh doanh (bản dịch tiếng Việt) có thể được xây dựng để đảm bảo rằng phần mềm được phát triển trong HE và FE là sẵn sàng có khả năng tùy biến được và được hỗ trợ với các chi phí tối thiểu càng lâu có thể càng tốt.
Làm thế nào tôi chắc chắn được rằng các tài liệu của OSS Watch là được cập nhật?
Tất cả các tài liệu được xuất bản trên website của OSS Watch tuân thủ với một qui trình rà soát lại nghiêm ngặt được các thành viên của đội OSS Watch tiến hành. Điều này bắt đầu 6 tháng sau khi tài liệu lần đầu tiên được xuất bản khi nó được rà soát lại về tính toàn vẹn. Sau 12 tháng và sau đó trên cơ sở cứ 6 tháng một nó sẽ được rà soát lại về tính toàn vẹn và tính phù hợp và được soạn sửa hoặc viết lại để được cập nhật hoặc lưu trữ. Bất chấp sự tỉ mỉ của chúng tôi, chúng tôi có thể có sai lầm và luôn chào đón các ý kiến phản hồi mà sẽ giúp cho chúng tôi giữ được cập nhật.
Các qui trình khởi đầu và rà soát lại tài liệu của chúng tôi được mô tả chi tiết hơn trong Cuộc sống của một tài liệu OSS Watch.
Làm thế nào tôi có thể có được sự cập nhật với các hoạt động của OSS Watch?
Chúng tôi thường xuyên viết blog (cũng sẵn sàng như là RSS feed) về mọi điều chúng tôi làm. Khi chúng tôi xuất bản một bài viết mới trên site thì chúng tôi sẽ tweet về nó. Chúng tôi có các RSS feed cho các tin tứcsự kiện thú vị mà chúng tôi đi qua. Và mỗi tháng chúng tôi xuất bản một thư tin bao gồm những nhấn mạnh nội dung của chúng tôi. Thư tin trong số những điều khác sẽ được công bố trong danh sách thư của chúng tôi.
Bạn có tổ chức bất kỳ sự kiện nào có liên quan tới nguồn mở không?
Vâng chúng tôi tổ chức một dải rộng lớn các sự kiện tự do tham dự với các thành viên của cộng đồng giáo dục cao đẳng và đại học. Chúng tôi đồng tổ chức một hội nghị quốc gia TransferSummit UK nhằm vào các lãnh đạo doanh nghiệp và các thành viên của cộng đồng hàn lâm, những người gặp nhau để thảo luận về các cơ hội và thách thức của các yêu cầu để sử dụng sự phát triển và cấp phép của PMNM. Chúng tôi cũng tổ chức một số hội thảo mỗi năm, mang lại cùng nhau các đoàn đại biểu FE và HE để thảo luận và chia sẻ thực tiễn tốt nhất trong phát triển và triển khai PMNM.
Bạn có phát biểu tại sự kiện của chúng tôi không?
Hầu hết chắc chắn là . Chúng tôi luôn muốn nói cho mọi người về các vấn đề xung quanh PMNM và sẽ làm tốt nhất để lên lịch theo bất kỳ yêu cầu nói chuyện nào. Chúng tôi nói chủ yếu tại các sự kiện của nước Anh nhưng thường xuyên đi khắp EU và tham dự các dự kiện tại Mỹ trong quá khứ.
Chúng tôi đang viết một đề xuất dự án cho một lời gọi cấp vốn, có thể chúng tôi tiếp cận bạn vì sự tư vấn trước khi biết kết quả đầu ra của vụ thầu có được không?
Vâng thực sự là tốt hơn để liên hệ với chúng tôi càng sớm càng tốt ngay khi viết đề xuất dự án. Cách này chúng tôi có thể giúp bạn giải quyết các vấn đề chính về phát triển phần mềm thường bị các dự án bỏ qua như việc cấp phép (bản dịch tiếng Việt) cho tính bền vững (bản dịch tiếng Việt) của sự điều hành (bản dịch tiếng Việt) của cộng đồng (bản dịch tiếng Việt) và ngân sách cho chúng một cách tương ứng. Tư vấn cho các vụ thầu dự án đưa ra một tổng quan về cách mà chúng tôi có thể giúp theo cách này.
OSS Watch có thể tư vấn cho tôi về các vấn đề có liên quan tới các tiêu chuẩn mở được không?
Các tiêu chuẩn mở chắc chắn có thể giúp để cải thiện tính tương hợp nhưng OSS Watch không theo dõi sự phát triển và áp dụng các tiêu chuẩn. Chúng tôi vì thế gợi ý rằng bạn liên lạc với một trung tâm hỗ trợ đổi mới bổ sung của JISC, Trung tâm về Công nghệ Giáo dục và các Tiêu chuẩn Tương hợp - JISC CETIS (Centre for Educational Technology and Interoperability Standards) để có thêm thông tin về các tiêu chuẩn mở.
Bạn có thể bổ sung thêm lời kêu gọi các tài liệu / lưu ý hội thảo vào site của bạn được không?
Chúng tôi rất vui mừng miễn là nó vì lợi ích của mọi người trong HE/FE tại nước Anh và phù hợp với nguồn mở.
Bạn có thể công khai hóa sự kiện hoặc tin tức của tôi về dự án của tôi không?
Miễn là tin tức và sự kiện của bạn là phù hợp với PMNM và khu vực giáo dục tại nước Anh thì chúng tôi vui mừng bổ sung sự kiện cuaru bạn hoặc một đường liên kết tới khoản tin tức của bạn trên trang tin tức hoặc các sự kiện của chúng tôi. Xin hãy liên hệ với chúng tôi với yêu cầu của bạn.
Bạn có chấp nhận các bài viết của khách trên blog không?
Chúng tôi không chỉ chấp nhận các bài viết của khách trên blog mà chúng tôi chào đón chúng! OSS Watch tư vấn cho HE và FE về phát triển nguồn mở (bản dịch tiếng Việt) và điều này là trong tâm của blog chúng tôi. Nếu bạn muốn đóng góp một bài viết của khách thì xin hãy chỉ cho chúng tôi một vài mẩu mà bạn đã viết gần đây và cho chúng tôi biết kinh nghiệm nào trong lĩnh vực nguồn mở bạn có thể mang tới một bài viết trên blog.
Các bài viết được OSS Watch xuất bản áp dụng được cho các khu vực khác hơn là khu vực FE và HE của nước Anh chứ?
Tuyệt đối đúng. Nhiều tư liệu của chúng tôi thảo luận các vấn đề có liên quan tới nguồn mở có khả năng áp dụng ngang bằng như nhau cho khu vực nhà nước nói chung hoặc khu vực thương mại. Sử dụng các tài nguyên của OSS Watch trong tổ chức của bạn (bản dịch tiếng Việt) nhấn mạnh nhiều ví dụ về cách mà các tư liệu của chúng tôi có thể sử dụng được trong các khu vực khác.
Về nguồn mở
Phần mềm tự do nguồn mở là gì?
Đối với OSS Watch PMNM là phần mềm đã được phát hành theo một giấy phép do Sáng kiến Nguồn Mở (OSI) phê chuẩn. OSS Watch sử dụng danh sách được OSI phê chuẩn này như một phương tiện để tránh những tranh cãi về sự diễn giải định nghĩa nguồn mở và các giấy phép nào tuân thủ hoặc không tuân thủ với nó. Bằng việc thừa nhận OSI như là cơ quan phù hợp cuối cùng trong vấn đề này nhiều sự lẫn lộn là tránh được. Sự diễn đạt nguồn mở có ứng dụng rộng rãi. Đối với OSI nó cũng tham chiếu tới phương pháp luận phát triển phần mềm đặc biệt được nhiều dự án PMNM sử dụng. Trang chủ của OSI bắt đầu với “Nguồn mở là phương pháp phát triển cho phần mềm mà khai thác sức mạnh của sự rà soát lại ngang hàng phân tán và sự minh bạch của qui trình”.
Phát triển mở là gì?
Phát triển mở là một khái niệm đang nổi lên, được sử dụng để mô tả mô hình phát triển do cộng đồng dẫn dắt được thấy trong nhiều dự án thành công của PMTDNM.
Phương pháp luận này đối nghịch với nhiều nguyên tắc của phát triển phần mềm thường được dạy trong các viện nghiên cứu. Mô hình này tập trung vào những sự lặp đi lặp lại nhanh của sự phát triển và các đội tự quản lý phân tán. Sự đóng góp cho dự án được khuyến khích từ tất cả các bên có quan tâm trong khi một mô hình điều hành rõ ràng được xác định để đảm bảo dự án không bị rơi vào hỗn loạn.
PMNM nói một cách khắt khe có thể có hoặc không được phát triển bằng việc sử dụng một phương pháp luận phát triển mở. Sự lựa chọn điều này hoặc bất kỳ phương pháp luận phát triển nào khác phụ thuộc vào con đường được chọn của dự án hướng tới tính bền vững.
Cách tốt nhất để trao sự tin tưởng cho các lập trình viên nguồn mở là gì?
Các dự án nguồn mở tốt được cộng đồng phát triển sao cho thường không có các 'ngôi sao nhạc rock' cá nhân nào. Một trong những cách thức tốt nhất để trao sự tin cậy cho cộng đồng là phải lôi cuốn được sự chú ý tới dự án bằng việc nói công khai (và trong danh sách thư của dự án) cách mà bạn thấy nó hữu dụng. Bạn có thể đi tốt hơn bằng việc tự bạn tham gia vào với và đóng góp (bản dịch tiếng Việt) cho nó - hoặc tốt nhất trong tất cả bằng việc khuyến khích những người khác làm như vậy.
Tôi có cần các nhân viên CNTT nội bộ để hưởng lợi từ PMNM không?
Không, bạn không cần các nhân viên CNTT trong nội bộ. Sự tin cậy của bạn vào các nhân viên phần lớn là y hệt như nó có thể đối với một giải pháp nguồn đóng. Để tùy biến một giải pháp nguồn mở thì bạn cần hoặc các nhân viên nội bộ hoặc các nhân viên có hợp đồng. Trong trường hợp của nguồn đóng, bạn chỉ có lựa chọn của các nhân viên có hợp đồng cho nhiều tùy biến.
Mô hình phát triển PMNM có hữu dụng cho nghiên cứu hàn lâm không?
Nói chung là có. Có nhiều ví dụ (bản dịch tiếng Việt) về PMNM từng được phát triển bởi và cho các nhà nghiên cứu, như TexGen (bản dịch tiếng Việt). Văn hóa phát triển mở cũng có thể rất có lợi trong một môi trường nghiên cứu cộng tác (bản dịch tiếng Việt).
Đổi mới mở là gì?
Nhiều người lẫn lộn đổi mới với sáng tạo, nhưng đổi mới là về nhiều hơn sáng tạo. Trong khi sáng tạo tập trung vào sự tạo ra thứ gì đó mới mà không nhất thiết hiện thực hóa được lợi ích kinh tế còn đổi mới là ứng dụng các sáng tạo để tạo ra lợi ích kinh tế. Đổi mới mở thừa nhận rằng trong thế giới hiện đại không tổ chức duy nhất nào có một sự độc quyền trong sáng tạo và thúc đẩy việc chia sẻ các sáng tạo và/hoặc các đổi mới xuyên khắp các biên giới về tổ chức. Tìm ra nhiều hơn về đổi mới mở trong tài liệu ngắn gọn của chúng tôi Nguồn mở và đổi mới mở (bản dịch tiếng Việt).
Tôi có thể phân phối ứng dụng nguồn mở của tôi thông qua một kho ứng dụng được không?
Điều này phụ thuộc chủ yếu vào giấy phép ứng dụng của bạn và thỏa thuận của người lập trình mà kho ứng dụng đặc thù đó đã đặt vào. Nói chung các giấy phép dễ dãi hơn như BSD và Apache là ít có vấn đề hơn. Để có thêm thông tin, hãy đọc ghi chép ngắn gọn của chúng tôi về các kho ứng dụng (bản dịch tiếng Việt) và hãy liên hệ với chúng tôi nếu bạn có nhiều các câu hỏi hơn sau này.
Ở mức độ nào PMNM được sử dụng trong khu vực HE và FE?
OSS Watch đã và đang nghiên cứu sự sử dụng và chính sách xung quanh PMNM trong khu vực HE/FE mỗi 2 năm kể từ khi nó bắt đầu vào năm 2003. Qua các năm chúng tôi đã thấy một sự sử dụng PMNM ngày một gia tăng chưa từng có. Khảo sát mới nhất đã được tổ chức vào năm 2010 và chỉ ra rằng tư vấn nhiều hơn là cần thiết để giúp khu vực này đánh giá được các dự án nguồn mở. Mô hình Độ chín Bền vững Phần mềm (bản dịch tiếng Việt) của OSS Watch có thể giúp đạt được điều này.
Nguồn mở và luật
Giấy phép nguồn mở nào chúng tôi nên sử dụng?
Nhiều dự án không bắt đầu một sản phẩm phần mềm mới mà thay vào đó bổ sung thêm vào hoặc cải thiện một sản phẩm phần mềm đang tồn tại trong những trường hợp như vậy hầu hết sự lựa chọn cấp phép hợp lý nhất có lẽ là sử dụng giấy phép y hệt và trong một số trường hợp bạn không có sự lựa chọn.
Nhiều dự án là một phần của (hoặc kế hoạch sẽ là một phần của) một cộng đồng lớn hơn các dự án như Apache Software Foundation, Free Software Foundation, Debian hoặc Ubuntu. Nhiều trong số này hạn chế sự lựa chọn có sẵn của việc cấp phép. Để biết cộng đồng bạn muốn tích hợp dự án của bạn vào và hiểu được cách mà sự lựa chọn giấy phép của bạn sẽ ảnh hưởng tới sự cam kết tham gia của bạn với cộng đồng đó.
Một số dự án có thẻ có các đối tác thương mại có mong muốn khai thác một cách thương mại các kết quả đầu ra của dự án. Nếu điều này là đúng thì một giấy phép cho phép mô hình khai thác thương mại được lựa chọn sẽ được chọn khi mà hầu hết các giấy phép có một tác động trực tiếp vào tính phù hợp của các con đường khai thác khác nhau.
Nếu không có sự lựa chọn rõ ràng cho các giấy phép của dự án của bạn, thì bạn có thể chọn cấp phép cho mã của bạn theo nhiều giấy phép, một thực tế được gọi là việc cấp phép đôi. Các dự án như Dự án Mozilla sử dụng việc cấp phép đôi để giải quyết các căng thẳng về cấp phép.
Chúng tôi đang phát triển một số phần mềm và muốn làm cho nó thành nguồn mở - giấy phép nào chúng tôi nên sử dụng?
Có hơn 70 giấy phép được OSI phê chuẩn dù chỉ một nhúm các giấy phép là thường được sử dụng. Quyết định của bạn nên được dựa vào việc liệu bạn có muốn cho phép những người khác sử dụng lại mã của bạn trong các dự án mà bản thân chúng không phải là nguồn mở hay không, hay bạn muốn mã của bạn chỉ có thể được sử dụng trong các dự án khác mà bản thân chúng là nguồn mở.
Nếu bạn đang sử dụng lại mã được ai đó khác phát triển thì bạn sẽ cần phải cẩn thận rằng bạn sử dụng một giấy phép tương thích với mã đó. Một số giấy phép đi với các mệnh đề bằng sáng chế hoặc yêu cầu rằng những sửa đổi mã nguồn phải được đóng góp ngược lại cho các lập trình viên ban đầu. Xin hãy xem phần Việc cấp phép và các Bằng sáng chế của các quyền sở hữu trí tuệ (IPR) (bản dịch tiếng Việt) để học thêm về các giấy phép riêng rẽ. Hãy liên hệ với chúng tôi nếu bạn muốn thảo luận về sự lựa chọn tiếp tục của bạn.
Một mẩu phần mềm trong cơ quan của chúng tôi được phát hành theo giấy phép GPLv3. Liệu tôi có còn có thể tạo ra các giấy phép hữu dụng và có giá trị khác được không?
Đối với một số nền tảng về việc phát hành mã theo một giấy phép nguồn mở, chúng tôi đã viết một giới thiệu chung (bản dịch tiếng Việt) về chủ đề này. Đặc biệt giấy phép GPLv3 bắt buộc rằng bất kỳ ai mà sửa đổi phần mềm và muốn phân phối phiên bản sửa đổi của chúng cần phải làm thế theo cùng giấy phép copyleft đó. Điều này có ý định để đảm bảo rằng mã không bị lấy đi khỏi cộng đồng và rằng tất cả các cải tiến là sẵn sàng cho tất cả mọi người.
Các nhà cung cấp thương mại mong muốn sử dụng phần mềm mà đã được phát hành thường không muốn sẽ bị ràng buộc bởi một giấy phép như vậy vì họ không muốn làm cho sản phẩm của họ là nguồn mở. Một giải pháp cho điều này là hãy sử dụng việc cấp phép đôi (bản dịch tiếng Việt) cho mã đó. Nói ngắn gọn điều này có nghĩa là bạn có thể bán các giấy phép cho các công ty mà không muốn bị ràng buộc vào các điều kiện cấp phép của phiên bản có sẵn một cách tự do.
Tôi có một mệnh đề sở hữu trí tuệ (IP) trong hợp đồng làm việc của tôi - làm thế nào tôi có thể phát hành phần mềm của tôi như là nguồn mở?
Có khả năng là ông chủ của bạn sẽ sở hữu bản quyền trong phần mềm mà bạn tạo ra và vì thế bạn sẽ cần sự cho phép của họ để làm cho nó sẵn sàng như là PMTDNM.
Hãy xem xét trong tài liệu của chúng tôi về việc đóng góp mã cho một dự án nguồn mở để có thêm chi tiết về việc đóng góp cho một dự án đang tồn tại. Bạn cũng có thể muốn đọc Giới thiệu các vấn đề về quyền sở hữu và cấp phép (bản dịch tiếng Việt) để có nhiều thông tin chi tiết hơn về chủ đề này.
Giấy phép nào chúng tôi nên sử dụng cho các giao phẩm không phải là phần mềm?
Nếu các giao phẩm không phải là phần mềm được đóng gói hoặc đánh đống với các giao phẩm phần mềm và không có khả năng sẽ được sử dụng lại một cách hữu dụng mà không có chúng thì có ít ý nghĩa để cấp phép cho chúng một cách riêng rẽ.
Tuy nhiên, nếu có các giao phẩm không phải là phần mềm mà có khả năng sử dụng lại được một cách độc lập hoặc phân phối lại được thì có thể có ý nghĩa để xem xét cấp phép cho chúng một cách riêng rẽ. Các giấy phép Creative Commons có lẽ là giấy phép được sử dụng rộng rãi nhất cho nội dung. OSS Watch đã có tài liệu về qui trình mà dẫn tới sử dụng Creative Commons của chúng tôi (chúng tôi trước đó đã sử dụng Giấy phép Tài liệu Tự do GNU – GFDL).
Bạn có thể tư vấn về cách cấp phép cho phần mềm được tạo ra trong một viện trường của HE? Bạn sẽ đưa vào các mô hình thương mại chứ?
Chúng tôi đưa ra tư vấn về việc cấp phép nguồn mở của phần mềm. Điều quan trọng để lưu ý rằng nguồn mở không đối nghịch với thương mại là đối nghịch với nguồn đóng. Bổ sung thêm vào tư vấn cấp phép nguồn mở, chúng tôi cũng đưa ra tư vấn về các mô hình kinh doanh áp dụng được cho PMNM. Nếu chúng tôi có thể trợ giúp được để hiểu các mô hình đó khi chúng áp dụng cho dự án của bạn, xin đừng ngại liên hệ với chúng tôi.
Tôi có thể sử dụng một giấy phép nội dung trong mã của tôi được không?
Chúng tôi có thể tư vấn chống lại nó rất mạnh mẽ. Các giấy phép nội dung mở được áp dụng cho phần mềm thực thi được tạo ra yêu cầu cho mã nguồn tương ứng sẽ được làm thành sẵn sàng. Các giấy phép nội dung mở được áp dụng cho mã nguồn không đòi hỏi bất kỳ sự thực thi nào được xây dựng từ nguồn đó sẽ có mã của chúng được xuất bản. Tất cả theo tất cả các giấy phép nội dung mở được áp dụng không tốt cho những hoàn cảnh đặc biệt xung quanh việc tạo và ra thay đổi phần mềm máy tính.
Tôi có thể cản trở sử dụng lại thương mại mã của tôi bằng việc sử dụng một giấy phép nguồn mở?
Không, trực tiếp thì không. Điểm 6 của Định nghĩa Nguồn Mở nói rằng điều kiện tiên quyết cho bất kỳ giấy phép nào sẽ được xem là nguồn mở là nó sẽ thực hiện 'Không phân biệt đối xử chống lại các lĩnh vực của đời sống'. Khai thác thương mại là một lĩnh vực của đời sống.
Đã nói điều này, một số giấy phép nguồn mở làm cho mã mà chúng bao trùm ít cuốn hút hơn đối với các thực thể thương mại để đưa vào trong các sản phẩm của họ. Nói chung các giấy phép với một số yếu tố 'copyleft' như GNU GPLv2 hoặc Mozilla Public License sẽ ép buộc những người sử dụng lại thương mại làm cho một số hoặc tất cả mã của riêng họ là nguồn mở. Các giấy phép dễ dãi như giấy phép BSDApache License v2 cho phép mã mà chúng bao trùm sẽ được bổ sung vào một dự án nguồn đóng mà không ép buộc bất kỳ mã nào khác phải là nguồn mở.
Tìm kiếm phần mềm nguồn mở
Làm thế nào tôi có thể tìm ra liệu có một ứng dụng nguồn mở nào cho các mục đích đặc thù của tôi được không?
Tất cả các nhà cung cấp đặt chỗ (hosting) đưa ra sự phân loại và các phương tiện tìm kiếm. Ví dụ bạn có thể tìm kiếm Google Code mà cho phép các dự án tự bản thân chúng xác định các nhãn để phân loại các dự án của chúng vì thế làm cho chúng tìm được tốt hơn. SourceForge sử dụng sự phân loại cho phép bạn đào sâu xuống qua các chúng loại dựa vào dạng phần mềm mà bạn đang tìm kiếm.
Cũng có các site tổng hợp như Ohloh cho phép bạn tìm kiếm qua nhiều website kho chứa khác nhau.
Tôi từng nghe có một đĩa CD với một bộ sưu tập PMNM. Chúng tôi có thể lấy nó ở đâu?
Bạn có thể tải về hoặc mua TheOpenDisc từ website. Webiste Ubuntu cũng đưa ra các chi tiết về cách để tải về hoặc mua các CD của phát tán phổ biến của họ như website Knoppix làm. Những người sử dụng MacOS X có thể tải về FreeSMUG Suite CD. Cũng có quan tâm tiềm tàng là phần mềm tự do nguồn mở Portable Apps, được áp dụng để chạy trực tiếp từ các đầu USB và EduApps mà có tiếp cận tương tự như mới các phần mềm nguồn mở cho các nhà giáo dục và các ứng dụng công nghệ có khả năng truy cập được.
Làm thế nào tôi cáo thể xác định được liệu nó có an toàn để sử dụng (lại) một dự án nguồn mở cụ thể nào đó?
Vấn đề quan trọng nhất khi đánh giá một dự án nguồn mở là để kiểm tra xem liệu sở hữu trí tuệ (IP) và nguồn gốc lai lịch IP (bản dịch tiếng Việt) có được quản lý tốt hay không. Hơn nữa tính bền vững của dự án là rất quan trọng bất kể liệu bạn có là một người sử dụng đầu cuối hoặc có ý định sử dụng lại phần mềm cho dự án của riêng bạn hay không. Chúng tôi gần đây đã phát hành một tài liệu về Mô hình Độ chín Bền vững của Phần mềm (bản dịch tiếng Việt) để giúp bạn xác định liệu một dự án có thể được sử dụng lại an toàn hay không. Bằng việc áp dụng mô hình này bạn có thể đánh giá được một dự án nguồn mở về 3 yếu tố bền vững: tính mớ, khả năng sử dụng lại và năng lực.
Quản lý các dự án nguồn mở
Bạn có thể giúp chúng tôi chia sẻ một ứng dụng được phát triển trong phòng của chúng tôi như một giải pháp nguồn mở hay không?
Chúng tôi chắc chắn có thể giúp bạn tối đa hóa các cơ hội có được nhiều nhất từ đầu tư ban đầu của bạn trong việc tạo ra phần mềm bằng việc quản lý nó như một dự án nguồn mở (bản dịch tiếng Việt). Đổi lại cho nỗ lực của bạn về việc áp dụng một mô hình điều hành (bản dịch tiếng Việt), thiết lập một số qui trình và công cụ (bản dịch tiếng Việt) phát triển phần mềm cơ bản và làm sáng tỏ khung IPR (bản dịch tiếng Việt) của dự án thì bạn sẽ tối đa hóa được các cơ hội cho việc đóng góp cho phần mềm của bạn theo một cách thức phát triển mở (bản dịch tiếng Việt). Chìa khóa để làm cho dự án của bạn bền vững (bản dịch tiếng Việt) về lâu dài là việc xây dựng một cộng đồng thịnh vượng (bản dịch tiếng Việt) những người sử dụng và các lập trình viên xung quanh nó bằng việc giảm thiểu các rào cản cho sự áp dụng và khuyến kích và tưởng thưởng cho tất cả các dạng đóng góp.
Mô hình điều hành là gì và làm thế nào tôi thiết kế được một mô hình?
Mô hình điều hành (bản dịch tiếng Việt) là một tài liệu công khai mô tả cách mà một dự án được quản lý. Đặc biệt nó mô tả cấu trúc của đội bao gồm các vai trò cá nhân và mô tả rõ ràng cách mà những người khác có thể đóng góp cho một dự án. Nó cũng phác thảo các qui trình được tuân thủ khi thực hiện các hoạt động của dự án.
Trong khi có một tiềm năng cho một loạt các mô hình điều hành không được xác định mà chúng có xu hướng nằm ở đâu đó trong một phạm vi giữa 2 cực được thừa nhận chung, được biết tới như là các mô hình 'người tài lãnh đạo' (bản dịch tiếng Việt) và 'nhà độc tài nhân từ' (bản dịch tiếng Việt). Sự khác biệt giữa 2 mô hình đó là trong thực tế là không thật lớn và những mối lo ngại hầu hết là về cơ chế giải quyết xung đột trong qui trình ra quyết định.
Nơi nào là tốt nhất để đặt mã nguồn mở của tôi?
Có một số con đường có thể. Tất cả chúng là về việc tìm ra ngôi nhà đúng của cộng đồng cho dự án của bạn sao cho sự lựa chọn của bạn sẽ phụ thuộc vào bản chất tự nhiên của dự án của bạn.
Các kho công cộng như SourceForge (bản dịch tiếng Việt) và Google Code (bản dịch tiếng Việt) là thuận tiện và trực quan cao nhưng chúng là đông đúc với các dự án chết hoặc đang chết.
Hạ tầng riêng là con đường khác có thể nhưng điều này cần phải được quản lý và duy trì như tính trực quan của máy tìm kiếm làm được. Một số người lựa chọn thứ gì đó như RedMine TRAC hoặc các ứng dụng gForge mà cho phép bạn đặt chỗ trong môi trường như SourceForge trong hạ tầng riêng của riêng bạn. Theo ý của chúng tôi thì có ít ưu thế trong việc đặt chỗ trong hạ tầng của riêng bạn ngoài thương hiệu và quyền sở hữu.
Các Quỹ (Foundation) cũng là một lựa chọn. Con đường này đưa ra các cấu trúc quản lý được chứng minh và có thể bổ sung một mức chất lượng và thương hiệu không được tạo ra dễ dàng bằng các phương tiện khác. Xem Apache Cocoon: một trường hợp điển hình về tính bền vững (bản dịch tiếng Việt) và Sakai: một trường hợp điển hình về tính bền vững (bản dịch tiếng Việt).
Cách nào là tốt nhất cho việc khai thác và duy trì bền vững thành công dự án nguồn mở của bạn?
Có nhiều mô hình kinh doanh và bền vững có sẵn cho các dự án nguồn mở. Chúng không loại trừ lẫn nhau và hầu hết thường được sử dụng trong sự kết hợp phụ thuộc vào kích cỡ các nhu cầu và mục đích của dự án. Để thảo luận chi tiết hơn về các lựa chọn khác nhau, hãy xem tài liệu của chúng tôi Các mô hình kinh doanh và bền vững của phần mềm tự do nguồn mở (bản dịch tiếng Việt).
Chúng tôi đang lên kế hoạch cho một dự án nghiên cứu để mở nguồn phần mềm nghiên cứu của chúng tôi. Bạn có thể cung cấp tư vấn về việc viết một kế hoạch hành động biến đổi sang nguồn mở được không?
Chắc chắn chúng tôi cso thể nhưng thực tế là có quá nhiều biến số cho hầu hết các dự án để giải quyết mà không có một sự tư vấn phù hợp mà chúng tôi cung cấp miễn phí cho các viện trường của HE và FE ở nước Anh.
Điểm khởi đầu là mở nguồn mã của bạn. Tuy nhiên điều này chỉ là một phần của qui trình quản lý phần mềm. Chỉ bằng việc gán vào một giấy phép nguồn mở (bản dịch tiếng Việt) lên nó sẽ không tạo thành một cộng đồng tích cực (bản dịch tiếng Việt) được. Làm cho phần mềm của bạn bền vững (bản dịch tiếng Việt) về lâu dài có liên quan chặt chẽ tới việc chọn một sự điều hành dự án (bản dịch tiếng Việt) phù hợp với một mô hình kinh doanh (bản dịch tiếng Việt) thích hợp.
Làm thế nào tôi tùy biến nguồn mở theo một cách thức có thể duy trì được?
Trong khi có được sự truy cập tới mã nguồn là một trong những lợi ích chính của các lập trình viên nguồn mở, thì có thể có khó khăn khi tiến hành các thay đổi. Điều này đặc biệt đúng nếu các tác động đầy đủ của những thay đổi đó không được cân nhắc cẩn thận. Thường thì những thay đổi mở rộng cục bộ có thể dẫn tới những hoạt động pha trộn đắt giá khi nâng cấp tới một phiên bản mới của dự án hoặc việc cài đặt các module mới không tương thích với các tùy biến cục bộ đó.
Một cách để tránh phí tổn này là làm việc với kiến trúc phần mềm và giới hạn những thay đổi tới một 'trình cài cắm' (plug-in). Điều này có thể được quản lý như một dự án riêng rẽ với một ít sự phụ thuộc vào mã cốt lõi. Mã của trình cài cắm như vậy thường ít bị những thay đổi của dự án làm ảnh hưởng tới. Thậm chí một tiếp cận còn hiệu quả hơn là làm việc với cộng đồng dự án (bản dịch tiếng Việt) để tùy biến thích nghi những thay đổi đó trong dự án cốt lõi. Những thay đổi đó sau đó được dự án duy trì và sẽ được đưa vào tự động trong phát hành tiếp sau. Nỗ lực dư thừa có liên quan thường có giá trị hơn khi những chi phí duy trì được giảm thiểu hoặc uy tín của các lập trình viên và cơ quan được cải thiện như là kết quả của việc tiến hành đóng góp.
Những công cụ nào chúng tôi cần hỗ trợ cho sự phát triển mở?
Trong các dự án phát triển mở (bản dịch tiếng Việt) có một ít các công cụ không thể thiếu: một hệ thống kiểm soát phiên bản (bản dịch tiếng Việt), một trình theo dõi các vấn đề, một hoặc vài danh sách thư và một website. Chúng tôi có những tài liệu đặc thù về làm thế nào chúng có thể được thiết lập bằng việc sử dụng SourceForge (bản dịch tiếng Việt) hoặc Google code (bản dịch tiếng Việt). Nếu bạn có nhiều hơn các câu hỏi về sử dụng các công cụ đó thì bạn có thể luôn có liên lạc với chúng tôi để có thêm thông tin và/hoặc một cuộc tư vấn đâu là nơi mà chúng tôi có thể giải quyết được các vấn đề đặc thù đó của bạn.
Qui trình quản lý phát hành là gì và vì sao nó quan trọng phải có một qui trình được định nghĩa rõ ràng?
Một qui trình quản lý phát hành xác định cách mà phần mềm được xây dựng được đóng gói và được phân phối. Việc có một qui trình rõ ràng tại chỗ từ đầu sẽ xúc tác cho một đội dự án lên kế hoạch và lập lịch cho công việc đặt ưu tiên cho một phát hành và giải quyết bất kỳ vấn đề pháp lý nào. Nó cũng đảm bảo rằng phát hành đó có đủ chất lượng và sẽ là hữu dụng cho những người khác. Để có thêm thông tin hãy đọc Quản lý phát hành trong các dự án phần mềm nguồn mở (bản dịch tiếng Việt) và Thực tiễn tốt nhất trong quản lý phát hành (bản dịch tiếng Việt).
Làm thế nào các lập trình viên mới có thể đóng góp mã cho dự án của tôi?
Khi các lập trình viên mới muốn tham gia vào với dự án PMNM và tài trợ mã cho dự án thì họ có thể sẽ không có sự truy cập ghi vào hệ thống kiểm soát phiên bản (bản dịch tiếng Việt) mà điều này có nghĩa là họ không thể đệ trình mã của họ một cách trực tiếp tới dự án. Thay vào đó họ có thể cung cấp mã như một bản vá (bản dịch tiếng Việt). Đây là một bản ghi những thay đổi được thực hiện cho một hoặc nhiều tài nguyên mà chúng là một phần của mã phần mềm của dự án. Một số người trong dự án mà có sự truy cập ghi đối với mã đó có thể áp dụng bản vá đó cho mã nguồn. Trong thông điệp đệ trình thì người mà đã đóng góp mã được tin tưởng như là người đóng góp gốc ban đầu.
Ý kiến phản hồi và các bình luận
Một trong những bài báo của bạn bị sai lệch một chút - bạn sẽ làm gì với nó?
Chúng tôi cố gắng đảm bảo rằng mọi điều trên website của chúng tôi là chỉnh chu và không thiên vị nhưng đôi khi thông tin là lỗi thời và chúng tôi không thể không có sai sót. Xin gửi thư điện tử về mailto:info@oss-watch.ac.uk với bất kỳ sự sửa cho đúng hoặc sự định phẩm chất nào.
About OSS Watch
Who is OSS Watch?
OSS Watch is an open source software advisory service for the UK higher and Further Education sector. We are funded by the Joint Information System Comittee (JISC) that means our services are free to the HE and FE sector.
We help institutions and education related projects in the use and development of free and open source software. We provide a variety of services including:
When was OSS Watch created and why?
In 2003 when OSS Watch started there was very little understanding in the UK academic sector about what open source is and how one would engage with it. OSS Watch was set up to examine the state of play and to make recommendations that would enable the sector to fully benefit from open source software.
Over the years the focus has moved from creating a base level understanding through to detailed legal procurement and engagement advice and support. More recently we have emphasized how open source software can be sustained and how business models can be built to ensure that software developed in HE and FE is available customisable and supported with minimal costs for as long as possible.
How can I be sure that OSS Watch’s documents are up to date?
All of the documents published on the OSS Watch website are subject to a rigorous review process conducted by members of the OSS Watch team. This begins six months after the document is first published when itis reviewed for integrity. After 12 months and thereafter on a six-monthly basis it will be reviewed for integrity and relevance and edited or rewritten to bring it up to date or archived. In spite of our thoroughness we are not infallible and always welcome feedback that will help us keep up to date.
Our document inception and review processes are described in greater detail in The life of an OSS Watch document.
How can I stay up to date with OSS Watch’s activities?
We regularly blog (also available as RSS feed) about everything we do. When we publish a new article on the site we will tweet about it. We have RSS feeds for interesting news and events we come across. And every month we publish a newsletter that contains the highlights of our content. The newsletter amongst other things will be announced on our mailing list.
Do you organize any open source-related events?
Yes we host a wide range of events free to attend by members of the further and higher education community. We co-organize TransferSummit UK a national conference aimed at business executives and members of the academic community who meet to discuss requirements challenges and opportunities for the use development and licensing of open source software. We also host a number of workshops every year that bring together FE and HE delegates to discuss and share best practice in the development and deployment of open source software.
Would you speak at our event?
Almost certainly yes. We are always keen to talk to people about the issues surrounding open source software and will do our best to schedule in any speaking requests. We speak mainly at UK events but regularly travel across the EU and have attended events in the US in the past.
We are writing a project proposal for a funding call, can we approach you for advice before knowing the outcome of the bid?
Yes it is actually better to contact us as early as writing the project proposal. This way we can help you address key software development issues often ignored by projects such as licensing community governance sustainability and budget for them accordingly. Advice for project bids provides an overview of how we can help in this respect.
Can OSS Watch advise me on matters relating to open standards?
Open standards can certainly help to improve interoperability but OSS Watch does not track standards development and adoption. We therefore suggest that you get in touch with a complimentary JISC innovation support centre JISC CETIS (Centre for Educational Technology and Interoperability Standards) for further information on open standards.
Could you add this call for papers / conference notification to your site?
We’d be delighted to provided it is of interest to people in further and higher education in the UK and relevant to open source.
Would you publicise my event or news about my project?
Provided your news or event is relevant to open source software and the educational sector in the UK we are delighted to add your event or a link to your news item on our news or events page. Please contact us with your request.
Do you accept guest blog posts?
We not only accept guest blog posts we welcome them! OSS Watch advises UK HE and FE on open source development and this is at the heart of our blog. If you would like to contribute a guest post please point us to a few pieces you wrote recently and let us know what experience in the area of open source you could bring to a blog piece.
Are the articles published by OSS Watch applicable to sectors other than the UK FE and HE sector?
Absolutely. Many of our materials discuss issues related to open source that are equally applicable to the public sector in general or to the commercial sector. Use OSS Watch’s resources within your organisation highlights many examples of how our materials could be of use in other sectors.
About open source
What is Free and Open Source Software?
For OSS Watch open source software is software that has been released under an Open Source Initiative (OSI) certified licence. OSS Watch uses this OSI-approved list as a means of avoiding debates over interpretation of the open source definition and which licences do or do not conform to it. By recognising the OSI as the appropriate final authority in this issue much confusion is avoided.
The expression open source has wide application. For the OSI it also refers to the distinctive software development methodology employed by many open source software projects. The OSI home page starts with “Open source is a development method for software that harnesses the power of distributed peer review and transparency of process.”
What is open development?
Open development is an emerging term used to describe the community led development model found within many succesful free and open source software projects.
This methodology contrasts with many of the principles of software development normally taught in academia. The model focusses on fast iterations of development and distributed self managing teams. Contribution to the project is encouraged from all interested parties while a clear governance model is defined to ensure the project does not descend into chaos.
Open source software strictly speaking may or may not be developed using an open development methodology. The choice of this or any other development methodology is dependent upon a project’s chosen route to sustainability.
What is the best way to give credit to open source developers?
Good open source projects are developed by the community so there are usually no individual ‘rock stars’. One of the best ways to give credit to the community is to draw attention to the project by saying publicly (and on the project mailing list) how useful you found it. You can go one better by engaging with and contributing to it yourself - or best of all by encouraging others to do so.
Do I need internal IT staff to benefit from open source software?
No you do not need internal IT staff. Your reliance on staff is largely the same as it would be for a closed source solution. To customise an open sorce solution you need either internal or contracted staff. In the case of closed source you only have the option of contracted staff for many customisations.
Is the model of open source software development useful for academic research?
In general yes. There are many examples of open source software that has been developed by and for researchers e.g. TexGen. An open development culture can also be very beneficial in a collaborative research environment.
What is open innovation?
Many people confuse innovation with invention but innovation is about more than invention. While invention focuses on the creation of something new without necessarily realising economic benefit innovation is the application of inventions to generate economic benefit. Open innovation recognises that in the modern world no single organisation has a monopoly on invention and promotes the sharing of inventions and/or innovations across organisational boundaries. Find out more about open innovation in our briefing document Open source and open innovation.
Can I distribute my open source application via an app store?
This depends mainly on the licence of your application and the developer agreement that the specific app store has put in place. In general more permissive licences like BSD and Apache are less problematic. For more information read our briefing note on app stores and feel free to contact us if you have more questions afterwards.
To what extent is open source software used in the HE and FE sector?
OSS Watch have been researching the use of and policy around open source software in the HE/FE sector every two years since its inception in 2003. Over the years we have seen an ever-increasing use of open source software. The latest survey was held in 2010 and shows that more advice is needed to help the sector evaluate open source projects. OSS Watch’s Software Sustainability Maturity Model can help achieving this.
Open source and the law
Which open source licence should we use?
Many projects don’t start a new software product but instead add to or improve an existing software product in such cases the most sensible licensing choice is probably to use the same licence indeed in some cases you have no choice.
Many projects are part of (or plan to be a part of) a larger community of projects such as the Apache Software Foundation Free Software Foundation Debian or Ubuntu. Many of these limit the licensing choice available. Get to know the community you wish to integrate your project into and understand how your licence choice will affect your engagement with that community.
Some projects may have commercial partners who wish to commercially exploit the software outputs of the project. If this is the case a licence which allows the chosen commercial exploitation model should be chosen since most licences have a direct impact on the suitability of different exploitation routes.
If there is no clear choice for your project licences you may choose to license your code under multiple licences a practice called dual licensing. Projects such as the Mozilla Project use dual licensing to resolve licensing tensions.
We are developing some software and would like to make it open source - which licence should we use?
There are over 70 OSI-approved licences although only a handful of these are commonly used. Your decision should be based upon whether you wish to allow others to re-use your code in projects that are not open source themselves or whether you wish that your code can only be used in other projects that are in themselves open source.
If you are re-using code developed by someone else then you will need to be careful that you use a licence compatible with that code. Some licences come with patent clauses or require that modifications to source code are fed back to the initial developers. Please see our Intellectual Property Rights (IPR) Licensing and Patents section to learn more about individual licences. Do get in touch with us if you’d like to discuss your choice further.
A piece of software at our institution is released under the GPLv3 licence. Can I still create other useful and valuable licenses?
For some more background on releasing code under an open source licence we have written a general introduction on the topic. Specifically the GPLv3 licence mandates that anyone who modifies the software and wishes to distribute their modified version needs to do so under the same copyleft licence. This is intended to ensure that the code is not taken away from the community and that all improvements are available to all.
Commercial vendors wishing to use the software that has been released often would not want to be bound by such a licence because they don’t want to make their product open source. A solution to this is to use dual-licensing for the code. In short this means that you can sell licences to companies that do not want to be bound by the licensing conditions of the freely available version.
I have an intellectual property (IP) clause in my employment contract - how can I release my software as open source?
It is likely that your employer will own the copyright in the software you create and that therefore you will need their permission to make it available as free or open source software.
Take a look at our document on contributing code to an open source project for more detailed information on contributing to an existing project. You might also like to read our Introduction to Ownership and Licensing Issues for more detailed information on this topic.
What licence should we use for non-software deliverables?
If the non-software deliverables are bundled or packaged with the software deliverables and unlikely to be usefully reused without them it makes little sense to license them separately.
If however there are non-software deliverables that are likely to be independently reusable or redistributable it may make sense to consider licensing them separately. The Creative Commons licences are probably the most widely used licence for content. OSS Watch has documented the process that led to our use of the Creative Commons (we previously used the GNU Free Documentation License).
Can you advise on how to license software created in an HE institution? Will you include commercial models?
We provide advice on open source licensing of software. It is important to note that open source is not the opposite of commercial it is the opposite of closed source. In addition to open source licensing advice we also provide advice on business models applicable to open source software. If we can be of assistance in understanding these models as they apply to your project please don’t hesitate to contact us.
Can I use an open content licence on my code?
We would advise against it very strongly. Open content licences applied to executable software make no requirement for the corresponding source code to be made available. Open content licences applied to source code do not require any executables built from the source to have their source published. All in all open content licences are poorly adapted to the special circumstances that surround the making and changing of computer software.
Can I restrain commercial reuse of my code using an open source licence?
Not directly no. Point 6 of the Open Source Definition states that a pre-requisite for any licence to be considered open source is that it should make ‘No Discrimination Against Fields of Endeavor’. Commercial exploitation is a field of endeavour.
Having said this some open source licences make code that they cover less appealing for commercial entities to include in their products. In general licences with some element of ‘copyleft’ such as the GNU GPLv2 or the Mozilla Public License will compel commercial reusers to make some or all of their own code open source. Permissive licences such as the BSD License and the Apache License v2 on the other hand allow the code they cover to be added to a closed source project without compelling any other code to be open source.
Finding open source software
How can I find out if there is an open source application for my specific purposes?
All major hosting providers provide categorisation and searching facilities. For example you can search Google Code which lets the projects themselves define labels to categorise their projects thereby making them better findable. SourceForge uses categorisation that allows you to drill down through the categories based on what type of software you are searching for.
There are also aggregation sites like Ohloh which allows you to search across many different repository websites.
I’ve heard there is a CD with a collection of open source software. Where can we get it from?
You can download or purchase TheOpenDisc from their website. The Ubuntu website also provides details about how to download or purchase CDs of their popular distribution as does the Knoppix website. MacOS X users can download the FreeSMUG Suite CD. Also of potential interest is Portable Apps free and open source software adapted to run directly from USB keys and EduApps which takes a similar approach to open source and freeware for educators learners and assistive technology applications.
How can I determine if it is safe to (re)use a specific open source project?
The most important issue when assessing an open source project is to check if IP and IP provenance has been managed well. Furthermore sustainability of the project is very important regardless of whether you are an end user or intending to reuse the software for your own project. We recently released a document on the Software Sustainability Maturity Model to help you deciding if a project can be reused safely. By applying this model you can evaluate an open source project in terms of three elements of sustainability: openness reusability and capability.
Managing open source projects
Can you help us share an application developed within our department as an open source solution?
We can certainly help you maximise the chances of getting the most from your initial investment in creating the software by managing it as an open source project. In return for your effort of adopting a governance model setting up some basic software development processes and tools and clarifying the project’s IPR framework you maximise the opportunities for contributing to your software in an open development fashion. The key to making your project sustainable in the long term is building a thriving community of users and developers around it by reducing barriers to adoption and encouraging and rewarding all forms of contribution.
What is a governance model and how do I design one?
A governance model is a public document that describes how a project is managed. In particular it describes the structure of the team including individual roles and clearly describes how others may contribute to a project. It also outlines the processes that are followed when performing project activities.
While there is potential for an infinite variety of governance models they tend to fall somewhere on a scale between the two commonly recognised extremes known as the ‘meritocratic’ and the ‘benevolent dictator’ models. The difference between these two models is in fact not so great and mostly concerns the the mechanism for resolving conflict in the decision making process.
Where is the best place to put my open source code?
There are a number of possible routes. It’s all about finding the right community home for your project so your choice will depend on the nature of your project.
Public repositories like SourceForge and Google Code are convenient and highly visible but they are crowded with dead or dying projects.
Private infrastructure is another possible route but this needs to be managed and maintained as does search engine visibility. Some people opt for something like RedMine TRAC or gForge applications that allow you to host a SourceForge-like environment on your own private infrastructure. In our opinion there is little advantage in hosting on your own infrastrcture other than branding and ownership.
Foundations are yet another option. This route provides proven management structures and can add a level of quality and branding not easily generated by other means. See Apache Cocoon: a case study in sustainability and Sakai: a case study in sustainability.
What are the best ways of successfully exploiting and sustaining your open source project?
There are many business and sustainability models available to open source projects. They are not mutually exclusive and are most often used in combination depending on the size needs and aims of the project. For a more detailed discussion of the various options see our document Free and open source business and sustainability models.
We are a research project planning to open source our research software. Can you provide advice on writing an open source transition action plan?
We sure can but the reality is that there are too many variables for most projects to address without a proper consultation which we provide free of charge to UK HE and FE institutions.
The starting point is open sourcing your code. However this is only part of the process of managing the software. Just slapping an open source licence on it will not result in an active community. Making your software sustainable in the long term is closely related to choosing a project governance matching an appropriate business model.
How do I customise open source in a maintainable way?
While having access to the source code is one of the key benefits of open source developers can run into difficulties when making changes. This is especially true if the full implications of those changes are not carefully considered. Typically extensive local changes can lead to expensive merging operations when upgrading to a new project release or installing new modules that are incompatible with local customisations.
One way to avoid this expense is to work with the software architecture and restrict changes to a ‘plug-in’. This can be managed as a separate project with few dependencies on the core code. Such plug-in code is less often effected by project changes. An even more effective approach is to work with the project community to adopt the changes into the core project. The changes are then maintained by the project and will be automatically included in the next release. The extra effort involved is often outweighed by the reduced maintenance costs or by the improved reputation of developers and institution as a result making contributions.
What tools do we need to support open development?
In open development projects there are a few indispensable tools: a version control system an issue tracker one or more mailing lists and a website. We have specific documents on how these can be set up using SourceForge or Google code. If you have more specific questions about the use of these tools you can always get in touch with us for more information and/or a consultation where we can address your specific issues.
What is a release management process and why is it important to have one clearly defined?
A release management process defines how software is built packaged and distributed. Having a clear process in place from the outset enables a project team to plan and schedule a release prioritise work and address any legal issues. It also ensures that any testing can be carried out in good time and by as many people as possible and therefore that the release is of sufficient quality to be useful to others. For more information read Release management in open source software projects and Best practice in release management.
How can new developers contribute code to my project?
When new developers want to get involved with your open source software project and donate code to the project they probably won’t have write access to the version control system yet which means they can’t submit the code directly to the project. Instead they can provide the code as a patch. This is a record of changes made to one or more resources that are part of the project’s software code. Someone in the project that does have write access to the code can apply the patch to the source code. In the commit message the person that contributed the code is credited as the original contributor.
Feedback and comments
One of your articles is a bit misleading - what are you going to do about it?
We try to ensure that everything on our website is accurate and non-biased but occasionally information becomes out of date and alas we are not infallible. Please email mailto:info@oss-watch.ac.uk with any corrections or qualifications.
Dịch: Lê Trung Nghĩa

Thứ Tư, 29 tháng 5, 2013

Các mô hình kinh doanh và bền vững xung quanh phần mềm tự do nguồn mở

Business and sustainability models around free and open source software
Pete Cooper, Published: 27 May 2009, Reviewed: 11 June 2012
Bài được đưa lên Internet ngày: 11/06/2012
Lời người dịch: Bài viết đưa ra nhiều vấn đề liên quan tới thế giới PMTDNM, từ các loại giấy phép khác nhau của PMTDNM, tới các mô hình kinh doanh bền vững, tới việc thương mại hóa PMTDNM, tới việc tạo ra một Quỹ (Foundation) để quản lý mã và giảm nhẹ các vấn đề hành chính liên quan và rồi ở phần kết luật, nêu: “các doanh nghiệp phần mềm lớn và thành công đang ngày càng nhìn vào dạng các mô hình 'đổi mới mở' hướng vào cộng đồng (bản dịch tiếng Việt) phản chiếu các thực tiễn truyền thống của sự tự do và cộng tác của giới hàn lâm”.
Báo cáo từ hội thảo của OSS Watch về các Mô hình Kinh doanh và Bền vững tại Đại học Oxford, 12/01/2009 của Pete Cooper.
Tôi may mắn được tham dự một sự kiện của OSS Watch gần đây. Hội thảo, các Mô hình kinh doanh và bền vững xung quanh phần mềm tự do nguồn mở, đã được tổ chức tại tổng hành dinh Oxford, nơi đặt chỗ của OSS Watch, sâu trong tòa nhà như mê lộ các Dịch vụ Điện toán của Đại học Oxforsd. Các suy nghĩ ban đầu của tôi, thậm chí trước sự kiện, hầu hết là các câu hỏi:
  • Làm thế nào có thể OSS Watch, trước hết có liên quan trong giáo dục cao học và đại học (HE/FE), tiếp cận chủ đề về các mô hình kinh doanh thương mại và vẫn còn là có thẩm quyền cơ chứ?
  • Liện quan điểm không bảo vệ của OSS Watch có bị gắn vào, đặc biệt trong các khía cạnh kinh doanh và thương mại của hội thảo?
  • Làm thế nào thứ gì đó có thể là sẵn sàng tự do một cách cơ bản không có chi phí lại có thể bền vững được? Sau tất cả, các mô hình kinh doanh thương mại, ít nhất theo nghĩa truyền thống, phần lớn dựa vào việc bán và/hoặc buôn bán một sản phẩm và/hoặc dịch vụ vì tiền và/hoặc các dịch vụ để đổi lại.
Hội thảo ở dạng của 4 bài trình bày và một phiên thảo luận, được mô tả trong báo cáo sau đây và được đề cập tới trong một blog sống động. Tất cả các diễn giả cũng đã phát hành các slide của họ cho tự do tải về, theo một giấy phép Creative Common Attribution - ShareAlike 2.0, trừ phi được chỉ định khác. Các slide là có sẵn từ trang web của hội thảo, được kết nối tới ở trên.
Những điều cơ bản về PMTDNM
Ross Gardler đã mở đầu hội thảo với một tổng quan về phần mềm tự do nguồn mở (PMTDNM). Ông đã bắt đầu bằng việc đề cập tới một số về lịch sử đằng sau 2 tổ chức PMTDNM, Quỹ Phần mềm Tự do – FSF (Free Software Foundation)Sáng kiến Nguồn Mở - OSI (Open Source Initiative), và đã đi tiếp để mô tả các dạng giấy phép PMTDNM chính: giấy phép dễ dãi cho phép đưa PMTDNM vào trong các dự án không phải là PMTDNM và hầu hết phù hợp cho các kịch bản nơi mà sự hấp thu rộng rãi nhất được yêu cầu. General Public License (LGPL) are examples of partial copyleft licences.
Các ví dụ của các giấy phép dễ dãi bao gồm Giấy phép Phần mềm Apache (Apache Software License) và giấy phép BSD được sửa đổi. Một giấy phép copyleft khác với một giấy phép dễ dãi theo đó các tác phẩm phái sinh, khi chúng được phân phối, phải kế thừa giấy phép y hệt như dự án cha của chúng, và các tác phẩm được cấp phép copyleft không thể kết hợp được vào trong các dự án không phải là PMTDNM. Một giấy phép copyleft là phù hợp cho các tình huống nơi mà tình trạng của PMTDNM sẽ được thừa nhận và/hoặc được tăng cường theo pháp lý. Giấy phép Công cộng chung GNU – GPL (GNU General Public License) là giấy phép copyleft nổi tiếng nhất.
Việc cấp phép copyleft một phần là một bản 'lai' của các giấy phép copyleft và dễ dãi. Những sự tương tự giữa việc cấp phép copyleft và một phần copyleft bao gồm sự kế thừa của giấy phép cho các tác phẩm phái sinh; tuy nhiên, tác phẩm được cấp phép copyleft một phần có thể được kết hợp trong các sản phẩm không phải là PMTDNM, theo cách tương tự tới tác phẩm được điều hành bằng một giấy phép dễ dãi. Giấy phép Công cộng Mozilla – MPL (Mozilla Public License) và giấy phép Công cộng Chung Ít hơn GNU – LGPL (GNU Lesser General Public License) là các ví dụ về các giấy phép copyleft một phần.
Ross sau đó đã chuyển qua chủ đề về quyền sở hữu bản quyền, một trong những vấn đề quan trọng nhất phải giải quyết khi thiết lập một dự án PMTDNM, và đã mô tả 2 mô hình ban đầu đang được sử dụng: quyền sở hữu tập trung và tổng hợp. Trong trường hợp quyền sở hữu tập trung, bản quyền được người chủ dự án sở hữu, và những người đóng góp chỉ định bản quyền của tác phẩm của họ cho người chủ sở hữu dự án. Quyền sở hữu tổng hợp có (những) người chủ sở hữu của dự án giữ lại bản quyền tác phẩm của họ, với những người đóng góp chỉ cấp phép mã của họ cho người chủ sở hữu dự án, thay vì chỉ định bản quyền của họ. Mô hình thứ 3, quyền sở hữu phân tán, là chung trong thế giới hàn lâm. Mô hình này tương tự như quyền sở hữu tổng hợp, ngoại trừ là những người đóng góp không cấp phép những đóng góp của họ cho người chủ sở hữu dự án; thay vào đó, họ đặt chúng theo cùng y hệt giấy phép như được dự án sử dụng, cho phép những đóng góp đó được kết hợp. Tuy nhiên, điều này có nghĩa là, người chủ sở hữu dự án sau đó không thể tái cấp phép cho dự án mà không có việc đảm bảo có thỏa thuận của từng người đóng góp; mô hình quyền sở hữu tổng hợp cho phép điều này, và vì thế được ưa thích hơn.
Cuối cùng, Ross đã nói về tầm quan trọng của việc ghi lại và truy xuất thông tinn về quyền sở hữu một cách chính xác. Trong kết luận, ông đã nhấn mạnh rằng PMTDNM không đơn giản chỉ là một tập hợp các điều khoản cấp phép phần mềm mà còn là một phương pháp luận cho sự phát triển phần mềm, và rằng các cộng đồng phát triển cộng tác được xúc tác bằng việc cấp phép là quan trọng như bản thân việc cấp phép đó.
Các mô hình kinh doanh và bền vững của PMTDNM
Tiếp theo là Rowan Wilson, người như là một Chuyên gia Nghiên cứu tại OSS Watch, tập trung vào các khía cạnh pháp lý của PMTDNM. Bài nói chuyện của ông đã bắt đầu với câu hỏi gây bực mình về việc liệu giấy phép PMTDNM có tạo thành một hợp đồng giữa lập trình viên và người sử dụng hay không. Trong khi nhiều người viện lý rằng nó phải là, để có bất kỳ hiệu ứng nào, thì các cộng đồng PMTDNM theo truyền thống đã có xu hướng hạ thấp các khía cạnh hợp đồng tiềm tàng của các giấy phép, thay vào đó viện lý rằng chúng đại diện cho sự trao đơn phương theo những hoàn cảnh đặc biệt (ví dụ, một sự trao quyền để sao chép, miễn là người sao chép giữ lại các thông tin ghi công). Ông sau đó đã đưa ra các ví dụ về những thách thức pháp lý không thành công đối với các giấy phép của PMTDNM, nổi bật là các vụ Wallace vs FSFJacobsen vs Katzer, đã chỉ ra rằng một người cấp phép PMTDNM tại Mỹ là không được tin cậy vào luật hợp đồng để ép tuân thủ các điều kiện trong giấy phép PMTDNM của họ.
Chuyển sang khai thác PMTDNM, Rowan đã giải thích rằng theo truyền thống thì các viện trường nghiên cứu của nước Anh đã dựa vào các bằng sáng chế phần mềm cho việc khai thác IP phần mềm của họ, nhưng đã cảnh báo chống lại điều này, khi tất cả các giấy phép PMTDNM, hoặc rõ ràng hoặc ẩn ý, trao các quyền cho các bằng sáng chế mà phần mềm cụ thể hóa cho bất kỳ ai trên thế giới về cơ bản không có chi phí nào. Ông cũng chỉ ra rằng việc âm thầm nhúng PMTDNM vào trong phần mềm của riêng bạn có thể là một sự cám dỗ nhưng nó thường kết thúc với sự phí tổn và sự công khai tồi.
Mô hình đầu mà Rowan đã trình bày từng là việc xây dựng của một cộng đồng hàn lâm xung quanh một giải pháp phần mềm đặc biệt, giải thích rằng 'việc sở hữu' một công cụ là nổi lên trong một lĩnh vực vấn đề đặc biệt có thể có lợi cho uy tín của viện trường và các nhà nghiên cứu hàn lâm theo yêu cầu, và khích lệ việc cấp vốn và quan hệ đối tác công nghiệp. Việc thiết lập một thực thể pháp lý riêng rẽ hoặc quỹ cũng có thể giúp nhiều với sự khai thác thành công một dự án PMTDNM. Cũng như một mô hình kinh danh làm việc được, điều này cho phép sự quyên góp và một tiếp cận đơn giản hơn về thuế. Việc tạo ra một cơ quan riêng rẽ mà giả thiết trách nhiệm pháp lý cho một dự án cũng giúp quản lý các rủi ro pháp lý cho dự án và những người có liên quan với nó: điều này cách li dự án khỏi các hành động pháp lý chống lại những người tham gia của nó, và cũng cách li những người tham gia khỏi các hành động pháp lý chống lại dự án. Có lẽ thậm chí hữu dụng hơn là một vài tổ chức ô dù của PMTDNM đang tồn tại mà bao gồm một số các dự án, cho phép các tài nguyên hành chính được gộp lại. Cuối cùng, các quỹ nguồn cộng đồng, dù chỉ có liên quan tiếp xúc với PMTDNM, đưa ra con đường khác cho giá trị gia tăng từ phần mềm, trong đó sự nhập vào cộng đồng phát triển được khẳng định trong việc tiến hành một cam kết được xác định về các tài nguyên.
Tiếp theo là sự tư vấn. chi phí thấp vốn dĩ của mua sắm PMTDNM, cùng với tài liệu thường lơ thơ của nó, có thể dẫn tới nhu cầu tư vấn và sự phát triển phần mềm được đặt hàng có liên quan. Việc gia tăng sự chấp nhận phần mềm như một dịch vụ, hoặc điện toán đám mây, cũng có thể là một dạng dòng doanh thu. Cung các các dịch vụ đó bằng việc sử dụng một số phần mềm được cấp phép copyleft không phá võ bất kỳ các điều kiện nào của giấy phép, khi mà phần mềm không được phân phối theo nghĩa truyền thống. Các dịch vụ quảng cáo và/hoặc tham chiếu cũng là nguồn doanh thu có khả năng khác.
Rowan sau đó đã đề cập tới các kỹ thuật khai thác PMTDNM truyền thống hơn - cung cấp sự hỗ trợ có trả tiền, bán các trình bổ sung (add-ons) sở hữu độc quyền và việc cấp phép đôi. Trong khi 2 cái đầu là các mô hình được hiểu tốt rồi, thì việc cấp phép đôi thường bị hiểu sai. Điều này có liên quan tới việc phát hành phần mềm của bạn theo một giấy phép copyleft mạnh như GNU GPL, và cũng làm cho sẵn sàng một phiên bản theo một giấy phép lựa chọn thay thế, cho phép những người sử dụng mà không muốn bị ràng buộc vào GNU GPL sẽ trả tiền cho phiên bản không phải copyleft đó. Thông thường, họ có thể làm điều này vì họ muốn sản xuất một sản phẩm dựa vào mã đó nhưng không bị giới hạn bằng một giấy phép copyleft.
Tóm tăt lại, Rowan đã nhấn mạnh rằng PMTDNM và phần mềm thương mại không đối đầu hoặc không phải là các khái niệm loại trừ lẫn nhau. Quan điểm này được sinh ra bởi thực tế là các thành phần và mã của PMTDNM đang ngày càng được chấp nhận như một phần của phần mềm thương mại và được dự đoán của Gartner ủng hộ rằng PMTDNM sẽ tạo thành một phần khoảng 80% các lời chào phần mềm thương mại vào năm 2012.
Thương mại hóa PMTDNM - một phép nghịch hợp?
Phiên buổi chiều đã bắt đầu với diễn giả khách ở Đại học Oxford, TS. Rhys Newman, người đã gắn cùng một số khía cạnh của các phiên buổi sáng, và đã chỉ ra cách mà PMTDNM được sinh ra trong giới hàn lâm có thể giàn được sự quan tâm của giới công nghiệp rộng lớn và lôi cuốn việc cấp vốn đầu tư rủi ro.
Rhys là bộ óc đằng sau 2 dự án đã giành giải thưởng, NereusJPC, các ứng dụng Java làm việc cùng nhau cho những người trung gian cho thời gian CPU giữa các nhà tài trợ và những người sử dụng. Bài trình bày của ông đã tập trung vào con đường đã đi qua đối với từng trong số các dự án, từ khái niệm cho tới sự phân phối. Như một phần của qui trình nghiên cứu, Rhys đã tính giá trị thời gian CPU rỗi rãi với giá 100 tỷ USD mỗi năm, mà nó, cân nhắc yêu cầu toàn cầu ngày một gia tăng đối với thời gian tính toán, đã thể hiện một cơ hội kinh doanh khổng lồ. Tuy nhiên, không có cơ sở cài đặt rộng lớn của JPC/Nereus, những người sử dụng và những người sử dụng tiềm năng có thể không bị thuyết phục về giá trị của dự án - và không có những người sử dụng ganh đua về thời gian CPU trong các máy tính được JPC/Nereus xúc tác, các nhà tài trợ có thể không bị thuyết phục để tham gia vào dự án. Vì thế, dường như là câu trả lời là để phân phối phần mềm máy trạm không lấy lại gì cả, để xây dựng một kho những người sử dụng; không được nói liệu một mô hình phân phối có giới hạn hơn, có trả tiền đã từng bao giờ được cân nhắc tới chưa. Như Rhys đã thừa nhận, làm như vậy đã không nhất thiết mở nguồn, mà đơn giản là mọi người có khả năng tải về phần mềm máy trạm một cách tự do. Theo quan điểm của ông, việc mở nguồn bổ sung vào một yếu tố marketing: ông tin tưởng rằng dạng những người 'hiểu biết kỹ thuật' có khả năng sẽ có quan tâm trong việc quản lý phần mềm có thể chỉ ra thiện chí nhiều hơn và sự quan tâm nó là nguồn mở. Lý do chính khác của ông là, nếu phần mềm là nguồn mở, thì các nhà đầu tư tiềm năng có thể ủy thác cho các phân tích phần mềm một cách độc lập nếu họ chọn làm như thế.
Ông từng tùy tiện lưu ý, dù, về bất kỳ vai trò nào đối với những đóng góp mã bên ngoài có thể có khả năng chơi trong dự án. Mục tiêu chính đơn giản là để đảm bảo sự phân phối rộng rãi nhất của phần mềm, khi doanh số để cấp vốn cho dự án tiếp tục có thể cuối cùng phụ thuộc vào sự tồn tại của kho người sử dụng. Một khi những người sử dụng đã bị thuyết phục và trung thành với lý do, thì sự đầu tư có thể được tìm thấy. Tuân theo sự đầu tư thành công, sản phẩm có thể sẽ thân thiện hơn với các tập đoàn và các tổ chức có thể có thiện chí hơn để thử nó.
Một trong những thách thức lớn nhất của Rhys là việc thuyết phục Đại học mà về cơ bản 'trao đi' phần mềm có thể mang về thứ gì đó để đổi lại. Lý lẽ của ông không phải là 'việc bỏ nó đi' có thể mang gì đó ngược trở về, mà việc không phát hành như nguồn mở có thể đảm bảo rằng không có tiền nào có thể bao giờ đó sẽ tới. Đơn vị chuyển giao công nghệ của Đại học Oxford, ISIS Innovation, từng mở cho khái niệm này và đã phê chuẩn sự phát hành. JPC và Nereus đã được tung ra vào năm 2007 và 2008 một cách tương ứng, cả 2 đều theo giấy phép GPLv2, và công nghệ đằng sau phần mềm từng được cấp phép thương mại vào tháng 12/2008.
Kết luận, Rhys đã thể hiện quan điểm rằng tương lai của phần mềm là tất cả về việc lấy tiền dòng xuôi: có các khách hàng đi tới các lập trình viên, muốn trả tiền cho giá trị mà họ có thể đã thấy rồi, tránh những khuyến khích ăn cắp vốn dĩ với các bản sao số có lấy tiền. Ông đã khuyên các đại biểu 'yêu cầu không phải là liệu có mở nguồn, mà hỏi liệu có KHÔNG mở nguồn' và để xem sự phát triển của điện toán đám mây, nói rằng nó 'sẽ trở thành tiêu chuẩn'.
Quản lý một quỹ có chứa mã của bạn
David Wood, từ Symbian Ltd, đã trình bày cuối cùng, đã mô tả thông tin về Quỹ Symbian (Symbian Foundation), một tay chơi chính trong thị trường điện thoại thông minh. Tập trung trước hết vào phía kinh doanh vận hành, ông đã mô tả như là các cơ hội di động 'khổng lồ' sẵn sàng cho Symbian. Tuy nhiên, có những thách thức phải vượt qua, bao gồm cả những hạn chế vật lý của kích cỡ màn hình và vòng đời của pin, cùng với những vấn đề tương tác với người sử dụng như sự phức tạp của các ứng dụng và chức năng không được làm để truy cập dễ dàng. Việc đáp ứng được các thách thức đó đòi hỏi đầu vào của nhiều lập trình viên, cùng với thiện chí ôm lấy một cộng đồng nguồn mở và một hệ sinh thái phù hợp.
Nhìn lại, David đã mô tả con đường của Symbian hướng tới việc ôm lấy nguồn mở. Một bước chính từng là áp dụng môi trường phát triển được tích hợp - IDE (Integrated Development Environment) Eclipse, cuối cùng nó đã dẫn tới sự tạo ra họ các IDE Carbide vào năm 2005. Symbian bây giờ là một thành viên của Quỹ Eclipse (Eclipse Foundation) và đã đóng góp thời gian và phần mềm của các lập trình viên vào một số dự án.
Symbian Ltd đã phát hành hệ điều hành Symbian như PMNM theo quyền sở hữu của Quỹ Symbian. Nó đã chọn giấy phép Eclipse Public License (EPL) để bao trùm phát tán nguồn mở cuối cùng cho mã của nó, để giảm sự phân mảnh phần mềm - sự phân mảnh ở đây tham chiếu tới số lượng lớn các hệ điều hành khác nhau trong thị trường thiết bị di động. David đã nói ra những vấn đề có liên quan tới tình trạng hỗn loạn này và đã giải thích cách mà sự dịch chuyển của Symbian trong nguồn mở có thể giúp được.
Trước hết, ông đã chỉ ra rằng sự phân mảnh có thể có những hậu quả khó chịu cực kỳ, thậm chí dù nó cũng có thể đôi khi dường như có lợi. 'Khả năng rẽ nhánh' (thực tế của việc sản xuất các phiên bản phần mềm song song khác nhau) là, theo nhận thực của công chúng, hầu hết thường có liên quan tới PMTDNM, thậm chí sản xuất bên trong dự án đóng cho tới bây giờ như Symbian, các nhà sản xuất thiết bị khác nhau có thể thường sản xuất các bản 'rẽ nhánh' nội bộ mã của nền tảng đó để làm việc với các vấn đề của riêng họ và không đóng góp chúng trở ngược lại cho dự án trung ương. Trong khi điều này đã giúp họ giải quyết các vấn đề ngắn hạn một cách nhanh chóng, về lâu dài nó sản xuất ra các phiên bản mới của hệ điều hành mà đã giải quyết được các nhu cầu của tất cả các nhà sản xuất thiết bị khó khăn hơn. Nói chung, việc cấp phép PMTDNM làm cho dạng này của sự phân mảnh dễ dàng hơn. Ở mức độ nào đó, sử dụng các giấy phép 'copyleft' có thể giúp giảm nhẹ chống lại rủi ro này.
Nền tảng của Quỹ Symbian hiện đang đi qua giai đoạn chứng minh, cuối cùng nhằm vào một phát hành tuân thủ đầy đủ EPL vào tháng 06/2010. Trong lúc chờ đợi, Quỹ đang vận hành như một dự án 'nguồn cộng đồng', với một giấy phép chỉ mở rộng cho các thành viên của dự án, những người trả phí để tham gia vào Quỹ.
Trong phần kết luận, David nhắc lại các nguyên tắc được đưa ra trong các phiên trước, nhấn mạnh tầm quan trọng của chế độ người tài lãnh đạo trong một dự án PMTDNM, vượt qua và trên cả những đóng góp tài chính, và nhấn mạnh rằng sự minh bạch sẽ mở rộng các qui trình của dự án cũng như mã.
Thảo luận phiên chuyên đề
David Wood cùng với Rhys Newman, Rowan Wilson và Steve Lee, một chuyên gia về khả năng truy cập trong PMTDNM, có trong một thảo luận phiên chuyên đề. Một đại biểu đã hỏi một câu cũ quen thuộc: 'Liệu mã nguồn mở có là một rủi ro về an ninh?' Câu trả lời của Rhys đã nêu đặc trưng phát hành nguồn mở như một tuyên bố về sự tin cậy của các tác giả trong an inh mã của họ, trong khi Steve đã chỉ ra rằng nhiều dự án PMTDNM là tích cực và lanh lẹ trong việc đáp trả của chúng đối với các vấn đề, nên có thể được sửa nhanh chóng. David đã trả lời với một câu chuyện cười về một vấn đề an ninh gần đây của Symbian, và tự hỏi to liệu đi trên con đường PMTDNM nghĩa là nhiều hơn hay ít hơn các sự cố như vậy hay không. Một đại biểu đã trả lời cho câu hỏi đó bằng việc nêu ví dụ về sử dụng của Cơ quan An ninh Quốc gia Mỹ một Linux được tùy biến thích nghi như là nền tảng điện toán an ninh của họ.
Cuộc thảo luận sống động tiếp tục, khi hội thảo đi tới lúc kết thúc. Trong số những câu hỏi còn lại là liệu các nhà đầu tư rủi ro có cần được giáo dục về đánh giá của họ về khả năng khai thác phần mềm, tập trung đặc biệt vào tiêu dùng mà chỉ một bằng sáng chế phần mềm cũng có thể đảm bảo rằng phần mềm đó được khai thác có lợi nhuận hay không.
Kết luận
Phán quyết: về tổng thể, một hội thảo vững chắc với nhiều đồ ăn cho suy nghĩ. Trong khi khu vực giáo dục thường nghĩ sẽ bị cách li khỏi tính nghiêm ngặt của thế giới kinh doanh, thì các trình bày của OSS Watch và những người khách của họ dường như chỉ ra khác. Chuyến đi của Ross và Rowan qua các mô hình kinh doanh và bền vững phù hợp của PMTDNM đã chỉ ra rằng có một phổ các cơ hội sẵn sàng cho các tác giả phần mềm hàn lâm, trải từ sự tạo ra các cộng đồng hàn lâm mới cho tới sự tạo ra [các thực thể mới] và thương mại hóa đầy đủ. OSS Watch có thể giúp nhận diện đâu là nơi mà các mô hình khai thác có liên quan tới PMTDNM là phù hợp, và đâu là nơi mà chúng có thể không phù hợp. Rhys Newman đã minh họa một con đường hợp lý cho một mẩu phần mềm từ công cụ hàn lâm tới tập trung vào lợi ích thương mại. David Wood đã chỉ ra cho chúng ta rằng, từ phía khác của hàng rào, các doanh nghiệp phần mềm lớn và thành công đang ngày càng nhìn vào dạng các mô hình 'đổi mới mở' hướng vào cộng đồng (bản dịch tiếng Việt) phản chiếu các thực tiễn truyền thống của sự tự do và cộng tác của giới hàn lâm.
A report from the OSS Watch Business and Sustainability Models workshop at the University of Oxford, 12 January 2009, by Pete Cooper.
I was fortunate enough to attend a sold-out OSS Watch event recently. The workshop, Business and Sustainability Models Around Free and Open Source Software, was held at OSS Watch’s central Oxford headquarters, deep in the maze-like Oxford University Computing Services building. My first thoughts, even before the event, were mostly questions:
  • How would OSS Watch, primarily involved in HE and FE, approach the subject of commercial business models and still be authoritative?
  • Would the non-advocacy stance taken by OSS Watch be adhered to, especially on the business and commercial aspects of the workshop?
  • How can something that’s essentially freely available at no cost be sustainable? After all, commercial business models, at least in the traditional sense, largely rely on selling and/or trading a product and/or service for money and/or services in return.
The workshop took the form of four presentations and a panel discussion, described in the following report and covered in a live blog. All presenters have also released their slides for free download, under a Creative Commons Attribution-ShareAlike 2.0 licence, unless otherwise indicated. The slides are available from the workshop’s web page, linked to above.
The fundamentals of FOSS
Ross Gardler opened the workshop with an overview of FOSS. He began by covering some of the history behind the two key FOSS organisations, the Free Software Foundation (FSF) and the Open Source Initiative, and went on to describe the main types of FOSS licence: a permissive licence allows inclusion of FOSS in non-FOSS projects and is most suited to scenarios where the widest uptake is required. Examples of permissive licences include the Apache Software License and Modified BSD. A copyleft licence differs from a permissive licence in that derivative works, should they be distributed, must inherit the same licence as their parent project, and copyleft-licensed works cannot be incorporated into non-FOSS products. A copyleft licence is suitable for situations where FOSS status is to be recognised and/or legally enforced. The GNU General Public License is the best-known copyleft licence.
Partial copyleft licensing is a ‘hybrid’ of copyleft and permissive licenses. The similarities between copyleft and partial copyleft licensing include the inheritance of licence for distributed derivative works; however, partial copyleft-licensed work can be incorporated into non-FOSS products, in a similar way to work governed by a permissive licence. The Mozilla Public License and GNU Lesser General Public License (LGPL) are examples of partial copyleft licences.
Ross then turned to the subject of copyright ownership, one of the most important issues to address when setting up a FOSS project, and described the two primary models in use: centralised and aggregated ownership. In the case of centralised ownership, copyright is owned by the project owner, and contributors assign copyright of their work to the project owner. Aggregated ownership has the project owner(s) retaining copyright of their work, with contributors only licensing their code to the project owner, rather than assigning their copyright. A third model, distributed ownership, is common in the academic world. This model is similar to aggregated ownership, except that contributors do not license their contributions to the project owner; rather, they place them under the same licence as used by the project, allowing them to be incorporated. This means, however, that the project owner cannot then re-licence the project without securing the agreement of every contributor; the aggregated ownership model does allow this, and is therefore preferred.
Finally, Ross talked about the importance of recording and retrieving ownership information accurately. In conclusion, he stressed that FOSS is not simply a set of software licensing terms but also a methodology for software development, and that the collaborative development communities enabled by the licensing are as important as the licensing itself.
FOSS business and sustainability models
Next up was Rowan Wilson who, as a Research Officer at OSS Watch, focuses on the legal aspects of FOSS. His talk began with the vexed question of whether a FOSS licence constitutes a contract between the developer and the user. While many argue that it must, in order to have any effect, traditionally FOSS communities have tended to downplay the potential contractual aspects of the licences, instead arguing that they represent unilateral grants under specific circumstances (for example, a grant of the right to copy, provided that the copier preserves attribution information). He then gave examples of unsuccessful legal challenges to FOSS licences, notably Wallace vs FSF and Jacobsen vs Katzer, which showed that a FOSS licensor in the US is not reliant on contract law to enforce the conditions in their FOSS licence.
Moving on to the exploitation of FOSS, Rowan explained that traditionally UK research institutions have relied upon software patents for exploiting their software IP, but warned against this, as all FOSS licences, either explicitly or implicitly, grant rights to patents that the software embodies to anyone in the world at essentially no cost. He also pointed out that silently engulfing FOSS within your own software can be a temptation but that it frequently ends in expense and bad publicity.
The first model Rowan presented was the building of an academic community around a particular software solution, explaining that ‘owning’ a tool that is prominent in a particular problem domain can benefit the reputation of the institution and academics in question, and foster funding and industrial partnerships. Establishing a separate legal entity or foundation can also help greatly with successful exploitation of a FOSS project. As well as being a workable business model, this allows donations and a simpler approach to tax. Creating a separate body that assumes legal responsibility for a project also helps manage legal risks to the project and those associated with it: this insulates the project from legal actions against its participants, and also insulates participants from legal actions against the project. Perhaps even more useful are the several FOSS umbrella organisations in existence that contain a number of projects, allowing administrative resources to be pooled. Finally, community source foundations, although only tangentially related to FOSS, provide another route to added value from software, wherein admission to the development community is predicated on making a defined commitment of resources.
Next up was consultancy. The inherent low cost of acquisition of FOSS, along with its often sparse documentation, can drive demand for consultancy and associated bespoke software development. The increasing acceptance of software as a service, or cloud computing, can also be a form of revenue stream. Provision of these services using some copyleft-licensed software does not break any licence conditions, as the software is not distributed in the traditional sense. Advertising and/or referral services are yet another possible source of income.
Rowan then covered the more traditional FOSS exploitation techniques - provision of paid support, selling proprietary add-ons and dual licensing. While the first two are well-understood models, dual licensing is often misunderstood. This involves releasing your software under a strong copyleft licence such as the GNU GPL, and also making available a version under an alternative licence, allowing users who do not wish to be bound by the GNU GPL to pay for the non-copyleft version. Generally, they would do this because they wish to produce a product based on the code but not confined by a copyleft licence.
Summing up, Rowan emphasised that FOSS and commercial software are not antagonistic or mutually exclusive concepts. This view is borne out by the fact that FOSS components and code are being increasingly accepted as part of commercial software and echoed by Gartner’s prediction that FOSS will form part of 80 per cent of commercial software offerings by 2012.
Commercialising FOSS - an oxymoron?
The afternoon session kicked off with Oxford University-based guest speaker, Dr Rhys Newman, who tied together a number of aspects of the morning sessions, and showed how FOSS generated in academia can gain wide industry interest and attract venture capital funding.
Rhys is the brains behind two award-winning projects, Nereus and JPC, Java applications that work together to broker CPU time between donors and users. His presentation focussed on the journey undergone by each of the projects, from concept to delivery. As part of the research process, Rhys had calculated the value of idle CPU time at $100 billion per year, which, considering the increasing global requirement for computing time, represented a massive business opportunity. However, without a large install base of JPC/Nereus, users and potential users would not be convinced of project value - and without users vying for CPU time on JPC/Nereus-enabled computers, donors would not be convinced about joining the project. It seems, therefore, that the answer was to distribute the client software for nothing, in order to build up a user base; it was not stated whether a more limited, paid-for distribution model was ever considered. As Rhys acknowledged, doing so did not necessitate open sourcing, but simply that people be able to download the client for free. In his view, open sourcing adds a marketing element: he believes that the sort of ‘technically aware’ people likely to be interested in running the software would show more goodwill and interest were it open source. His other main reason is that, were the software open source, potential investors could commission independent analyses of the software if they chose to do so.
He was notably dismissive, though, of any role external code contributions would be likely to play in the project. The main goal was simply to ensure the software’s widest distribution, as revenue to fund the project further would ultimately depend on the existence of the user base. Once users had been persuaded and were loyal to the cause, investment would be sought. Following successful investment, the product would be more corporate friendly and organisations would be more willing to trial it.
One of Rhys’s biggest challenges was persuading the University that essentially ‘giving away’ the software would bring back something in return. His argument was not that ‘giving it away’ might bring something back, but that not releasing as open source would ensure that no money would ever come in. The technology transfer unit of Oxford University, ISIS Innovation, was open to this concept and approved the release. JPC and Nereus were launched in 2007 and 2008 respectively, both under GPL v2 licences, and the technology behind the software was licensed commercially in December 2008.
Concluding, Rhys expressed the view that the future of software is all about downstream charging: having customers coming to developers, wanting to pay for value they can already see, avoids the inherent piracy incentives with chargeable digital copies. He advised delegates to ‘ask not whether to open source, ask whether NOT to open source’ and to watch the development of cloud computing, stating that it ‘will become the standard’.
Running a foundation to contain your code
David Wood, of Symbian Ltd, delivered the final presentation, which described the formation of the Symbian Foundation, a major player in the smartphone market. Concentrating at first on the business side of the operation, he described as ‘huge’ the mobile opportunities available to Symbian. However, there are challenges to overcome, including the physical limitations of screen size and battery life, along with such user-interaction issues as complexity of applications and functionality not made easily accessible. Meeting these challenges requires the input of many developers, along with a willingness to embrace an appropriate open source community and ecosystem.
Looking back, David described Symbian’s journey towards embracing open source. A key step was the adoption of the Eclipse integrated development environment (IDE), which ultimately led to the creation of the Carbide family of IDEs in 2005. Symbian is now a member of the Eclipse Foundation and has contributed developer time and software to a number of projects.
Symbian Ltd released the Symbian operating system as open source software under the ownership of the Symbian Foundation. It selected the Eclipse Public License (EPL) to cover the eventual open source distribution of its code, in order to reduce software fragmentation - fragmentation here referring to the large number of differing operating systems within the mobile device market. David spelled out the problems associated with this chaotic situation and explained how Symbian’s move into open source might help.
Firstly, he pointed out that fragmentation can have extremely unpleasant consequences, even though it may also sometimes seem beneficial. ‘Forkability’ (the practice of producing differing parallel versions of software) is, in the public perception, most commonly associated with FOSS, yet even within an up-to-now closed project like Symbian, different device manufacturers would often produce internal ‘forks’ of the platform code to deal with their own problems and not contribute these back to the central project. While this helped them solve short-term issues quickly, in the long run it made producing new versions of the operating system that addressed the needs of all device manufacturers more difficult. In general, FOSS licensing makes this kind of fragmentation easier. To an extent, the use of ‘copyleft’ licences can help to mitigate against this risk.
The Symbian Foundation platform is currently going through a proving time, ultimately aiming for a fully EPL-compliant release in June 2010. In the interim, the Foundation is operating as a ‘community source’ project, with a licence that extends only to project members who pay a fee to join the Foundation.
In conclusion, David reiterated the principles outlined in the previous sessions, stressing the importance of meritocracy in a FOSS project, over and above financial contributions, and emphasising that transparency should extend to project processes as well as code.
Panel discussion
David Wood was joined by Rhys Newman, Rowan Wilson and Steve Lee, an expert in accessibility within FOSS, for a panel discussion. One delegate asked an old favourite: ‘Is open source code a security risk?’ Rhys’s reply characterised open source release as a statement of confidence by the authors in the security of their code, while Steve pointed out that many FOSS projects are active and agile in their response to issues, so can be fixed quickly. David replied with an anecdote about a recent Symbian security issue, and wondered aloud if going the FOSS route would mean more or fewer such incidents. A delegate responded to the question by citing the example of the US National Security Agency’s use of an adapted Linux as their secure computing platform.
Lively discussion continued, as the workshop drew to a close. Among the remaining questions was whether venture capitalists needed to be educated on their assessment of software exploitability, concentrating particularly on the assumption that only a software patent could guarantee that software was profitably exploitable.
Conclusion
The verdict: overall, a solid workshop with plenty of food for thought. While the education sector is often thought to be isolated from the rigours of the world of business, OSS Watch’s presentations and those of their guests seemed to indicate otherwise. Ross and Rowan’s tour through the relevant FOSS business and sustainability models showed that there is a spectrum of opportunities available to academic software authors, ranging from creation of new academic communities to full spin-out and commercialisation. OSS Watch can help to identify where FOSS-related exploitation models are appropriate, and where they may not be. Rhys Newman exemplified a reasoned path for a piece of software from academic tool to focus of commercial interest. David Wood showed us that, from the other side of the fence, large and successful software businesses are increasingly looking to the kind of community-focused ‘open innovation’ models that mirror traditional practices of academic freedom and collaboration.
Dịch: Lê Trung Nghĩa