KendraBaseLicenseRequirements

To get a feel for what's going on read [Which software license? A way forward...].

Requirements

Note:

• In this section please make no references to real or imaged open source licenses by name. It's crucial that we stick purely to conceptual requirements.
• If you want to modify a "requirement" then inform the people that have already signed up to it after doing so on the kDev list or perhaps the best thing to do is in the Summary say "Modified: Protect from being sued." for instance and people will just have to keep looking at RecentChanges - actually DO BOTH.
• Only modify a requirement if you agree with it in principle but think you can add clarity.
• Don't go deleting requirements - that's an obvious one, eh?
• Bear in mind that we may data munge all this at some point into KendraBase so please keep to the suggested format. If something is ambiguous then ask on kDev.
• I'm making this all up so if you have any better ideas about how to do structured design then do say on kDev -- DanielHarris

Template - with descriptions:

• Short: A short description of the requirement. A matter of a few words. One line only
• Long: A long description of the requirement. Go into as much detail as you need. May be multiple lines.
• Why: The reasoning behind why such a requirement is good for the project. May be multiple lines.
• People: Add your name to this if you wrote the initial requirement or if you want to say that you agree with the requirement and that you think it should be prioritised. May be multiple lines.

Template - blank:

• Short:
• Long:
• Why:
• People:

Requirements - put them below this:

• Short: Protect from being sued.
• Long: Protect the developers and copyright owners from being sued for negligence in terms of creating code that doesn't work perfectly.
• Why: We need to show that developers will be protected otherwise they may be put off coding for the project.
• People: DanielHarris

• Short: Minimise hindrances to code incorporation.
• Long: Minimise hindrances and barriers to other software developers (commercial and non-commercial, free open source and proprietary) to incorporate our code into their projects.
• Long: Need to encourage people to use our code and concepts and data exchange interfaces no matter what their motivations.
• Why: The more people can use or code easily the more that will.
• People: DanielHarris

• Short: Maximize interoperability, in terms of data and code.
• Long: An entity with a Kendra deployment should be able to fully interoperate with any other, if they so choose. One deployment should be able to use any implementation of certain features - say the data store, or the interface - without this precluding the use of another implementation in addition. So I should be able to say "Yes, I want this proprietory datastore from Foo Software", without this meaning I then cannot choose to obtain an interface from another source. I believe this is a higher priority for some areas that the above "Minimise hindrances to code incorporation", and neccessitates using a recursive license for core code.
• Why: The more entities are able to compete, the better the net result for those deploying or accessing the system. Thus we should strive to prevent problems with interoperability.
• People: DaveCridland

• Short: Legal protection / limited warranty.
• Long: This is a feature of every license deployed, whether open source or proprietary. As such, I don't feel it warrants further discussion, important as it is. I feel it would be extremely difficult to write or find a license without it.
• Why:
• Source: http://www.kendra.org.uk/lists/archive/k-developers/msg00262.html
• People: DaveCridland

• Short: Maintain copyright of contributors, maintain notice of authorship
• Long: This is a feature of every license deployed, whether open source or proprietary. As such, I don't feel it warrants further discussion, important as it is. I feel it would be extremely difficult to write or find a license without it.
• Why:
• Source: http://www.kendra.org.uk/lists/archive/k-developers/msg00262.html
• People: DaveCridland

• Short: Commercial exploitation, without enforcing a particular license choice.
• Long: I think this is what Daniel means by his second point on the Wiki, but I have endeavoured to find a phrasing which actually explains the rationale, rather than use the rationale to find an artificial requirement.
• Why:
• Source: http://www.kendra.org.uk/lists/archive/k-developers/msg00262.html
• People: DaveCridland

• Short: Interoperability of data
• Long: In other words, two distinct deployments of 'Kendra' should be able to exchange data as they choose. Without this, I feel we're undermining the entire purpose of the project. This is also stated in Daniel's second requirement, to a degree.
• Why:
• Source: http://www.kendra.org.uk/lists/archive/k-developers/msg00262.html
• People: DaveCridland

• Short: Avoid vendor lock-in
• Long: Code from one ISV, be that in source or binary form, should be usable in any deployment of 'Kendra'. This restricts the possibility of an ISV controlling 'Kendra' by producing a useful module that prevents other ISVs from competing in other areas - in other words, it reduces the potential scope of a vendor lock-in.
• Why:
• Source: http://www.kendra.org.uk/lists/archive/k-developers/msg00262.html
• People: DaveCridland

• Short:
• Long:
• Why:
• Source:
• People: