Help talk:Toolforge/Right to fork policy

Discussion of initial straw dog proposal

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

2016-09-21 to 2016-10-12 discussion closed per pre-announced timeline.

Too long; Did not read

• Legoktm is in favor of expanding the scope beyond Tool Labs to apply to Labs generally.
  • BryanDavis cautiously agrees but feels that approval and implementation for Tool Labs should happen before expanding scope.
• Legoktm is in favor of requiring readable source code to be present on Tool Labs servers for any and all binary tools (e.g. C, C++, Java, ...).
  • BryanDavis feels that technical enforcement of this would be difficult and suggests that it be part of the socialization mission of the source code committee.
• The proposed language for a universal default GPLv2+ license has open questions about legality especially for tools that existed before some highly visible clickwrap license has been put in place.
• The restriction to OSI-approved licenses has been questioned by Smalyshev.
  • Legoktm and Greg Grossmeier suggest that expanding to the union of OSI, FSF, and DFSG would be reasonable, but restricting to vetted licenses is useful.
  • BryanDavis points out that OSI is the existing policy even though no one may have ever noticed.

• Additional comments from meta:Requests_for_comment/Abandoned_Labs_tools#Require_open-source:
  • meta:User:Jarekt wonders if we could require a single license so all code is compatible and usable across projects. They also are concerned about competing forks of an original project.
    • meta:User:BDavis (WMF) points out that a single license and the existing licensing of 3rd party components are not likely to be compatible.
  • meta:User:ArielGlenn is in favor of changing should to must in the statement "All Tool Labs hosted tools should publish their source code using Wikimedia's provided version control services, another public version control system, or some other publicly accessible means.".
  • meta:User:Koavf is in favor of requiring a free license selected from a suite of acceptable licenses.

---

Rest of labs

To avoid similar problems in the future, I think this policy should also cover the rest of labs. legoktm (talk) 04:15, 13 September 2016 (UTC)

Let's see if we can get it approved and in use for Tool Labs before expanding scope. I agree that in theory there really shouldn't be much difference between things that are hosted in the PaaS environment offered by the Tool Labs project and hosting in the IaaS environment of Labs generally. --BryanDavis (talk) 22:30, 13 September 2016 (UTC)

Socializing

I would suggest that the committee also be given a mandate to encourage developers to publish code on their own. That would mean being a little more proactive and reviewing newly created tools, filing bugs asking developers to publish their code in VCS (I suspect most cases are people being lazy/ignorant, not out of malice), making sure repositories have proper licensing, etc. legoktm (talk) 04:15, 13 September 2016 (UTC)

That sounds like a great idea to me. --BryanDavis (talk) 22:24, 13 September 2016 (UTC)

Done Legoktm made an edit to add this to the straw dog.

Compiled code

Should we have a requirement that the *source* code be present on labs machines? I'm thinking of cases where the code is in C (or something), and all that is present is a binary of the compiled code. legoktm (talk) 04:17, 13 September 2016 (UTC)

I know of at least one case where we have a tool that was in need of help, but that help was blocked because there was no source to go with the compiled Java jar files used to run the bot. I don't know technically how we would enforce a "requirement" though. I think this would probably be more reasonably handled by something like the socializing idea. --BryanDavis (talk) 22:27, 13 September 2016 (UTC)

Making a default GPL-2+ Tool Labs license

I would expect one of the more controversial points of the original straw dog to be the presumption of default GPL-2+ Tool Labs source code license. This is not quite as heavy handed as the TOU of many walled gardens where you grant the site owner a non-exclusive, non-revocable license to do whatever they want with published content by using the service. I've heard that toolserver handled this issue by making users choose a default license at account creation^{[citation needed]}. That is actually a feature I would like to bring to Tool Labs soon, but we will still need to find some means of dealing with the 1500+ existing tools that may or may not include documented licenses. --BryanDavis (talk) 22:41, 13 September 2016 (UTC)

Yep, see mw:Toolserver:Default license. I think GPL-2+ is a good default given that it is the preferred license for MediaWiki code and already is the default for Phabricator. Wikimedia is a pretty strong supporter of the copyleft movement with CC-BY-SA, so it seems natural to go with the GPL. We've basically imposed a AGPL-like requirement that all web services must publish their code, except we're just not making that requirement viral. So yeah, sounds good to me :) legoktm (talk) 22:41, 14 September 2016 (UTC)

Is that even legal? Assuming that the author has given an irrevocable license for reuse without the author ever saying so seems sketchy. At a minimum there should be some clickthrough agreement that we can be sure everyone has clicked through. For tools that are already abandoned, I don't see how this could be done. --tgr (talk) 22:28, 21 September 2016 (UTC)

