Help talk:Toolforge/Right to fork policy
Discussion of initial straw dog proposal
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)
- 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)