Wikidata talk:WikiProject Informatics/FLOSS

From Wikidata
Jump to navigation Jump to search

Activate Wikidata:Flow[edit]

WikiProject Informatics has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.

Dachary
Metamorforme42
NMaia
Valerio Bozzolan
MichaelSchoenitzer
Jasc PL
LiberatorG
Dexxor
Waldyrious
Iwan.Aucamp
Airon90
Ainali
Haansn08
So9q
Tomodachi94
Zblace
Labdajiwa
Mind_Booster_Noori

Notified participants of WikiProject Informatics/FLOSS

I propose that we activate Flow on this page. If there is no opposition within two weeks, I'll do it. Dachary (talk) 15:44, 16 July 2016 (UTC)[reply]

@Metamorforme42: I'm not sure how to do that on this page. Is it even possible ? – The preceding unsigned comment was added by Dachary (talk • contribs) at 15:44, 16 July 2016‎ (UTC).[reply]
@dachary: See Wikidata:Flow#Community page, Wikidata talk:Flow or eventually ask to Trizek (WMF).
ps: ping don't works if you forget signing.
— Metamorforme42 (talk) 19:49, 24 August 2016 (UTC)[reply]

floss Catering isn’t a large contributor to open source[edit]

Unaffiliated developers are currently assigned to the organization floss.cc, a domain that happens to be owned and operated by bloss Catering in Germany. How about using an actual email address instead of picking on a random unaffiliated company? They must receive a bunch of email spam from Wikidata’s use of their domain. Propose changing contact@floss.cc to something at example.org or an organization that represents the interest of otherwise unaffiliated open source contributors (EFF? OSI?).

Mail threads[edit]

 – The preceding unsigned comment was added by Dachary (talk • contribs) at 09:17, 16 July 2016‎ (UTC).[reply]

Dual licensing[edit]

Liferay Portal (Q254211) actually are two slightly different software, one is distributed under a Free Software license and the other is under a proprietary license and has more features etc. I updated the license / instance of statements to add the proprietary aspects, with references so that it's less confusing. I however wonder if it would be better with two distinct items, related to each other. – The preceding unsigned comment was added by Dachary (talk • contribs) at 09:18, 16 July 2016 (UTC).[reply]

There is nothing wrong with having both. It is like having multiple editions of a book (with different ISBNs/product codes and licensing, prices, etc.). I think we can still consider them a single software. 50.53.1.33 00:29, 25 September 2016 (UTC)[reply]
When the only thing that changes is price and licensing, it makes sense to me. However the proprietary version of Liferay Portal (Q254211) is updated during a long period (4 years according to https://www.liferay.com/subscription-services Liferay Enterprise Subscription gives you four years of software updates per version. Liferay Community Edition is only updated once or twice after the first GA release) and becomes different from the free software version over time. This is an interesting case because there is only one name for the product although there are two different products, when you look close enough. When there are two different products and the developer gives them different names (such as GitLab EE (Q25973915) and GitLab (Q16639197)) and their code base is mostly the same, having two different items makes sense and there is no confusion. Dachary (talk) 07:22, 25 September 2016 (UTC)[reply]

For the record ISO Master (Q663640) appears to be a case of dual licensing where there is no difference between the proprietary software and the free software. Dachary (talk) 09:56, 28 September 2016 (UTC)[reply]

Identifiers[edit]

The Software directory entries and identifiers should be put together. I initially thought it would be best to have a chapter different from properties because it shows in a different part of the interface when editing an item. However, I'm happy to merge that with properties instead. @Metamorforme42: what do you think ? Dachary (talk) 08:23, 3 August 2016 (UTC)[reply]

You can merge. I just don't seen the section identifiers. — Metamorforme42 (discussion) 16:44, 3 August 2016 (UTC)[reply]
✓ Done That was done some time ago but I forgot to update that topic. Dachary (talk) 12:15, 14 September 2016 (UTC)[reply]

instance of (P31) qualifier of source code repository URL (P1324)[edit]

@NMaia: you added mirror storage (Q654822) as a qualifier to a source code repository URL (P1324) at https://www.wikidata.org/wiki/Q20085696 which sounds like a great idea. Would you like to document that at https://www.wikidata.org/wiki/Wikidata:WikiProject_Informatics/FLOSS#source_code_repository ? If you don't have time, I can do it. Dachary (talk) 22:30, 2 September 2016 (UTC)[reply]

It's a good idea to say the website is a mirror but instance of (P31) is not a qualifier so p31 can't be used as a part of a claim that says something about the specific claim (and p31 say “this item is a specific example and a member of that class”; an url is not an item)
Maybe should we find a better way to write this ? — Metamorforme42 (talk) 23:12, 2 September 2016 (UTC)[reply]
I'm open to any ideas :) ~★ nmaia d 23:30, 2 September 2016 (UTC)[reply]

What about adding the qualifier archive URL (P1065) with the URL of the mirror ? Say git://foo.com/ has is mirrored at git://bar.com/ and git://frob.nitz, two archive URL (P1065) qualifiers are added to git://foo.com/, one with git://bar.com/ and the other with git://frob.nitz. There can be a source code repository URL (P1324) statement for git://bar.com/ but even if there is no such statement, the information is valuable and verifiable (to the extent that is is not a 404 URL at least). What do you think ? Dachary (talk) 09:07, 3 September 2016 (UTC)[reply]

Hmm, it's not exactly an archive though, is it? ~★ nmaia d 13:10, 3 September 2016 (UTC)[reply]
A mirror is only pertinent if it is online, like archives (an historic of mirrors including old mirrors is useless because a software repository can have a lot of different mirrors), but it is not exactly an archive (because up-to-date opposite to an archive who is a fixed representation of data at a precise time (we can't archive date (P2960) with a mirror)). Should we create a new qualifier (mirror) ? — Metamorforme42 (talk) 13:25, 3 September 2016 (UTC)[reply]
A new mirror qualifier would be better, sure. I agree with both of you that archive URL (P1065) is not ideal. I picked it because it already exists but it's definitely not a perfect fit. I would support a new mirror URL qualifier. Dachary (talk) 14:42, 3 September 2016 (UTC)[reply]
Me too. At any rate, it would be nice to get the wider community's take on the desirability of such a qualifier. ~★ nmaia d 13:38, 4 September 2016 (UTC)[reply]

✓ Done The discussion should move to the mirror URL property proposal created just now. Dachary (talk) 12:12, 14 September 2016 (UTC)[reply]

@NMaia:, @metamorforme42: it would be great if you could comment on the mirror URL property proposal. Dachary (talk) 09:10, 18 September 2016 (UTC)[reply]

@dachary: ✓ Done and I added french translation and subject item. — Metamorforme42 (talk) 14:08, 18 September 2016 (UTC)[reply]

propose a wikidata id to appdata.xml[edit]

Reach out to https://people.freedesktop.org/~hughsient/appdata/ to propose a new element with the wikidata id of the software : https://lists.freedesktop.org/archives/freedesktop/2016-September/000339.html Dachary (talk) 21:17, 7 September 2016 (UTC)[reply]

✓ Done The discussion continues in the mail threads above and will be concluded there. Dachary (talk) 12:14, 14 September 2016 (UTC)[reply]

removed feature (P756)[edit]

I've been using removed feature (P756) in a way which I'm not sure if it's correct, but it makes sense to me. In Devuan (Q18601928), I added removed feature (P756) → systemd (Q286124). Similarly, in Linux-libre (Q665683) I set removed feature (P756) → proprietary device driver (Q763151). Any thoughts on this would be appreciated, thanks. ~★ nmaia d 13:42, 4 September 2016 (UTC)[reply]

Could you describe how removed feature (P756) should be used ? I think I get what you're after but it would help to have a detailed description. Thanks :-) Dachary (talk) 08:12, 7 September 2016 (UTC)[reply]
Well, that's what I was hoping you folks would help with. My reading of removed feature (P756) is something that is specifically removed from this edition/version/distribution. But I'd like to hear your understanding of it :) ~★ nmaia d 13:48, 7 September 2016 (UTC)[reply]
That's also my understanding. In the case of Devuan (Q18601928) you added removed feature (P756) → systemd (Q286124) but it should also state from where it was removed. If used as a qualifier for software version identifier (P348) it would mean that it existed in previous versions and was removed in this software version. If used as a statement for a software that follows (P155) another software, it would mean something similar. IIRC Devuan (Q18601928) is a GNU/Linux distribution that has been created from scratch and had never had systemd to begin with. Maybe you meant to express the fact that it does not use systemd ? If that's the case, removed feature (P756) may not be the best choice. Dachary (talk) 20:09, 7 September 2016 (UTC)[reply]
Isn't Devuan based on Debian? ~★ nmaia d 21:35, 7 September 2016 (UTC)[reply]
It looks like Devuan is indeed based on Debian, my bad for not catching this. What about having removed feature (P756) → systemd (Q286124) as a qualifier of the based on (P144) statement ? Dachary (talk) 07:00, 8 September 2016 (UTC)[reply]
Hmm that would be adequate, I think :) ~★ nmaia d 21:39, 8 September 2016 (UTC)[reply]
Cool :-) Would you like me to update the item and the documentation accordingly ? Or would like to do it yourself. Either way is fine with me :-) Dachary (talk) 11:53, 12 September 2016 (UTC)[reply]
It would be lovely if you could, I'm a bit overworked at the moment :P ~★ nmaia d 23:29, 13 September 2016 (UTC)[reply]
✓ Done Updated the software project page accordingly and you already updated the Devuan item. All good :-) Dachary (talk) 11:44, 14 September 2016 (UTC)[reply]