There has been a form of clickwrap license since 2012-12-15T07:13:07 (notice that new accounts are subject to the TOU) and the TOU has mentioned open source and open data restrictions since 2012-03-20T18:55:06. What hasn't been specified is what happens if you do not explicitly choose a license for original code published as a tool. I agree that retroactively using this on code deployed prior to the policy being adopted needs to be vetted by someone who is not just a armchair copyright enthusiast. --BryanDavis (talk) 23:17, 21 September 2016 (UTC)

As a start, we can require it of *new* tool labs accounts while legal/whomever vet the re-licensing of pre-existing tools. legoktm (talk) 03:10, 22 September 2016 (UTC)

When a file is uploaded to Commons without any permission tag, it is not assumed to be under Creative Commons Attribution-ShareAlike license, instead it is deleted within a few days. Likewise if a tool is not open source I would expect the admins to wipe it out after poking the maintainer. --Ricordisamoa 10:44, 22 September 2016 (UTC)

That presumes that Tool Labs admins have the time and energy to actively patrol tools for license compliance. Although there are a number of members of the tools.admin project who would have the technical ability to do this, there really are too many other issues for the few of us who are active in the project to attend to to perform such actions. This is in part why I think that a volunteer committee is necessary to actual move forward on such policies.

More generally though I think the future looking solution for the licensing problem is to resurrect something like the former mw:Toolserver:Default license as a required component of creating a tool account and then require all existing tools to also declare a default license. I hope to work on the technical side of that in the coming months with a goal of having a solution in place by the end of 2016. --BryanDavis (talk) 15:24, 22 September 2016 (UTC)

No response

A request may be made to the Tool Labs Source Code Committee if no response has been received from maintainers(s) after 14 days.

Replace no response with no source code? The right to fork is not something the tool owner can just say "no" to. --tgr (talk) 22:29, 21 September 2016 (UTC)

I agree that "no" isn't a valid answer, but "I'm a bit busy but I'll get it cleaned up and published in the next couple of weeks" is I think. If things aren't in crisis I don't think we should rush to push the current maintainer out of the way. All of this is going to be a unscientific because humans are involved. Reasonable guidelines will be a start but judgement will be needed. --BryanDavis (talk) 23:05, 21 September 2016 (UTC)

OSI approved

Requiring license to be OSI-approved seems too narrow. What if I want permissive license like WTFPL? In general, why it has to be OSI? --Smalyshev (talk) 23:53, 21 September 2016 (UTC)

OSI approved is the currently (poorly) documented policy. If you want to use WTFPL, just dual-license the code. --BryanDavis (talk) 00:36, 22 September 2016 (UTC)

Because OSI is generally what Wikimedia uses as a standard for "open source" (it's in my employment contract for example). The only reason someone wants to use WTFPL specifically is to be profane or make a point. But WTFPL actually has problems in places where there is no public domain, so people should use the OSI-approved CC-0.

That said, I would be in favor of also being okay with any FSF-approved or DFSG-compatible licenses, as those three lists (FSF, OSI, DFSG) are comprehensive and well maintained, and adhere to the values we want in code licensing. legoktm (talk) 03:08, 22 September 2016 (UTC)

I agree that specifically WTFPL uses profane language, but in service of larger point - and, in my opinion, an important point - you don't/shouldn't need two pages of lawyerspeak that you can't even understand to set your code free. Neither you should need OSI approval to do it. I mean, I have nothing against OSI, but I don't see the need to make unnecessary restrictions. --Smalyshev (talk) 05:00, 22 September 2016 (UTC)

No need at all for pages of anything. The MIT license weighs in at 168 words, is recognized by all of the license review bodies that Legoktm mentioned, and is likely to actually be enforceable in most jurisdictions. I know a lot of folks don't believe that software licenses matter, but I think they are being short sighted. The fragmentation of FLOSS licenses bothers me a lot (can't borrow code from a GPL project to add to an Apache or MIT project, AGPL it practically difficult to comply with even as the original publisher, etc). There is however a very good reason for a US citizen to explicitly license their code. Copyright providing exclusive rights to use and distribution to the original author for life plus 70 years automatically attaches to any software product as eligible work. (That ridiculous duration will continue to grow too as long as Disney wants to protect Mickey Mouse.) If no license is applied this effectively makes the code you produce unusable by anyone else ever. By all means pick MIT or CC0 as a license if you want anyone to do anything with your code. Just please don't assume that you can opt out of the system by force of will. --BryanDavis (talk) 05:31, 22 September 2016 (UTC)

