Develop 4 proposals for licensing moving forward, with a SWOTish (pro/con) analysis

[dcwalk]

This emerged from our 2018-Feb-19 Roundtable "Licensing of Data Together libraries (CDXJ & WARC packages)" <--notes in the link!

• @b5 TODO Develop draft proposals for licensing moving forward, with a SWOTish (pro/con) analysis, editable draft: https://docs.google.com/document/d/14tIA9ByCfVy6sEr5k5q82hA74qc0tx4hR1Qlnl0kYLc/edit
  • Change nothing (everything GPL)
  • Relicense all Data Together packages (~2/3) as MIT
  • WARC and CDXJ moved to qri.io, relicensed at MIT there
  • Have Everything GPL and make a really clear spec, use it as a basis for hosting discussions (see Eclipse as an example)
• @b5 ask for additional feedback from people
• discuss at roundtable
• agree (and document) on a decision at Coordinating Call (MAY)

[b5]

These options only apply to packages. For the list of packages in question, see here. This contrasts with services, a list of which are available here. There are roughly 7 services and 10 packages at the momemnt. Packages are much smaller in terms of end-user-functionality than services.

1. License all packages GPL

This used to be referred to as "change nothing". In this option we'll unify all package licenses to be GPLv3.0 and leave it as such.

Strengths:

• consistent licensing story: if it's "data together code, it's GPL"
• attracts contributors who share our explicit vision

Weaknesses:

• the only projects that can use these packages are other GPL projects
• a number of community members will not be able to use these packages

2. Relicense all packages as MIT

In this scenario we flip all packages to MIT, leaving only services as GPL.

Strengths:

• wider potential audience for using these packages
• wider potential audiences for contributors

Weaknesses:

• less consistent licensing story
• potential conflict of interest with partner institutions

3. WARC and CDXJ moved to qri-io GH org, relicensed at MIT there

In this case we just move the two most-contested packages move over to qri, citing data together as the project that has motivated them into existence. qri will maintain these packages on Data Together's behalf.

Strengths:

• consistent licensing story: if it's "data together code, it's GPL"
• address community member's desire to use CDXJ & WARC packages without sacrificing DT values

Weaknesses:

• loosened association with Data Together
• may have to re-have this conversation on a case-by-case bases in the future

4. Have Everything GPL and make a really clear spec, use it as a basis for hosting discussions (see Eclipse as an example)

While I may not do this suggestion justice, I understand this would amount to placing additional requirements on a license / and or creating our own. This is effectively going the route of planning our own license, as we'd be putting additional guidance. The main thrust of this proposal is to get us to think beyond licensing as a means of getting us to rethink what justice means on the d.web

Strengths:

• able to make clear, concise definition of what we're after

Weaknesses

• too expensive to properly implement
• others must read & understand our license before use, instead of being able to use common shorthand framings

I would note that option 4 makes lots of sense in other contexts, these disadvantages only appear in relation to package licensing

[dcwalk]

Thanks @b5 -- I've moved these to a gdoc so more people can add to 'em! Lets also drop in slack 🎉
https://docs.google.com/document/d/14tIA9ByCfVy6sEr5k5q82hA74qc0tx4hR1Qlnl0kYLc/edit#heading=h.jpnxt9indc0v

[b5]

Oh. Man. Turns out we may have just needed to google a little more. I've suggested this into the google doc above, reposting here as well:

5. Use LGPL licenses for all packages

After a little more research, the LGPL seems to be a very close match to what we may want:
From wikipedia:

The license allows developers and companies to use and integrate software released under the LGPL into their own (even proprietary) software without being required by the terms of a strong copyleft license to release the source code of their own components.
… The LGPL is primarily used for software libraries, although it is also used by some stand-alone applications.

Strengths:

• Strikes a strong balance between different interests
• Maintains a consistent licencensing story while letting newcomers gradually (re) acclimate to copyleft principles

Weaknesses:

• It is a compromise on “pure” copyleft principles
• LGPL is not widely known, we may have to do some explaining

---

TL;DR; all contributions & derivative works of these packages would be GPL, but non-GPL projects can import these packages without worrying about these packages affecting their own licensing decisions.

cc @machawk1 & @ibnesayeed. if we went LGPL, would this work?

[dcwalk]

Thanks for adding! I have concerns about LGPL more broadly (and I think it has proven controversial in the OS/FLOSS community) so I just want to caution immediately switching track to that as a best outcome.

• LGPL is incompatible with Apache (https://www.apache.org/legal/resolved.html) "The LGPL is ineligible primarily due to the restrictions it places on larger works, violating the third license criterion. "
• https://www.gnu.org/licenses/why-not-lgpl.en.html
• compatibility challenges: http://gplv3.fsf.org/dd3-faq
• some anecdotal take: https://nikmav.blogspot.ca/2013/03/the-perils-of-lgplv3.html

[ibnesayeed]

@b5: cc @machawk1 & @ibnesayeed. if we went LGPL, would this work?

Most of our code under @oduwsdl lately have been released under MIT license and we can foresee this to be the case for a while. We generally try to respect license terms of the software we use to build them. We will happily use any packages as long as their license is compatible with the license we would release our code under.

That said, I stopped myself from reviewing the code of WARC and CDXJ packages from Data Together because those are the kind of packages that we might potentially need in future and if the License of these packages remains incompatible with our software, we will end up implementing something similar (which will be an obvious duplicate work). I did not want to get any influences, when implementing my own, from a code base that we otherwise cannot use as it is due to an incompatible license.

[machawk1]

I do not have strong feelings on the licensing but wanted to add my 2¢ in response to @b5. Approach 1 and 2 seem heavy handed without regard to potential reuse. (3) seems appealing minus the "loosened association with Data Together", which I do not have an opinion on due to my limited code contributions to DT but others might.

"may have to re-have this conversation on a case-by-case bases in the future" seems like something that should be done anyway so as to not have the blanket effects like (1) and (2).

I will echo @dcwalk's concern based on the reports and write-ups of others re:(5).

Again, I do not have strong feelings either way, unlike @ibnesayeed despite his and my collaboration on a project that would potentially reuse the CDXJ and WARC packages. I suppose the implications of licensing packages as GPL in terms of preventing others from contributing to and improving these packages ought to also be considered. Most previous discussion looks to be around potential reuse and not contribution back to the packages themselves.