search

soiltechproject / fsm-docs

https://www.soiltechproject.org/
3 stars 0 forks source link

[Discussion] LICENSE #1

Open KipCrossing opened 4 years ago

KipCrossing commented 4 years ago

We've established that this project SHOULD be an open-source project and therefore we must choose a license. The next question is, what type of license should we use?

This thread is here to document a discussion on what license we choose based on the criterion set out by the soiltech project.

KipCrossing commented 4 years ago

I have HOW_TO_LICENSE guide here that can be used to help guide discussions:

https://github.com/KipCrossing/my-wikis/blob/master/HOW_TO_LICENSE.md

KipCrossing commented 4 years ago

Reasons behind choosing a LICENSE

From Point 1, the primary reason for going open source is to Ensure Uptake, the second of the Three key goals of the Soiltech Project.

The secondary reasons may include Gain Farmers Trust and Create a Community, however, these SHOULD NOT take away from the primary reason.

From Point 2

The soiltech project has defined bad actors as anyone who:

These are defined as the following:

Three Key Goals

  1. Translate soil science into digital soil management tools for farmers.
  2. Ensure uptake of the tools, and drive changed management practice, amongst land managers to improve soil condition.
  3. Observe and document the process over the life of the project, so that the process can be replicated

National Interest Test

  1. The code SHOULD NOT be able to be used by foreign industries to gain a competitive advantage over the Australian industries
  2. The soiltech project MUST NOT bring halm to Australian organisations
  3. Benefits SHOULD flow to Australian industries
  4. The soiltech project MUST be maintained within Australia by Australians

Farm Data Code Compliance

See the Farm Data Code

  1. The soiltech tools MUST NOT include any telemetry that sends private data to third parties and can demonstrate it
  2. Usage of the soiltech tools SHOULD be done in compliance with the Farm Data Code
  3. The soiltech project MUST NOT promote or endorse ‘Code Users’ that do not comply with the Farm Data Code

The challenge is to choose a license + strategy that satisfy the above reasons while deterring "bad actors".

KipCrossing commented 4 years ago

A useful next step is to choose a category that

Strong-copyleft: Such as: GPL, Eclipse

Usage of this code requires you to open-source your project under the same license

Weak-copyleft: Such as: LGPL, Mozilla Public Licence 2.0

Usage of this code requires you to open-source your project under the same license only IF modifications have been made to the original source code.

Permissive: Such as: MIT, Apache 2.0

Free to use/modify.

KipCrossing commented 4 years ago

The LGPL strategy

From tldrlegal.com:

This license is mainly applied to libraries. You may copy, distribute and modify the software provided that modifications are described and licensed for free under LGPL. Derivatives works (including modifications or anything statically linked to the library) can only be redistributed under LGPL, but applications that use the library don't have to be.

The main reason to use a weak-copyleft license is to satisfy point 3 of the National Interest Test. That improvements to the code (say from a large USA company) may flow back into Australia; as modifications MUST be published. This means that Australian companies (such as FarmLab) may benefit from these modifications.

The other reason to use an LGPL license is that it would allow us to identify modified forks that don't align with the soiltech project so that we could request the removal of any soiltech trademarks.

Further, the license allows for additional clauses and it is common to put some of the Apache 2.0 warranty disclaimers in. Many contributors in Australia prefer the Apache 2.0 license as it has a more robust warranty disclaimer and covers loss of revenue or profits.

If we were to go with a permissive license, I would recommend going with an Apache 2.0 licence because of the above reason.

From this study [Section 6.2]

Australian courts will give an exclusion clause its natural and ordinary meaning but, if there is any ambiguity, it will be construed against the person seeking to rely on the clause ... If liability for negligence is not expressly excluded, the courts may read down the exclusion clause so that liability for negligence is not excluded. It is best therefore to specifically exclude liability for negligence. There is a real risk that the GNU General Public License does not exclude liability for negligence of the licensor.

Samuel22 commented 4 years ago

Hi Team -

I’ve been thinking about the challenges around open source licensing this morning and I don’t think we necessarily need to tie the tools to a single license. An idea might be to use two different licenses, one for a ‘collection’ of the tools, and the other for ‘individual’ tools themselves. As follows:

  1. A license for the collection of tools together. This is the main code that serves up the full suite of Soil Tech tools (from sampling to mapping) and their value and the licence can be geared towards supporting the ongoing development of these tools for soil management.
  2. A more commercial friendly license for the ‘raw’ tools by themselves. These raw tools are just the plain old code converted from R, not packaged into anything but they can be picked up and used independently to do anything (even purposes outside of soil). This would allow Agtech companies to ‘pick and choose’ tools they may want to use and make them their own, without being tied to the original code and having to provide a feedback loop into them.