Differences between revisions 16 and 17

JISC Projects FAQ

This FAQ has been largely superceded by the main OSS Watch FAQ.

This document contains questions commonly asked by JISC projects. Like all FAQs it is never complete. If you would like to ask any other question or would like clarification on any of these answers please contact us.

Contents:

Contents

Introduction
Frequently Asked Questions (FAQs)
References

1. Introduction

These questions are an attempt to answer questions raised by projects funded by the JISC. They may or may not be relevant to other people and projects; we hope they are.

2. Frequently Asked Questions (FAQs)

2.1. Who are OSS Watch?

OSS Watch are 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:

* authoring and publishing information about open source * consultancy services for those considering, adopting or producing open source software * assistance with the evaluation of open source software in procurement * advising on community development, business models and sustainability of open source software * provide speakers for events * organise events

For more infomration see About us on the OSS Watch web site.

2.2. 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."

2.3. What is Open Development?

Open Development is an emerging term used to describe the community led development model found within many succesfull 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 whilst a clear governance model is definded to ensure the project does not decend 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.

2.4. Do OSS Watch give legal advice?

No. OSS Watch does not give legal advice and employs no lawyers. If you believe you need legal advice you should contact your university legal team (if the question relates to your project) or get yourself a lawyer (if the question relates to you personally). JISCLegal may also be useful to you http://www.jisclegal.ac.uk/ .

2.5. Who owns the copyright of the code produced during to project?

Typically, copyright belongs to the creator(s) of the code. However, depending on your terms of employment, code that is created during the course of employment usually belongs to your employer. This is fairly common at UK universities and colleges. Contractors (as opposed to employees) own copyright on their code by default. However, many such commissions will require (in the contract) that the copyright is re-assigned or jointly held.

Licensing the code under a licence (open source or otherwise) does not change who owns the copyright, but often makes it less relevant. Only the copyright owner can choose to release the code under a particular licence.

2.6. My project has lots of personal information in it, do I have to release this under an open source licence?

Almost certainly not. Generally software is released with only enough associated data for automated testing. This data is generally "dummy data" rather than real data. There are huge complications in distributing personal information, due to various data privacy laws world-wide, so the inclusion of personal information is best avoided.

If your project is generating personal information as deliverables in the project, see What licence should we use for non-software deliverables? above.

2.7. What kinds of deviations from open source are acceptable?

The JISC Open Source Policy says: Copyright of software, documentation, design materials, manuals, user interface and source code must be released under an OSI-approved open source licence [11], unless the bid explicitly argues why this should not be the case and proposes an alternative licence. The kinds of arguments that were envisioned when writing this clause include:

Migration tools: In order to migrate existing data (and thus institutions) from a closed propriety system, it may be necessary to write a plugin or module as part of that system.
Interoperability tools: In order for existing closed propriety systems to interoperate using open standards, it may be necessary to write a plugin or module as part of that system.

Such plugins and modules often require commingling of intellectual property or other licensing challenges. It was envisioned that these would be one-off arguments, and not open the door to on-going expenditure. In both cases the http://www.hefce.ac.uk/|HEFCE requirement that deliverables be freely available to all UK Higher and Further education still apply.

2.8. What kinds of deviations from open standards are acceptable?

The JISC Open Source Policy says: Documentation, graphics, sound, data and other files must, wherever possible and practicable, use open standards. There are clearly some situations in which open standards cannot be used, including:

When there is no established open standard for a particular content type
During the process of developing or establishing an open standard for a particular content type
When testing the interoperability or compatibility of standards

When deliverables or outputs are targeting communities where proprietary or non-open standards are the norm, several versions of a particular item of content may be generated, one using open standards and one using proprietary or non-open standards.

2.9. Should we Trademark the name of the project?

If you intend your project to have an life independent of the current funded or are considering launching a commercial spinout, start-up or service, trademarking is a sensible option. Trademarking can protect your name and logo in a competitive marketplace. See our TradeMark document for more information.

2.10. How should we archive our project's work and outputs?

Archiving of outputs depends on the type of the output. Ideally textual outputs (i.e documents) should be placed where they can be located by third party tools such as Google and Internet Archive. Generally simply formatted content is more accessible to using these tools than content in complex or propriety formats, i.e. HTML is easier than Word or PDF files.

Source code should archived in a version control system. Small teams with substantial IT resources may choose to go with third party systems such as Google Code or SourceForge. TODO

2.11. What kind of testing should we be using?

Testing needs to be appropriate to the project.

TODO

2.12. Do we have to host our own servers?

If you have in-house expertise and a robust fast internet connection, there is no reason why you should not host your own servers to host the project website, version control, demonstrator, etc. If, however, you prefer to have someone else to do these, there are a number of options available:

Google Code
SourceForge
Debian
Apache
S

TODO

A: If hosting your own servers is difficult or impractical, sourceforge and other third-party hosters allow you to host all the necessarily material.

3. References

-- StuartYeates 2006-12-07 13:59:17

-Deletions are marked like this.
+Additions are marked like this.
 Line 4:
+'''This FAQ has been largely superceded by the main [http://www.oss-watch.ac.uk/about/faq.xml OSS Watch FAQ].'''
-Line 33:
+Line 35:
-For OSS Watch open source software is software that has been released under an [gttp://www.opensource.org 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.
+For OSS Watch open source software is software that has been released under an [http://www.opensource.org 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.
-Line 52:
+Line 54:
-=== 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. Anything else would require a separation of the old code and the new.



Many projects are part of (or plan to be a part of) a larger community of projects, such as the [http://www.apache.org/foundation/ Apache Software Foundation], [http://savannah.gnu.org/ Free Software Foundation], [http://www.debian.org/ Debian], [https://launchpad.net/ Ubuntu], [http://sourceforge.net/ SourceForge] and [http://code.google.com/ Google Code], many of these limit the licensing choice available. Get to know the community you with which you wish to integrate your project.



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 commercial incorporation of the code should be chosen. Examples include the BSD and Apache licences.



If there is a tension licences, projects make choose to licence their code under multiple licences, a practise called [http://www.oss-watch.ac.uk/resources/duallicence2.xml dual licencing]. Projects such as the Mozilla Project use dual licensing to resolve licensing tensions.



=== 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 licence them separately.



If, however, there are non-software deliverables that are likely to be independently reusable or redistributable, it makes sense to consider licensing them separately. The [http://creativecommons.org/ Creative Commons] licences are probably the most widely used licence for content. OSS Watch has [http://www.oss-watch.ac.uk/resources/relicensing.xml documented] the process that led to our use of the Creative Commons (we previously used the [http://www.gnu.org/copyleft/fdl.html Gnu Free Documentation License]).