NOT restricting it to a known set of licenses (I +1 Lego's suggestion of using OSI, FSF, and DFSG) maintained by trusted third-parties means that you want this committee to also start reviewing every odd-ball crayon license for enforceability and Free-ness. That is not worth their time and we can simply use all of the great work done by OSI, FSF, and Debian instead. Greg Grossmeier (talk) 16:38, 22 September 2016 (UTC)

Version control system

Why mandate publishing via version control system, instead of just saying the code should be public? --Smalyshev (talk) 23:57, 21 September 2016 (UTC)

That's reasonable. Version control has other advantages, but it probably isn't necessary for the right to fork. I actually have a couple of trivial one-file tools that are not using version control and instead provide a "view source" link. --BryanDavis (talk) 00:38, 22 September 2016 (UTC)

Done see revision 855794

Committee membership

See meta:Requests for comment/Abandoned Labs tools#Committee membership, since this affects both proposals.

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Default GPL-2+ Tool Labs license clause removed from straw dog proposal

After a brief consultation with WMF Legal staff I have decided to remove the default GPLv2+ licensing clause. Relying on click-wrapping to potentially ambiguous terms in the Labs TOU is not best practice for such a clause. Instead I hope to work with the committee that is formed to oversee the policy to promote declaration of licensing by existing and future tool maintainers. I will also be working on adding a mandatory default license selection step to tool account creation as a part of the updated workflows provided by http://toolsadmin.wikimedia.org/. --BryanDavis (talk) 16:16, 31 October 2016 (UTC)

@BryanDavis: If this policy is adopted without a default license, where does this leave us with regards to tools that do not comply with the "must" clause to license their code? Would those tools still be subject to have their source code published without the authors permission? Personally, I don't mind either way, but I do think it's important to make this more explicit to avoid unexpected surprises for those that perhaps wouldn't have expected this. I assume that in such publication, other volunteers would not be allowed to derive or further spread the work - merely use it as inspiration. Unless we include in our policy that copyright is co-owed by the committee if no license is seen in the code and that the committee, upon request, may publish it under a license of their choosing. - Which sounds a lot like a default license. Krinkle (talk) 19:19, 21 November 2016 (UTC)

This gets into actual lawyer territory, but my rough understanding is that the Wikimedia Foundation could chose to assert a right to maintain and use the source code of an unlicensed tool under an implied license theory. Such a right would only belong to the Wikimedia Foundation as a legal entity that can actually hold a license rather than the Wikimedia community which has no clear legal standing in most jurisdictions. It seems likely to me that the committee would have to work with the WMF Legal team to determine when and if such a right could be invoked and what can happen with the source code following such an event.

The reality of the loss of a blanket default license from the policy is that we will need to be more proactive in ensuring that tools actually have a declared default license. I am planning to make this easier with "Manage shared tool accounts via Striker". Once we have the place to store the license and a way to determine which tools have and have not chosen one then we can start an information campaign to get default licenses chosen. Depending on consensus we could even go so far as choose a sunset date to disable any tools that have not yet chosen a license. --BryanDavis (talk) 19:52, 21 November 2016 (UTC)

A mandatory "you must pick a default license before creating your tool" step seems like a good idea to me :) legoktm (talk) 19:34, 22 November 2016 (UTC)

Source code publishing

This proposal looks good to me. Only remark: I'd change the should in "All Tool Labs hosted tools should publish their source code [...]" in a must. Source code for tool labs IMHO should always be public, and enforcing that in advance could make the enforcement of the "right to fork" less painful. --Pietrodn (talk) 09:50, 25 November 2016 (UTC)

I'd question that assertion, for the same reason that abuse filters can be hidden from view by the general public. Anomie (talk) 14:12, 28 November 2016 (UTC)

Round 2

here is an attempt to change that policy again without discussion. Jut because something is released under an OSI does not mean that the source code need be public. Betacommand (talk) 13:18, 17 January 2024 (UTC)

The change was sourced to Help:Toolforge/Rules which at no point requires a publicly accessible source code repository. Betacommand (talk) 13:20, 17 January 2024 (UTC)

This policy was written and published in 2016. I don't understand how you get to arbitrarily change it and demand consensus for restoring the policy that has existed for nearly 8 years. I am reverting to the prior policy text and suggest that if you would like to see an amendment that you start that discussion rather than this one. -- BryanDavis (talk) 15:56, 30 January 2024 (UTC)

I apologize @Betacommand. I misread the history of the "should"/"must" phrase. I should have taken more time before acting. You are correct that until very recently this policy used "should" for code publication.

Technical things are trending a a direction that will advantage and possibly at some point require git hosted projects in public repos, but that has not come to pass yet. -- BryanDavis (talk) 16:37, 30 January 2024 (UTC)