CVS :pserver: repositories are not URLs[edit]

There still are some CVS repositories around (for instance GNU Linear Programming Kit (Q838189)). Contrary to all other VCS, it is not a URL when presented as :pserver:anonymous@cvs.sv.gnu.org:/sources/glpk. We cannot use it as an object of source code repository URL (P1324) because a URL is required. Does someone have an idea on how to handle that ? Dachary (talk) 15:02, 14 September 2016 (UTC)[reply]

For LibTIFF (Q1017110) I set the web page that has the :pserver: instructions as source code repository URL (P1324) and added both HTTP (Q8777) and CVS (Q467252) as a workaround until we figure out something. Dachary (talk) 10:35, 15 September 2016 (UTC)[reply]
Apache Maven (Q139941) has already attacked the problem of encoding CVS connection methods (see http://cvsman.com/cvs-1.12.12/cvs_28.php) in to URIs (see https://maven.apache.org/scm/cvs.html). I am not sure we can leverage this solution or not (CVS (Q467252) does not actually use this syntax). Incidentally the Maven encoding solution does not produce a dereferencable URL (Q42253) but rather just an abstract Uniform Resource Identifier (Q61694). It should be noted that the Internet Assigned Numbers Authority (Q242540) URI scheme registry (see http://www.iana.org/assignments/uri-schemes) does not contain an entry for "scm". Also the registry mentions the "cvs" scheme (see http://www.iana.org/assignments/uri-schemes/prov/cvs) presenting another method which seems appropriate and seems to claim "Scheme creator: The CVS Team" (so perhaps this is the best encoding scheme). 50.53.1.33 04:16, 20 September 2016 (UTC)[reply]
Impressive research :-) What about we use http://www.iana.org/assignments/uri-schemes/prov/cvs as a URL and add a qualifier with the :pserver: string ? This way a human being can copy/paste the :pserver: string, we have a URL that is suitable for the source code repository URL (P1324) datatype and a bot can rebuild the :pserver: from the URL and verify they match. It's a little bit complicated but there only are a few dozens CVS repositories. Dachary (talk) 06:49, 20 September 2016 (UTC)[reply]
✓ Done The discussion continues with the proposal of the cvs scheme. Dachary (talk) 20:28, 26 September 2016 (UTC)[reply]

source code repository URL (P1324) protocol (P2700) qualifier[edit]

I am wondering about this. Most version control (Q189439) systems are not really instances of a communication protocol (Q132364) but they can and often do support multiple "wire" protocols for accessing a repository (Q3133368), so I asked myself: shouldn't this qualifier represent the protocol used to access a repository with a specified Uniform Resource Identifier (Q61694) or other such specifier (I notice discussions about CVS (Q467252) "wire" protocol specifiers not being URIs)? As examples, I cite:

And of course this is in addition to local file (e.g., file URI scheme (Q5448333)) which virtually all such systems must support. In general VCS are not required to support any network protocols (just the local file access though a distributed revision control system (Q1186723) that only supports local file access would probably be inane).

Perhaps the thinking is that the actual network "wire" protocol is already specified by means of the Uniform Resource Identifier scheme (Q37071). That seems reasonable, however, I notice both of the above systems do not have instance of (P31) or other claims making them a communication protocol (Q132364) so creating qualifiers using them as the object of protocol (P2700) seems wrong. It seems to me media type (P1163) (e.g., "Content-Type: application/mercurial-0.1") or file format (P2701) would be a better property for qualifying the type of VCS repo specification claim. What do you think?

I ask this because I was reverted while making such changes to source code repository URL (P1324) protocol (P2700) qualifiers. Thank you for sharing. 50.53.1.33 15:00, 18 September 2016 (UTC)[reply]

  • You have a good point about the fact that URLs often support multiple protocols, regardless of the scheme they start with (for instance github.com URLs respond to HTTP as well as git). When relevant a source code repository URL (P1324) should be qualified with multiple protocols for that reason. The other points you make about protocols are valid but I'm not sure I understand the problem you're trying to describe. I'd be grateful if you could rephrase it to clarify. The URL of a source code repository URL (P1324) responds to a protocol (P2700), it cannot be defined by a file format (P2701) nor by a media type (P1163) which is a way to specify file formats and format contents transmitted on the Internet. (P.S. it would help with the dialog if you could create an account for yourself, otherwise the IP address you're using is likely to be different when you change location and it will be difficult to followup). Dachary (talk) 21:10, 18 September 2016 (UTC)[reply]
