Wikidata:Property proposal/FLOSS usage policy URL

FLOSS usage policy URL[edit]

Originally proposed at Wikidata:Property proposal/Generic

Done: free/libre open source software usage policy URL (P9771) (Talk and documentation)

Description	URL for free/libre open source use policy or guideline of an entity
Data type	URL
Domain	instance of/subclass of organization (Q43229)
Example 1	Swedish Social Insurance Agency (Q3372219) → [1]
Example 2	Association for Progressive Communications (Q743611) → [2]
Example 3	OpenStreetMap Foundation (Q6542248) → [3]
Planned use	add all policies I can find to items
See also	Wikidata:Property proposal/FLOSS development policy URL https://www.wikidata.org/wiki/Wikidata:Property_proposal/service_status_information_URL

Motivation[edit]

FLOSS policies are found in at least two government agencies and numerous non-profit organizations (see example above) So9q (talk) 12:20, 2 February 2021 (UTC)[reply]

Discussion[edit]

Support --Lectrician1 (talk) 17:21, 2 February 2021 (UTC)[reply]

Comment This is very interesting and potentially very useful. How do we do for countries where there are laws for FLOSS (like Italy and Bulgaria). Then there are no "policy" at all but the same law for all public agencies in the country. Ainali (talk) 19:04, 2 February 2021 (UTC)[reply]

No idea, had no idea it was mandated by law to use FLOSS. I think it's out of scope of this property. Maybe we should model that too but on the country item.--So9q (talk) 11:55, 3 February 2021 (UTC)[reply]

Wait, is this only intended for what kind of software an organization use? I was thinking it was more important to document the policies of the software they develop or contribute to. But perhaps we can use it for both using of (P642) as a qualifier? (Whatever we choose, the description needs to be perfectly clear.) Ainali (talk) 22:52, 21 February 2021 (UTC)[reply]

If it's only for their use, I suggest suggest we rename it to FLOSS usage policy URL and the description to "URL for policy or guideline of an entity's usage of free/libre open source software". Ainali (talk) 09:34, 13 March 2021 (UTC)[reply]

@Ainali: Done, see below.

Comment Do we want to define what open source is for this property (like policies that prescribe a license defined as open by Open Source Initiative (Q845918)), or should we allow policies that call themselves open whatever license they use? And should the licenses be recorded as qualifiers? Ainali (talk) 20:56, 4 February 2021 (UTC)[reply]

In the case of FK above there is no specific licenses mentioned. To record something like that we would need a new property like "policy recommends" -> OSI approved license.--So9q (talk) 10:25, 5 February 2021 (UTC)[reply]

I was thinking copyright license (P275) but that might be perceived as applying to the policy itself. But even if we don't have a qualifier, what do you think about the proposed constraint? Ainali (talk) 13:04, 5 February 2021 (UTC)[reply]

@ainali: You raise an interesting point. Maybe a qualifier "recommends" -> "OSI approved licences only", "recommends" -> licenses both with and without OSI approval, "recommends" -> no licences. Then we don't force the world into our model and you can still query for policies that recommend OSI-licenses. Currently there is no such property though.--So9q (talk) 22:52, 24 February 2021 (UTC)[reply]

@So9q: Could you clarify this proposal regarding Ainali's question, so we can get it made? JesseW (talk) 18:30, 9 April 2021 (UTC)[reply]

@JesseW: Done, see below.

Support, an important property for sites.--Arbnos (talk) 21:14, 21 February 2021 (UTC)[reply]

Marked as ready, multiple supports, no particular objections. JesseW (talk) 04:02, 8 April 2021 (UTC)[reply]

@JesseW: I removed the Ready mark since I'll ~~Oppose~~ until we clarify if this intended for the policy for use of FLOSS, development of it or both. We better solve that question before we create the property. Ainali (talk) 19:32, 8 April 2021 (UTC)[reply]

@Ainali: Makes sense; I wasn't sure from your comment if you intended to block the proposal, or if it was something that could be addressed later. Thanks for clarifying. JesseW (talk) 23:09, 8 April 2021 (UTC)[reply]

To be clear, I absolutely think we need a property or two for this. I just want us to get it right from the start after seeing what mess it becomes if you after just a few weeks of using it realize that people use a property differently. Ainali (talk) 06:51, 9 April 2021 (UTC)[reply]

Adopted your suggestion to limit the scope for use of FLOSS which is the intention of the FK example that originated this property. We need another property for FLOSS development policies like this one IMO [4]--So9q (talk) 15:14, 10 April 2021 (UTC)[reply]

I discussed a bit with Abbe98 and another approach would be to just use one property, but with mandatory qualifier to point out which one it is. A qualifier could be of (P642) and it could then look like:

Swedish Social Insurance Agency (Q3372219)FLOSS URL policyhttps://github.com/Forsakringskassan/riktlinje-oppenkallkod/blob/master/riktlinje.mdof (P642)use (Q1724915)

An item with different URL's have two statements, and if there is just one URL for both, it can be one URL with two qualifiers.

This would save us from creating many properties and make it easier to find all organizations that have some policy. Ainali (talk) 19:37, 10 April 2021 (UTC)[reply]

I understand that this would save a property, but I think this suggestion is making it overly complicated to edit or search the graph and it uses of (P642) which is best avoided (according to @Lucas Werkmeister:). I have no problem with 2 propertities on an item having the same URL. E.g. Swedish Social Insurance Agency (Q3372219)FLOSS usage policy URLhttps://github.com/Forsakringskassan/riktlinje-oppenkallkod/blob/master/riktlinje.md and Swedish Social Insurance Agency (Q3372219)FLOSS development policy URLhttps://github.com/Forsakringskassan/riktlinje-oppenkallkod/blob/master/riktlinje.md.I wonder what others think about this redundancy/complexity.--So9q (talk) 08:36, 1 August 2021 (UTC)[reply]

Sure, we could go with two different properties. But in that case, perhaps better start a new proposal for those two for a clean slate? Ainali (talk) 10:41, 1 August 2021 (UTC)[reply]

Support Ainali (talk) 22:39, 1 August 2021 (UTC)[reply]