search

datatogether / roadmap

Coordinating technical work & roadmapping additional services
8 stars 3 forks source link

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

Open dcwalk opened 6 years ago

dcwalk commented 6 years ago

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

b5 commented 6 years ago

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:

Weaknesses:

2. Relicense all packages as MIT

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

Strengths:

Weaknesses:

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:

Weaknesses:

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:

Weaknesses

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

dcwalk commented 6 years ago

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 commented 6 years ago

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:

Weaknesses:

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 commented 6 years ago

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.

ibnesayeed commented 6 years ago

@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 commented 6 years ago

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.