Well that is actually the point. A single URI only supports a single communication protocol (Q132364) as per its Uniform Resource Identifier scheme (Q37071). However, multiple representations of a resource can be served at a single URI (e.g., via HTTP content negotiation (Q1128629)). Served resource representations can be content labelled (e.g., with media type (Q1667978), IETF language tag (Q1059900), etc.). You mentioned GitHub (Q364), so I shall arbitrarily pick li₃ (Q6647924) as an example. The URL https://github.com/UnionOfRAD/lithium.git, as per its "https" scheme, can only be accessed via the HTTPS (Q44484) protocol (on port 443), however, it can, and does return different representations/contents based on the client request (e.g., HTML (Q8811), JSON (Q2063), etc.). A URI with the scheme "http" is only accessible via HTTP (on port 80 unless otherwise specified) and one with the "git" scheme is only accessible via the insecure git protocol (on port 9418 unless otherwise specified; see https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols). Mercurial (Q476543) is not really a protocol itself, however, it does support two protocols (in addition to local file access which can be represented via a URI with a file URI scheme (Q5448333)) specified by the following schemes: "http" (and secure "https") and "ssh" (see https://www.mercurial-scm.org/wiki/WireProtocol). Incidentally, though I usually prefer to contribute via IP, I do have an account (going back to 2004). 50.53.1.33 06:54, 19 September 2016 (UTC)[reply]
The protocol qualifier for source code repository URL (P1324) currently means : "what VCS can I use with this URL ?". This is not the precise definition of a protocol and you made it very clear, thanks for taking the time to explain in detail :-). We could either agree that this interpretation of the protocol qualifier, in this specific context, is good enough. Or we could propose a new qualifier that exactly convey the intended meaning. And after the qualifier has been created, a bot can change the protocol qualifier to use the new qualifier. Which way would you like to go ? Dachary (talk) 10:31, 19 September 2016 (UTC)[reply]
We need a property that corresponds to version control (Q189439) instead of communication protocol (Q132364) for qualifying such claims. I did a cursory investigation and it seems protocol (P2700) does have current multiple conflated meanings/usage (easily found from Wikidata:Property proposal/Archive/48#P2700 based on the original proposal for protocol (P2700)) so we do need a new property (we cannot just co-opt/update it to have the meaning we want) and will likely need to disambiguate the meanings/usages updating claims en masse via a bot as you mentioned. Incidentally, the new property should be able to be applied to any URL property (e.g., generic URL (P2699)) to specify its usage with a VCS (e.g., specifying links to branches or specific files and versions withing a repo). I recommend a property name along the lines of "version control system", "repository version control system" or "repo VCS type", etc. 50.53.1.33 02:15, 20 September 2016 (UTC)[reply]
Agreed. Could you propose such a property ? Once it exists I can add something to User:FLOSSbot to convert the existing protocol qualifiers of source code repository URL (P1324) to use it instead. Dachary (talk) 06:40, 20 September 2016 (UTC)[reply]

I'm browsing the properties looking for something to replace protocol (P2700). It should be more generic than media type (P1163) or file format (P2701). Here is what I found: including (P1012), uses (P2283) used by (P1535) or facet of (P1269) because the server reachable via this source code repository URL (P1324) URL has to include the VCS one way or the other to answer to the VCS client in a useful way; P794 (P794) because it is a valid VCS. While it makes sense when you think about it, there is very little chance an editor figures that out by herself/himself. I'll keep looking. Dachary (talk) 12:39, 21 September 2016 (UTC)[reply]

Well I notice there are issue tracker URL (P1401) and package management system (P3033) properties. Surely, we can get a version control system property. That said, the target property needs to be a Wikidata qualifier (Q15720608) (which excludes uses (P2283), used by (P1535), facet of (P1269) unless we co-opt them a qualifiers; I believe very few properties are qualifiers and as properties on entities like items or other properties) and of type item (which excludes media type (P1163)). version type (P548) and file format (P2701) are interesting but I agree specifically in the wrong directions (and/or not general enough). including (P1012) also has this problem (too related to has part(s) (P527)). P794 (P794) is general enough but perhaps too general (as you stated it would be hard to educate editors). 50.53.1.33 15:16, 24 September 2016 (UTC)[reply]
I agree :-) Would you like to propose the version control system property ? Dachary (talk) 22:17, 26 September 2016 (UTC)[reply]
@Dachary: It appears Waldyrious has now made Wikidata:Property proposal/version control system so once that is created you can fire up the bot you mentioned earlier. That said, it seems you have not done much on Wikidata since 2017 (see Special:Contributions/Dachary and Special:Contributions/FLOSSbot vs. fr:Special:Contributions/Dachary) so I doubt you will get to it. —Uzume (talk) 18:54, 9 July 2020 (UTC)[reply]

Licenses or later[edit]

Should we create elements for GPL-1.0+, GPL-2.0+ and GPL-3.0+ with statements "subclass of GPL" and "has part GPL-3.0[ and GPL-2.0[ and GPL-3.0]]" ?

For example, CVS (Q467252) is actually under GPL-2.0+ (from the reference on the item) but writing GPL-2.0 is false because it is also GPL-3.0, and writing "GPL-2.0 and GPL-3.0" is only true for the moment (what if a GPL-4.0 come in some years? we lost an information (the +)).

Problem, this is not the only one item concerned: could we use a bot for checking in the references if the license is GPL-2.0+ instead of GPL-2.0 or, GPL-2.0 instead of "GPL-2.0 and GPL-3.0", or GPL-3.0+ instead of GPL-3.0, etc. (@Dachary:) ?

Problem number 2 (but it is not really our because we can't change software licenses, we just put the informations we have) : GPL-2.0+ is deprecated, GPL-3.0+ and GPL-1.0+ both.

— Metamorforme42 (talk) 19:47, 24 September 2016 (UTC)[reply]

What do you mean by deprecated? The link does not help at all to understand what it means by that. ~★ nmaia d 20:31, 24 September 2016 (UTC)[reply]
It's only a syntax problem or a how to describe the license of a new project (see the bottom of this page), finally I don't think we are concerned. — Metamorforme42 (talk) 21:06, 24 September 2016 (UTC)[reply]

Idem for LGPL (LGPL-2.0+, LGPL-2.1+ and LGPL-3.0+) — Metamorforme42 (talk) 22:03, 24 September 2016 (UTC)[reply]

 Approved I think we should create elements for *GPL*+ as you suggest and https://spdx.org/licenses/ clearly explains why it is a useful way to describe a variation of the licensing terms of a software. Dachary (talk) 22:34, 24 September 2016 (UTC)[reply]
Ok, we have now GNU General Public License, version 1.0 or later (Q27016750), GNU General Public License, version 2.0 or later (Q27016752), GNU General Public License, version 3.0 or later (Q27016754), GNU Library General Public License, version 2.0 or later (Q27016756), GNU Lesser General Public License, version 2.1 or later (Q27016757), and GNU Lesser General Public License, version 3.0 or later (Q27016762).
I have now to check all softwares with gplv1only, gplv2only, gplv3only, lgplv2.0only, lgplv2.1only, or lgplv3only (✓ Done). So can a bot read references and determine witch item have not the correct license ? Or at least giving a list of the software witch have some of theses licenses with references. I can do it manually, but it will take hours. — Metamorforme42 (talk) 09:37, 25 September 2016 (UTC)[reply]
I could write something as part of User:FLOSSbot. How would you describe the algorithm in abstract terms ? Dachary (talk) 17:58, 25 September 2016 (UTC)[reply]
Thank you, I will probably describe it in the next few days (I have to sleep now…). — Metamorforme42 (talk) 20:22, 25 September 2016 (UTC)[reply]

✓ Done Since the implementation of scripts to better handle that is outside of the scope of this discussion. Dachary (talk) 16:26, 28 September 2016 (UTC)[reply]

Community edition and Enterprise edition[edit]

Have we already some elements like community edition or entreprise edition for use with applies to part (P518) on a license statement for example ? See Neo4j (Q1628290) witch for the moment use incorrectly review score (P444). — Metamorforme42 (talk) 20:17, 25 September 2016 (UTC)[reply]

It does seem like those would make good candidates for items as I am not aware of anything like that, however, I do note the similarity with alpha version (Q2122918), beta version (Q3295609), release candidate version (Q1072356) and stable version (Q12355314) (often used with version type (P548)). 50.53.1.33 20:53, 26 September 2016 (UTC)[reply]
Having different items (one for the Free Software version and one for the proprietary version) also makes sense to me (GitLab EE (Q25973915) and GitLab (Q16639197) are an example). It gets trickier when the developer gives the same name to both software despite significant technical differences (see Dual licensing above for instance). Using review score (P444) as is done in Neo4j (Q1628290) conveys the information, no doubt about that. But having separate items seems a lot simpler. Dachary (talk) 22:12, 26 September 2016 (UTC)[reply]
Ok, does exist a tool for duplicate an item easily ? Two items really look simpler (or maybe we could see this as two branches of the software ?) — Metamorforme42 (talk) 16:54, 27 September 2016 (UTC)[reply]
I'm not aware of a tool to duplicate items. Sound useful though :-) Dachary (talk) 20:20, 27 September 2016 (UTC)[reply]

For the record, I created Zarafa for home (Q27042442) today: it is the proprietary version of Zarafa (Q147680) and has a different name.Dachary (talk) 09:29, 28 September 2016 (UTC)[reply]

✓ Done I've handled a dozen such cases since the last comment and using the existing license / instance of and occasionally creating items when the software is different was enough IMHO. If someone is unsatisfied, please remove the done and let's continue the chat ;-) Dachary (talk) 20:26, 4 October 2016 (UTC)[reply]

License statistics[edit]

@Metamorforme42: The GPL-2.0+ etc. do not show at in the license statistics because they are not (even indirectly) a subclass of free software license (Q3943414) or OSI-approved license (Q1156659). I could add to the query that it should also include items that have a license that is an instance of a license which is a subclass of free software license (Q3943414) or OSI-approved license (Q1156659). Since this is getting a bit complicated, I would appreciate a confirmation from you that this is indeed the simplest way. Dachary (talk) 16:25, 28 September 2016 (UTC)[reply]

Imo, it is. And thanks to your modification, we can now see X11 license (Q18526202) in the stats. — Metamorforme42 (talk) 12:00, 29 September 2016 (UTC)[reply]
✓ Done Cool, thanks for the confirmation. Dachary (talk) 15:30, 29 September 2016 (UTC)[reply]

Heads up: Android ID proposal[edit]

Discussion on Wikidata:Property proposal/Android ID‎ is taking place, and your opinion on it is most welcome! ~★ nmaia d 18:27, 4 October 2016 (UTC)[reply]

Importing licenses[edit]

I'm implementing the following strategy to import licenses from various infoboxes, using User:FLOSSbot.

  • For each item that is an instance of (P31) Free Software that has no copyright license (P275) claim
  • Parse each interlink to extract the license field from infoboxes
  • If the licenses of each interlink are exactly the same, add a license claim, otherwise display them for the editor to figure it out

Does that sound sensible ? Dachary (talk) 22:32, 8 October 2016 (UTC)[reply]

A first implementation was submitted for approval. Dachary (talk) 21:48, 12 October 2016 (UTC)[reply]

The problem with this implementation is that GPLv3 will be imported as GNU General Public License because it redirects to it. Handling of redirects should be done differently. Dachary (talk) 10:36, 15 October 2016 (UTC)[reply]
Looking at the wikipedia entries I think most of them link directly to GPL, even if the license infobox parameter states that it is GPLv3. When the version of the license is mentioned it is done in a way that I can't figure out how to parse. IMHO setting the particular version of the license should either be done manually or by harvesting information elsewhere. For instance via fossology, using the source code repository. Dachary (talk) 12:52, 17 October 2016 (UTC)[reply]

Property documentation[edit]

There is a lot of useful reference information about properties on this page, but the actual property documentation pages are decoupled from this -- see for instance Property talk:P1324 vs. Wikidata:WikiProject Informatics/FLOSS#source code repository. Wouldn't it be preferable if we moved this information to the property pages themselves, and link/transclude them here? Or alternatively, add them to a subpage of the property documentation, and transclude them in both places? --Waldir (talk) 22:39, 11 April 2017 (UTC)[reply]

Merge FLOSS with Software[edit]

Dachary
Metamorforme42
NMaia
Valerio Bozzolan
MichaelSchoenitzer
Jasc PL
LiberatorG
Dexxor
Waldyrious
Iwan.Aucamp
Airon90
Ainali
Haansn08
So9q
Tomodachi94
Zblace
Labdajiwa
Mind_Booster_Noori

Notified participants of WikiProject Informatics/FLOSS

MichaelSchoenitzer
dachary
Metamorforme42
Ash Crow
OdileB
John Samuel
Jasc PL
Daniel Mietchen
Iwan.Aucamp
SM5POR
Moritz Schubotz

Notified participants of WikiProject Informatics/Software

Could we merge page "FLOSS" into "Software", now that we have tabs in Software page? OdileB (talk) 10:27, 10 June 2017 (UTC)[reply]

Dachary
Metamorforme42
NMaia
Valerio Bozzolan
MichaelSchoenitzer
Jasc PL
LiberatorG
Dexxor
Waldyrious
Iwan.Aucamp
Airon90
Ainali
Haansn08
So9q
Tomodachi94
Zblace
Labdajiwa
Mind_Booster_Noori

Notified participants of WikiProject Informatics/FLOSS

MichaelSchoenitzer
dachary
Metamorforme42
Ash Crow
OdileB
John Samuel
Jasc PL
Daniel Mietchen
Iwan.Aucamp
SM5POR
Moritz Schubotz

Notified participants of WikiProject Informatics/Software

As nobody seems to object, I will probably try to do a merge FLOSS -> Software and copy the most informative texts and discussions into the still-non-existing Software page Discussion. I also wish to reorder the properties in alphabetic order. OdileB (talk) 15:03, 22 June 2017 (UTC)[reply]

Outdated software-versions by checking against Arch-Packages[edit]

Dachary
Metamorforme42
NMaia
Valerio Bozzolan
MichaelSchoenitzer
Jasc PL
LiberatorG
Dexxor
Waldyrious
Iwan.Aucamp
Airon90
Ainali
Haansn08
So9q
Tomodachi94
Zblace
Labdajiwa
Mind_Booster_Noori

Notified participants of WikiProject Informatics/FLOSS

I wrote a little script that searches for outdated software-versions by comparing the newest version-number available on Wikidata to the version available in the Arch-Linux-Repos. You can find it's source-code here and it's results here. I plan an having a bot update it regularly – has anyone a bot that could do this? -- MichaelSchoenitzer (talk) 15:02, 18 October 2017 (UTC)[reply]

Notified participants of WikiProject Informatics/FLOSS
I've improved it a little. It now runs once a day on toolforge. It also tries to sort the list according to the "size" of the difference in version-number, so things where the first version number have changed are listed on top, etc. I think fully automatically adding the version-numbers from packages is not a good idea: this would lack the publication date (P577) and a source and there are a lot of false-posivitves (look at amule or wine for example). But what I would like to do, is to enhance the site of half-automatic editing formality, maybe a bit like the wikidata-games have them. I think, we should try to have a little team who looks at the list regularly and tries to keep at least all major-versionnumbers up-to-date. -- MichaelSchoenitzer (talk) 11:41, 28 December 2017 (UTC)[reply]

Ways to identify a Wikidata Item as Free/Open Source Software[edit]

There are currently several ways that Items are identified as Free/Open Source Software:

Most of the time these are synonyms – but there are a handful of exceptions.

Currently there seems to be no plan or logic in what is used when. I generated a Venn diagramm to see how much they are used nowadays and how much they overlap. We should think about how we want to handle things in the future. I see several possibilities:

  1. Remove all the instance of (P31) statements and identify them only by there license.
  2. Use free software (Q341) wherever appropriate.
  3. Use free and open-source software (Q506883) when ever a software is free and open source software. Use free software (Q341) and open-source software (Q1130645) only in the rare cases when a software is only free (according to FSF) or only open source (according to OSI).

I personally strongly prefer Option 3, since it's the most correct one. Option 2 would be easiest to reach since its the most common of the three, but it's less correct than Option 3. Option 1 has no redundant information but has the problem that there are a lot of programs using there own (unnamed) license, so it would be hard/unrealistic to add them all to Wikidata as own items (at least for now). Also it makes accessing them harder. What's you opinion? Should we make an RFC? -- MichaelSchoenitzer (talk) 13:12, 5 January 2018 (UTC)[reply]

WikiProject Informatics has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. -- MichaelSchoenitzer (talk) 13:13, 5 January 2018 (UTC)[reply]
Notified participants of WikiProject Informatics/FLOSS -- MichaelSchoenitzer (talk) 13:15, 5 January 2018 (UTC)[reply]
I totally agree on the fact that there are no plan or logic, as also for other wikidata arguments, so any effort to make a more effective approach is welcome,thanks. IMHO free and open-source software (Q506883) has a redundant definition: a free software must respect the four freedoms [1], and to respect the freedoms to study and to improve the program we need to have an "Open Source" code. free software (Q341) is comprehensive and should be used. Moreover, as you say, it is the most common term.
Talking about the licenses, Option 1 is my preferite way to proceed, since it would be easy for many contributors just to record the license type (GPL, PD, etc...). Then the license should be classified as instance of (P31)free software license (Q3943414).--FabC (talk) 14:10, 6 January 2018 (UTC)[reply]
 Comment Agree with @FabC: that Option 1 is the best approach. To address the concerns raised by @MichaelSchoenitzer: about custom/unnamed licenses, those licenses should ideally be created as new items in Wikidata (with full work available at URL (P953) used to link to the license text if available), even if they're only ever linked to by one software item. License items can then be subclasses of a "free and open source software license" item. I'm sure there are multiple different interpretations of "free" and "open source" which this approach supports. Pixeldomain (talk) 00:02, 8 January 2018 (UTC)[reply]
 Comment Trying to develop the concept to identify free software starting from their licenses (Option 1). This query lists the elements having a free software license, i.e. instances of subclasses of free software license (Q3943414):
# Free software and license
SELECT ?freesw ?freeswLabel ?freelicense ?freelicenseLabel WHERE {
  ?freelicense (wdt:P31/wdt:P279*) wd:Q3943414.      # Instances of free software licenses
  ?freesw wdt:P275 ?freelicense.
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
ORDER BY ?freelicenseLabel
Try it!
Example:
NASA WorldWind (Q840415)copyright license (P275)NASA Open Source Agreement (Q6952418)
NASA Open Source Agreement (Q6952418)instance of (P31)permissive free software license (Q1437937)
permissive free software license (Q1437937)subclass of (P279)free software license (Q3943414)
hence NASA WorldWind (Q840415) is a free software since it has a free software license.
The graph of the free software licenses can be shown here --FabC (talk) 18:40, 8 January 2018 (UTC)[reply]
 Comment This only finds software under licenses listed as free software license (Q3943414) not OSI-approved license (Q1156659). See Wikidata:WikiProject_Informatics/FLOSS for a queries that finds both. -- MichaelSchoenitzer (talk) 01:28, 9 January 2018 (UTC)[reply]
 Comment That's correct Michael, the query aimed to list only the items that can be considered pure "free software". --FabC (talk) 21:23, 9 January 2018 (UTC)[reply]

Please create a wikidata item like WikiProject Software (Q15659621) and WikiProject Law (Q8486941) so this group can be added as open-source license (Q97044024)maintained by WikiProject (P6104)WikiProject FLOSS[edit]

It is not always easy to know who to contact regarding changes or suggestions, if this WikiProject has an item it can be added to properties and items that are in the purview of this project so that it is clear who to contact regarding them. Iwan.Aucamp (talk) 22:22, 7 July 2020 (UTC)[reply]

Done Q97061444 OdileB (talk) 11:09, 8 July 2020 (UTC)[reply]

@OdileB: thanks and apologeties, I only saw WikiProject Software/Free Software (Q10783254) now and I merged your item in there and linked it to this wikiproject. Iwan.Aucamp (talk) 14:09, 9 July 2020 (UTC)[reply]
Dachary
Metamorforme42
NMaia
Valerio Bozzolan
MichaelSchoenitzer
Jasc PL
LiberatorG
Dexxor
Waldyrious
Iwan.Aucamp
Airon90
Ainali
Haansn08
So9q
Tomodachi94
Zblace
Labdajiwa
Mind_Booster_Noori

Notified participants of WikiProject Informatics/FLOSS

Jupyter Notebook in Wikidata x2[edit]

Dachary
Metamorforme42
NMaia
Valerio Bozzolan
MichaelSchoenitzer
Jasc PL
LiberatorG
Dexxor
Waldyrious
Iwan.Aucamp
Airon90
Ainali
Haansn08
So9q
Tomodachi94
Zblace
Labdajiwa
Mind_Booster_Noori

Notified participants of WikiProject Informatics/FLOSS

Hello. Wikidata has two separate items for Jupyter Notebook/Jupyter notebook:

Are they in fact distinct? Should there only be one Wikidata item? Clarification would be much appreciated. Thank you! -- Oa01 (talk) 16:49, 20 November 2021 (UTC)[reply]

@Genium: Since you added Jupyter notebook file (Q70357595)different from (P1889)Jupyter Notebook (Q105099901).  – The preceding unsigned comment was added by Haansn08 (talk • contribs) at 19:56, 20 November 2021 (UTC).[reply]
I believe one of them refers to the Jupyter Notebook software project itself, and the other refers to specific instances of notebooks created with it. So I would expect that there could be items with instance of (P31)Jupyter notebook file (Q70357595) and software engine (P408)Jupyter Notebook (Q105099901). That said, I agree that this distinction is not clear from the description of the items, so they should be improved. The edits 1350166057, 1350167038 and 1350167237 IMO contributed to the ambiguity; something closer to the original description would be clearer. --Waldyrious (talk) 12:25, 21 November 2021 (UTC)[reply]
Thanks @Waldyrious:. Is there a schematic diagram that would help to explain the distinction? Also: at least 500 items link to Jupyter notebook (Q70357595). But only three items link to Jupyter Notebook (Q105099901). -- Oa01 (talk) 12:51, 21 November 2021 (UTC)[reply]
Indeed Jupyter Notebook (Q105099901) is a software to create notebooks [aka Jupyter notebook (Q70357595)]. There is also third party software to create such notebooks. I agree that the description is not clear but unfortunately a notebook is a program. I suggest to change the label of Jupyter notebook (Q70357595) to notebooks. Genium. 14:09, Nov 21, 2021 (UTC+01:00)
Another use case is uses (P2283)Jupyter notebook file (Q70357595) or describes a project that uses (P4510)Jupyter notebook file (Q70357595), on the basis of which we are using Jupyter notebook file (Q70357595) as a test case for improving the Scholia /use profiles, e.g. as per toolforge:scholia/use/Q70357595. --Daniel Mietchen (talk) 23:00, 24 March 2022 (UTC)[reply]

Property for out-of-the-box features of file managers[edit]

As far as I know, there are not properties for storing out-of-the-box features of file managers (be it console applications or GUIs). For example, these are some features that I would like to store in file managers: bulk renaming, single image preview, multiple image preview, By storing this information, we would be able to answer questions similar to: "What are some file managers that can preview images?".

If you know a property for doing this, please let me know.

Rdrg109 (talk) 03:38, 6 December 2021 (UTC)[reply]

source code repository URL (P1324) qualifiers[edit]

Dachary
Metamorforme42
NMaia
Valerio Bozzolan
MichaelSchoenitzer
Jasc PL
LiberatorG
Dexxor
Waldyrious
Iwan.Aucamp
Airon90
Ainali
Haansn08
So9q
Tomodachi94
Zblace
Labdajiwa
Mind_Booster_Noori

Notified participants of WikiProject Informatics/FLOSS and @Uzume:

I'd like to get consensus on a detail of how source code repository URL (P1324) version control system (P8423) and web interface software (P10627) qualifiers should be used. The goal is to make it easier to use this data programmatically. For example, to create a tool that can populate information about new software versions in Wikidata, or determine the number of people who have contributed code to the project, or graph the number of source lines of code over time, etc.

Previously the protocol (P2700) qualifier was used to indicate whether a particular source code repository URL (P1324) URL could be used with version control commands (e.g. git clone if protocol (P2700)Git (Q186055), svn checkout if protocol (P2700)Apache Subversion (Q46794), etc.) or only for web browser viewing (if protocol (P2700)HTTP (Q8777)). Unfortunately, since it was repurposing a qualifier used for other purposes it required reading the project-specific documentation and discussions to know what to put there, but most people didn't read that and interpreted the word "protocol" in their own way, leading it to being filled with other values like HTTPS (Q44484) or Secure Shell (Q170460) that repeat what is already in the URL while omitting the information that was intended to be conveyed by this qualifier.

It was my expectation that replacing protocol (P2700) with version control system (P8423) and web interface software (P10627) would fix this; in particular you could then indicate whether a particular source code repository URL (P1324) URL could be used with a version control system using version control system (P8423), or for web browser viewing using web interface software (P10627), or both if both qualifiers have a value, and without ambiguity since these qualifiers are used only for this purpose. So for example if you want to access the source code (e.g. you're writing that tool that graphs source lines of code over time), your code would look for a P1324 URL with a recognized P8423 qualifier value and then get the source code using that URL with the command that is appropriate for that version control system.

Since April (when the P10627 qualifier was approved), I and others have been updating the qualifiers on source code repository URL (P1324) statements; out of the 17k P1324 statements on Wikidata, over 14k now have both P8423 and P10627 filled in with either a value or "no value". The majority (>11k) of the P1324 URLs in Wikidata are GitHub repository URLs that support both Git commands and web browser viewing; for URLs that support only version control commands or only web browser viewing I have been setting the other qualifier to no value. However, I found that at least one person has a different view of these qualifiers and is setting version control system (P8423)Git (Q186055), web interface software (P10627)Gitweb (Q97460957) for a Gitweb URL that they know is not a valid Git URL and does not work with Git commands, because the underlying source that Gitweb is using to access the data is a Git repository. In particular, in Q223204#P1324, the dev.gnupg.org and github URLs support both Git commands and web browser viewing and therefore have a value for both version control system (P8423) and web interface software (P10627), but the git.gnupg.org URLs support only one or the other.

Just wanted to get consensus on the preferred way to handle this before continuing to update the remaining source code repository URL (P1324) URLs. I've listed the options that I can think of, but if I missed something feel free to offer another suggestion.

  1. The version control system (P8423) and web interface software (P10627) qualifiers on a source code repository URL (P1324) URL reflect the interfaces available to access data via the specified URL. So for example a Gitweb URL that offers a Gitweb browser interface but isn't a valid Git URL and therefore won't work with Git commands would have qualifiers version control system (P8423)no value, web interface software (P10627)Gitweb (Q97460957). If a valid Git URL is available to access the underlying Git repository directly then it should have its own separate source code repository URL (P1324) URL statement with version control system (P8423)Git (Q186055), and anything that wants to directly access the repository programmatically can ignore the URLs with no value (or an unsupported value) for version control system (P8423).
  2. The web interface software (P10627) qualifier reflects the interface that is provided when the URL is accessed via a web browser, but the version control system (P8423) qualifier reflects any underlying data source. So for example a URL that offers a Gitweb browser interface, whether or not it is a valid Git URL or works with Git commands, would have qualifiers version control system (P8423)Git (Q186055), web interface software (P10627)Gitweb (Q97460957). In order to access the repository directly you may have to try all the URLs to find one that works.
  3. As above but introduce yet another qualifier to indicate whether the URL is a valid URL for a version control system.

I personally think that option 1 makes the most sense but am interested to hear what other participants think of this. –LiberatorG (talk) 05:27, 31 May 2022 (UTC)[reply]

Thanks for the notification; consistency is definitely something we should strive for. I was about to write that option 2 isn't too bad but then I made a query and noticed that repository statements with version control system (P8423) = no value are often the preferred statement for GNU projects, e.g. GNU nano or ERC. So option 1 would be really helpful if you want to programmatically access the repository. However, option 1 is not the most intuitive. Thus, the Wikidata usage instructions (P2559) for version control system (P8423) should state very clearly how the property is meant to be used. Dexxor (talk) 07:30, 31 May 2022 (UTC)[reply]


In my opinion, there are merits to both approaches. I see source code repository URL (P1324) as representing a single entity that can be accessed in different ways (in this sense, I agree with your option 2), but it makes sense that we should allow a declarative way to determine what is the "clone URL" of a repository. The problem seems that we're overloading version control system (P8423) to mean both the underlying VCS of a repository, and the availability of the URL we choose as its primary representation (i.e. as the value of source code repository URL (P1324)) as an actual clone URL. So I would be in favor of option 3, a new qualifier for source code repository URL (P1324) that would explicitly specify the VCS clone URL. I believe that would give us the advantages of both option 1 and option 2, i.e. intuitiveness for humans and clarity for machines. --Waldyrious (talk) 09:58, 31 May 2022 (UTC)[reply]


@LiberatorG: Contrary to the belief that source code repository URL (P1324) does, should or ever used to represent a URL usable by a revision control system or any software implementation of such, I do not believe it has ever specified such directly (with or without any qualifiers). Not all revision control systems even use URLs for all such references and even among those that do, not all Uniform Resource Identifier scheme (Q37071) are even allowed here at Wikidata (e.g., BitKeeper (Q878697) can supposedly be checked out via bk clone bk://bkbits.net/bk/bugfix but bk://bkbits.net/bk/bugfix cannot be specified as a URL here; another is CVS (Q467252) which can have remote repositories but they traditionally have not been able to be specified via URLs). Previously protocol (P2700) had been used as a qualifier in a conflated way to specify the revision control system used at a repository specified by a URL and this was fixed by introducing version control system (P8423) as a replacement. protocol (P2700) has other meanings and it was determined that specifying the actually network protocol was redundant with the URL scheme provided in the source code repository URL (P1324) URL. More recently, web interface software (P10627) was introduced as a qualifier to source code repository URL (P1324) to allow one to specify the web application used by a specified URL. Not all URIs can be dereferenced via some network protocol and even those that can be, which are usually deemed URLs, can be so dereferenced via any type of software. That said, most URLs are used as web references. Even among dereferable web URLs, the software, both the server and the client, are free to interpret them differently depending on how they are dereferenced, e.g., GitHub (Q364) allows its repository URLs to be both dereferenced by web browser (Q6368) clients as well as Git (Q186055) and Apache Subversion (Q46794) clients, despite them all doing very different things during such dereferences. This establishes that a remote repository cannot always be represented by a URL and that when it can be, that URL might or might not be able to be used by a web browser and similarly it might or might not be able to be directly used by revision control software. If we want to have a means to determine when a source code repository URL (P1324) URL can be directly used by specify types of software like revision control systems or web browsers, etc., I propose we create a new qualifier. I could possibly foresee reusing web interface software (P10627) somehow but to date, it has been mostly used to specify server-side web applications (although I suppose it could be used for client-side web applications), however, I believe this would unduly conflate its currently usage. Any such new qualifier could then be used for more than just source code repository URL (P1324) URLs, it could be used to specify which software is supported to dereference a URL specified in any Wikibase claim (Q111513362). Multiple qualifiers could then be specified when appropriate and we could query for specific URLs by the software needed to use them (as you seem to want to be able to do). My current belief is that web interface software (P10627) when it specifies a value, as it is currently defined, implies that the URL can be deferenced by a web browser (Q6368) (because it specifies a web application (Q189210) or perhaps a web service (Q193424), both of which qualify as a web resource (Q3427877)) but there is no way to specify that a URL can be deferenced by something else. Some URLs are obvious via their URL scheme like git://, svn:// and bk://, etc. Much less obvious are ones like https:// and https://, etc. —Uzume (talk) 19:45, 31 May 2022 (UTC)[reply]
Thanks for the extra context, @Uzume! So, to be sure I'm reading you correctly, the solution you're recommending would fit into @LiberatorG's option 3, right? Waldyrious (talk) 14:17, 2 June 2022 (UTC)[reply]
@Waldyrious: Yes, I believe it would effectively qualify under option three from above but methinks it is a better design and would also have potentially other good ramification towards even claims using other URL properties where it could also be used to specify which software is known to be able to dereference given URLs (e.g., some old websites still have pages that really only work with older Internet Explorer or a browser supporting a plug-in like Adobe Flash (Q165658), Java applet (Q865817), Microsoft Silverlight (Q489048), etc.). Such things could potentially be specified with a new qualifier and it would also effectively fix the issue LiberatorG has brought up above. As far as I see it, the other option would be to look at option one from above and instead convert version control system (P8423) to be the client software able to dereference a URL. Such a conversion would need renaming the property as well as widening up the scope of the allowed Wikibase item type to a larger range of software rather than just revision control software. At first I considered that a better option as this has been discussed much over the years and URL scheme can sometimes be redundant with such a specifier and sometimes not (e.g., earlier specifying protocol (P2700) HTTPS (Q44484) on https:// is just as redundant as specifying version control system (P8423) Git (Q186055) on git://), however, with a new qualifier we can also specify the underlying revision control system even for URLs that can only be directly dereferenced by a web browser (Q6368) (or other non-VCS software) which is common for things like ViewVC (Q927548), Gitweb (Q97460957), etc. (ug, now I am envisioning ugly things like a Adobe Flash (Q165658) or Microsoft Silverlight (Q489048) based VCS viewer; such things might be come about with new technologies like WebAssembly (Q20155677) to support the old, see things like CheerpX For Flash, OpenSilver, etc.) —Uzume (talk) 15:06, 5 June 2022 (UTC)[reply]
Great, thanks for the confirmation (and the additional info!). I agree that repurposing version control system (P8423) would not be desirable, and that a new qualifier would be a better way to allow covering the breadth of situations under discussion without sacrificing clarity for either human or machine consumers of the data. Waldyrious (talk) 21:36, 5 June 2022 (UTC)[reply]

technical requirements as property?[edit]

What would be the bast way to describe/inscribe minimum/optimum technical requirements? Is it even something that would be desirable to hold in Wikidata? (can imagine it is for Linux distros at least, but maybe also for certain type of applications) --Zblace (talk) 16:30, 6 January 2023 (UTC)[reply]

Specifying that they are "minimal" seems useful to me. Maybe "Minimal Technical Recommended requirements". Having said that we probably will never get to a level where this data will be useful to be able to make a comparison and choose a software. This data should only be useful individually, to understand given a software, what hardware to give them. Most video conferencing software for example have really very much entropy of possible combinations, and a rigid comparison such as ours (server CPU frequency + CPU cores + RAM + network bandwidth + storage I/O bandwidth + bandwith per month?) would probably never be enough to describe the situation widely and sufficiently and many people would often disagree to the data. A review page on Wikibooks or similar would be probably much more accurate than a Wikidata raw scheme. Valerio Bozzolan (talk) 07:47, 13 April 2023 (UTC)[reply]
See also Wikidata:Property proposal/system requirements. Jean-Fred (talk) 15:37, 13 April 2023 (UTC)[reply]

How should software under the BUSL-1.1 be handled ?[edit]

Hi, people might have seen the news about Hashicorp starting to use a license for most of their products. I started to tag the entries with the proper license (I created the items for the Business Source License 1.1 (Q121359688), I would appreciate a double and triple check on both the item and the tagging), but how should instance of (P31) be handled for the softwares ? For example, Vagrant (Q7725312) is still listed as free and open-source software (Q506883), which I think is misleading because newer versions are not, and wouldn't be for 4 years. But the existing released ones are still FOSS, so I can't just remove that. And the versions will be re-licensed in the future, due to a clause in the BUSL. Is there a existing example I could reuse ? (as the license wasn't in WD, I assumed there isn't ) Misc (talk) 14:21, 11 August 2023 (UTC)[reply]

> And the versions will be re-licensed in the future, due to a clause in the BUSL.
I'm not sure what you mean "re-licensed"? Once a software is published under a Free Software license, this cannot be revoked. Do you mean something else? Dachary (talk) 09:47, 4 October 2023 (UTC)[reply]
Now I get what the question is. In the case of hashcorp products, all versions for the next four years will not be Free Software and that gives us a little time to figure that out. Dachary (talk) 09:54, 4 October 2023 (UTC)[reply]
I think it would make sense to consider that Vagrant (and other BUSL licensed software) are two different software instead of one. Just like it is done for Open Core software where you have a proprietary version and a Free Software version. They are effectively two different products. In 2027 there will be a Free Software distribution of vagrant as it exists in 2023 which is going to be significantly different from the distribution of vagrant developed in 2027.
So, I would propose to create a new item for the BUSL version of Vagrant, where all proprietary versions are documented and recorded. For the next four years it will be the only one getting updates while the existing Vagrant (Q7725312) will not be updated since there are no Free Software version published. On 2027 Vagrant (Q7725312) can start getting updates again. And from then on the two entries are updated, four years apart.
Does that sound like a sensible way to approach this? Dachary (talk) 10:03, 4 October 2023 (UTC)[reply]
No, I do not think that's a good way. It would be a one-off modelling for that specific case, which would cause a bunch of problem on downstream data users. For example, having 2 items is going to be problematic for wikipedias using wikidata for infoboxes, as they would likely need information from both. If I take the french WP as a example, the latest version would be coming from the BUSL item, while the initial version would come from the non-BUSL one (unless the information is duplicated, but that's asking for trouble and make the item even more complex). It would requires specific code to handle the 10 or so items potentially using this scheme (as there isn't that much BUSL software).
Having to also keep the 2 items in sync in a variable number of years also mean that the task will be forgotten and result in stale/incorrect data in a systemic way, again something we want to avoid. --Misc (talk) 16:02, 4 October 2023 (UTC)[reply]

Move the organizations policy properties to a different section[edit]

free/libre open source software usage policy URL (P9771) and free/libre open source software development policy URL (P9904) are properties that apply to organizations and they are used in the context of less than a dozen of such organizations at this date. It relates to policies the organization applies regarding its relationship with Free Software, either for using it or developing it.

The focus of the FOSS project is on software released under a Free Software license. It is not about organizations and none of these properties can be used as claims or qualifiers for any software. For this reason they should be moved to a different section. There is value in keeping them around because they are of interest in the context of the FOSS project, for cross reference purposes. Dachary (talk) 09:40, 4 October 2023 (UTC)[reply]

That makes sense, Thank you! Natct (talk) 09:14, 18 October 2023 (UTC)[reply]
Agreed, they fit perhaps under something like "See also" or "Related properties". Ainali (talk) 13:25, 20 October 2023 (UTC)[reply]

Taxonomy of LUG, GLUG (User Groups)[edit]

Since we have the opportunity to help Wikidata in reflecting the real-life, and because in real-life there are well-known naming controversies over "LUG" or "GLUG", I'm looking for a compromise here:

Talk:Q1138237#"Linux User Group" vs "GNU/Linux User Group"

Thanks for any additional eye --Valerio Bozzolan (talk) 11:46, 16 October 2023 (UTC)[reply]

It would be worth explaining how this request is related to the FLOSS project. I'm sorry but I can't make the link just by myself. Thank you for your help! Dachary (talk) 09:10, 18 October 2023 (UTC)[reply]
@Dachary These are groups for FLOSS software and they have Wikidata items. That is the connection. Ainali (talk) 17:30, 20 February 2024 (UTC)[reply]

DYNE Foundation[edit]

I just created Q124618885‎ for Dyne Foundation as I realized they are not on Wikimedia though they are prominent European FLOSS developer and advocate for software autonomy. If anyone is able to help documenting their work that would be most appreciated. I wanted to do more in this directions but failed to find time and focus in past months...and now I try to defend need for such category on EN Wikipedia, but even on Wikidata there seems to be not much info available :-/

Dachary
Metamorforme42
NMaia
Valerio Bozzolan
MichaelSchoenitzer
Jasc PL
LiberatorG
Dexxor
Waldyrious
Iwan.Aucamp
Airon90
Ainali
Haansn08
So9q
Tomodachi94
Zblace
Labdajiwa
Mind_Booster_Noori

Notified participants of WikiProject Informatics/FLOSS Zblace (talk) 06:57, 20 February 2024 (UTC)[reply]

@Zblace the description is odd. What is a "Think &do tank and free software foundry"? Also, we usually don't put long sentences in brackets in the description. Just make it brief and easy to disambiguate from something with a similar name. Ainali (talk) 17:28, 20 February 2024 (UTC)[reply]
@Ainali I reduced it. Think Thank is known term andDO means that they also do practice that materializes that thinking....like developing software and hosting content. Zblace (talk) 19:28, 20 February 2024 (UTC)[reply]
@Zblace And there is not a missing space between "&" and "do"? Ainali (talk) 09:09, 21 February 2024 (UTC)[reply]
@Ainali i just trunscribed, thinking it exists as neo-logism that does not follow language norms :-) Zblace (talk) 11:15, 14 March 2024 (UTC)[reply]

Documenting notable software in use by organizations[edit]

Premising that on Meta-wiki we are trying to document notable software in use by notable organizations:

m:FLOSS-Exchange/Matrix

Questions:

  1. Is this kind of information in the scope of Wikidata, in your opinion?
    → Probably yes in some ways. At least in documenting Wikimedia organizations, should be in-scope.
  2. if yes, is the property "uses (P2283)" somehow suitable to catalogue notable software adopted by an organization?
    Example:
    Wikimedia France (Q8423370)uses (P2283)BigBlueButton (Q4904858)
    Wikimedia Italia (Q15136611)uses (P2283)BigBlueButton (Q4904858)start time (P580)July 2020
    Wikimedia Foundation (Q180)uses (P2283)Zoom (Q94979732)
    → Probably yes in some ways.
  3. If no, what would be a good name of a new property, in your opinion?
    "Software in use"?
    "Software adopted"?
    ...

Thank you so much for any comment :) Thanks to User:Ferdi2005 and User:Waldyrious and User:Ederporto who already shared early useful feedback \o/ --Valerio Bozzolan (talk) 20:18, 2 May 2024 (UTC)[reply]

start date:Dragon Ball? I assume that should be 2020 :)
For 1. it should be worth keeping in mind that there are no special rules for Wikimedia organizations on Wikidata. It might fit better in another Wikibase, perhaps even on MetaBase. Ainali (talk) 13:21, 3 May 2024 (UTC)[reply]
rotfl. "Dragon Ball" is the new "2020". Feel free to fix it, if you know how. Yeah, no special rules. That is why the question n. "1." but I think your answer is "probably not in scope" (?). Thanks for the suggestion of MetaBase! Super-interesting. I was unaware of that. Registering there. Valerio Bozzolan (talk) 11:09, 4 May 2024 (UTC)[reply]
Thanks again, we are also exploring Metabase:
https://metabase.wikibase.cloud/wiki/Talk:Main_Page#Using_Metabase_to_Document_Software_in_use_by_Wikimedia_Organizations Valerio Bozzolan (talk) 11:35, 4 May 2024 (UTC)[reply]
Yes, probably not in scope as you are unlikely to find a non-self-published source verifying the claim. Ainali (talk) 11:55, 12 May 2024 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata_talk:WikiProject_Informatics/FLOSS&oldid=2152278405"