Should JOSS publish papers on code that relies on proprietary software/programming environments?

[labarba]

We haven't discussed the limits on scope for the journal regarding code submissions that rely on a proprietary library or runtime.

What if the submitted code is itself open source, but it relies on a runtime that is closed and a paid product? (The typical example is MATLAB code.) It can be argued that even though the submitted code is open source, it does not integrate with an open-source software stack, thereby inflicting a barrier on users.

It is my personal opinion that such code submissions are not really open (and we should not publish them). We recently had a similar discussion in the NumFOCUS board, and decided that such projects would not be eligible for fiscal sponsorship under the NumFOCUS umbrella.

What do other editors think?

[cMadan]

I think it depends on the availability of the paid product. In the case of MATLAB, most relevant educational institutions provide access via an institutional license or in specific computer labs (along with first-party toolboxes). If the code required a less common paid product, I can agree with not accepting them at JOSS. However, this does bring up the fuzzy issue of how to judge if the required product is 'common' or not.

As an an editor, I do think that using MATLAB is acceptable, but I am biased in that MATLAB is my main programming language. (And biased in that this issue originated from review of a submission of mine.)

[arfon]

What do other editors think?

I favour a slightly more lenient approach here: I think relying upon a proprietary runtime is acceptable as long as it is possible for the reviewer to complete the review process:

[ ] Installation: Does installation proceed as outlined in the documentation? [ ] Functionality: Have the functional claims of the software been confirmed? [ ] Performance: Have any performance claims of the software been confirmed?

While I would rather see everyone using open source languages I think we should recognize that this is not a realistic option for many researchers in the near-term.

It also occurs to me that encouraging contributions to the open source ecosystem (as JOSS papers) in these communities that rely upon closed-source/proprietary runtime environments can only serve to elevate the role of open source in the long term.

[labarba]

most relevant educational institutions provide access via an institutional license

Do you have data to back that up?

And what about non-educational institutions? Should we call open software that is only available in (select) educational institutions?

It is true that The Mathworks have done aggressive marketing in universities, which is reflected in the institutional access and cheap licenses for students. This availability disappears when students graduate, and this is a problem in my eyes.

[pjotrp]

I am against it because it prohibits people from running the code. Including reviewers. Also there are people in countries that don't have the money for these tools. @biorelated what is your view here?

[danielskatz]

I'm also mildly against it.

On Jun 27, 2016, at 12:51, Pjotr Prins notifications@github.com<mailto:notifications@github.com> wrote:

I am against it because it prohibits people from running the code. Including reviewers. Also there are people in countries that don't have the money for these tools. @biorelatedhttps://github.com/biorelated what is your view here?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/openjournals/joss/issues/142#issuecomment-228804891, or mute the threadhttps://github.com/notifications/unsubscribe/ACx2NTqeQR-9rAylF5rVnSMd6-JpEueZks5qP_9kgaJpZM4I_R4T.

[kyleniemeyer]

I second @danielskatz's "mild" opposition (sorry @cMadan 😦)

I don't think we need to put a blanket limit against, e.g., MATLAB code, because an open-source interpreter does exist in that case (Octave). However, not all MATLAB code will run in Octave without some work, particularly if it depends on proprietary libraries.

@arfon In response to your requirements for the review process, what happens when someone best qualified to review doesn't have access to the runtime or libraries? Or if someone submits an open-source software package that relies on something less "common" than MATLAB, but is otherwise similar to the current situation in question? I imagine we wouldn't accept something that none of the reviewers could install or run, even if the submitter (and possibly certain other institutions) did have access. Therefore, MATLAB (in the current example) would in a sense be given a pass simply because of its popularity.

I absolutely agree that we want to encourage contributions to the open-source ecosystem—which I think JOSS does through its very existence—but don't we also want to encourage a fully open software stack? And, therefore, discourage one that isn't fully open?

(OK, through the course of writing that, I think my opposition escalated slightly.)

[pjotrp]

Free and Open Source Software is just that. JOSS is for FOSS. When there is a requirement for non-free software we should not accept that because it prevents people from using and auditing the software. Even a platform as Windows or Microsoft Excel is not acceptable. FOSS software has to be made available for other platforms for everyone to use.

I may sound extreme, but I am actually pragmatic. In the rich world we live in a cocoon when we think all the resources are 'free' to us. 80% of the students, teachers and researchers are not able to Matlab or SPSS because of its costs. So, software built on that belongs in the rich world. It does not belong in a journal that promotes FOSS.

[cMadan]

While free 'dependencies' would definitely be preferable, I think the bigger issue is if JOSS is built around open science practices or FOSS. I was excited when JOSS launched as it provided a venue for publishing my analysis code as toolboxes that others can use and modify in their own work, while also counting as being 'published' in a journal. However, if this is insufficient and JOSS also requires that all dependencies be free and open, this is a very important distinction.

There are ideals, but there are also practicalities--I can't program in other languages nearly as well as I can in MATLAB, so I won't be re-writing my code to Python for the sake of open science, I would just be ostracized from publishing it via JOSS. Additionally, the particular submission that brought up this issue requires a freely available third-party MATLAB toolbox. I don't know for sure if that works in Octave, but if it does not, the point goes further in that even though free (GPLv2), anything using that code would also be not publishable at JOSS without re-writing the code into another language.

If no reviewers are able to run the submitted code, I agree that it couldn't be accepted at JOSS. It clearly would be preferable if no paid products were dependencies for submissions, but I feel it is too extreme to enforce this as a journal policy--effectively discouraging open science practices unless an individual adopts another language.

[pjotrp]

At the moment we sit between writing software for science that is available to all (my view) and publishing papers on free software that sits on dependencies that cost money. I understand @arfon's point that we should encourge people to publish their code thereby hopefully encouraging them to change their ways. @cMadan I am sure you don't mean to really say that you won't change your ways just because you won't learn Python so as to share you great gift with others ;).

My suggestion is as follows: we should make it a point to state clearly that we prefer and encourage FOSS software that does not depend on proprietary closed source tools, and certainly not on tools that cost money for mentioned reasons (limited audience, hampered auditing). Meanwhile we create a loop hole that we can allow such contributions, provided the authors help the reviewers run the tools - i.e., by providing access to such tools. We can not ask JOSS or reviewers to buy the licenses.

How does that sound? I think that is pretty fair. I know of at least one paper in another journal that got rejected because the reviewers could not run matlab. Why would be be different? We need to be able to audit the software.

[george-githinji]

One can make an argument that work derived from proprietary environment should automatically get disqualified. But again what is the role of a journal? JOSS is a journal, and as a journal it has a mandate to welcome, share and make knowledge accessible. As long as the author is willing to provide the full source code and disclose proprietary pieces, then his work should be accepted and published. If the work meets and passes the review criteria and as long as the proprietary licence does not restrict the author from providing his code or works derived from it under a FOSS license, it should be acceptable for publication. I agree that some of the proprietary runtimes may not be accessible to people with less income, but I feel that is a separate issue.

[pjotrp]

Thanks @biorelated.To add one more thing, I am less principled than I may sound (though I don't think we should underestimate the importance of free software). I actually champion the idea of a journal that accepts all comers (provided the software is FOSS, there is some scientific contribution and the coding is non-trivial). I strongly believe that papers, even blogs, that are great, simply drift to the top and get cited.

The rest drops off the radar. Out of the 100K+ scientific papers that get published annually, how many are actually relevant?

That is closer to PLOS ONE. Great software begets great papers. JOSS can accentuate FOSS and ask people in review to opt for a free platform the next time. The reviewers should be able to run the software. If we publish 1,000 paper per year, I am sure there will be quite a few great ones.

[Kevin-Mattheus-Moerman]

I agree that reliance on proprietary components should be minimized and we should fly the "free and open-source flag" as high as we can. However, in reality I think we cannot completely avoid codes relying on some proprietary components.

Software works relying on proprietary components should be allowed as long as they follow the OSI definitions of open-source (which includes software relying on proprietary programming environments) and there are reviewers available.

That reviewers need to be available is of course true for all software in general. I.e. there may be various exotic and rare free programming languages for which we may never have reviewers. Or programming languages that have gone out of fashion.

A "proprietary component" can be a proprietary programming environment (e.g. MATLAB, LabView, Mathematica), another closed-source software package (e.g. I know of people developing Python code to create input files for, and process output from, closed-source analysis software) or even hardware (e.g. control software for robotic devices, control software for MRI scanners). Again, I feel as longs as there are reviewers available, and the software submissions themselves follow OSI definitions, I think they are suitable for JOSS.

Side notes/tangents: 1) Out of interest. Are most FOSS projects actually free and open-source "all the way down" (as in "turtles all the way down")? Or would one hit a wall at some built-in code or a set of ones and zeros one could not openly or humanly read?

2) @labarba touched upon fiscal sponsorship of projects. This is a different discussion but I actually feel special funding should be made available to help people switch to free and open-source tools. Currently at all of the institutions I worked with or for, a campus wide MATLAB license was available. So in that sense MATLAB has always appeared free to me and my colleagues. I am not saying this is a good thing. This probably comes out of our research money in some automated way and we cannot opt-out. It also removes any incentive from me and my peers to even try to switch to stuff like Python (I would love to though). I mainly work with MATLAB and I've calculated that it would take me at least 3 months to switch all my skills and tools from MATLAB to Python (while probably hardly advancing the research I should be doing). As a post doctoral researcher I simply cannot invest that amount of time in translating to another language to do the same thing I am already doing. Agreed it would be more open but my superiors would see it as a waste of time. Unless we could actually opt-out of these licenses e.g. as a department or research group. Alternatively there should be dedicated funding available to help research groups switch to open and free tools. The additional funding would help bridge the sluggish translation period. Once the open-source tools are in place it could self amplify in a department, e.g. I'd be teaching new research students Python instead of MATLAB.

[bachmeil]

I recently had a coauthor send a program that runs on Matlab (but not Octave). I cannot currently run that software because Matlab is not installed on my machine. Even if I had my department pay for a Matlab installation for this one project, I would only be able to work on the paper in my office.

I don't understand the connection to "open source" in that case except as a marketing tool. It's true that this isn't an issue for well-funded research universities. I just don't see the connection to open source.

[oheim]

Compared to a classic journal the JOSS paper with proprietary dependencies would still be superior, since the published software itself is free and you could study and migrate it. This is much more than I can expect from common scientific software nowadays. Of course there'd be a practical problem to review it, but you'd have similar problems if I proposed a software which has other exotic dependencies (like it only operates in a power plant, in a submarine, in space, …).

IMO, there is no need to accept such a paper. If the software shall be free, it is easy for the author to get rid of proprietary dependencies nowadays. For example, if it is written in the popular Matlab language, it should be easy to get it to run in Octave with little effort. To request this extra effort from the author would benefit the software and in turn the users.

There might be corner cases where you have no replacement for some non-free dependency. So I'd say “no” to non-free dependencies unless one has a very good reason.

[dimpase]

While I am not an editor, I'd like to remark that I worked at several respectable institutions that did not have campus-wide Matlab licenses available; e.g. MSRI did not have Matlab, CS Department of the University of Frankfurt did not have it, Nanyang Technological University (Singapore) did not have it. Before stopping using Matlab all together, I had to use pirated copies to go on with some projects...

To give you more extreme case, let us talk about Magma software. While it's currently sponsored by Simons Foundation in US, it does cost a foot and a leg elsewhere; and as it's less popular than Matlab, chances that you have a campus license are about 0.

[arfon]

Thanks for all the feedback everyone. For me, this topic comes down to 'what is the purpose of JOSS?'. A non-exhaustive list of possible answers to this question includes (no priority order here):

1. To promote open source software in academia
2. To improve the reproducibility of academic research
3. To improve the quality of research software
4. To improve the 'citability' of research software/embed research software in the scholarly ecosystem
5. To enable researchers writing research code to receive career credit for their work

For me, the last one in this list is the most important one by quite some way.

As @cMadan asked earlier:

While free 'dependencies' would definitely be preferable, I think the bigger issue is if JOSS is built around open science practices or FOSS.

I care passionately about open source, and its role in academia and the software industry at large but I see JOSS as primarily as an open science journal, not a journal that adheres to strict FOSS principles. I think closed source languages are a poor choice for many researchers but they're also 1) often not the choice of the individual, particularly in the case of early-career researchers and 2) not an easy/pragmatic choice to make because of the vast amounts of existing code already written in a particular research domain.

As I see it, any open source software is better than none, and I worry that by being strictly FOSS we penalize individuals who have chosen to release open source code even if it does reply upon something closed source.

For these reasons I'm still pretty convinced we should allow submissions that rely upon a closed source/proprietary runtime environment but with the strict requirements that reviewers must be able to install and verify the functionality/performance of the package. This means that we may ask the submitting author to work hard to find reviewers for us.

In addition, as @pjotrp mentioned, I think we should add some language to state that we prefer and encourage software that doesn't rely upon proprietary environments.

How does this all sound? I would be interested to hear both opinions on this topic but also how much people care about the decision we make in this thread. I realize some people have a preference but it's not clear how strongly they feel about this decision.

[cMadan]

@arfon, I think your perspective here sounds perfect to me.

I strongly care about this decision--with MATLAB as my main programming language of interest, and likely will only submit/be part of JOSS if MATLAB-based submissions are allowed. I've also been mentioning JOSS to several people since it's launch, but restrictions against MATLAB code would make JOSS unsuitable to many of their needs as well.

I agree that FOSS is preferable and should be encouraged, but not enforced as a strict requirement.

[jakevdp]

I largely agree with @arfon's points just above: coming from a field where a lot of great work has been historically done in a less-well-known proprietary language (IDL), I feel that tying JOSS to strict FOSS principles would be too limiting. On the practical side, I think @Kevin-Mattheus-Moerman put it quite succinctly:

Software works relying on proprietary components should be allowed as long as they follow the OSI definitions of open-source (which includes software relying on proprietary programming environments) and there are reviewers available.

[pjotrp]

@arfon, @jakevdp sounds good to me. As an editor I'll add a comment in review to such papers that the authors are limiting the scope and use of their software, and they severely limit their audience (and therefore impact!) by depending on closed source expensive tools. I'll suggest to look at FOSS alternatives and consider using FOSS next time. I'll frame it nicely, but it is a form of awareness raising. Being closest to the FSF I think I am the right person to do that. I realise in Science we have to take short cuts, but scientists should at least think about and be aware about their choices. We all have a choice here and it can be done with a little extra work.

It would be good to have a general statement as part of the submission guidelines.

[labarba]

In reply to @arfon …

interested to hear both opinions on this topic but also how much people care about the decision we make in this thread

I care very much about the issue but I'm phlegmatic about the decision. The principal mission of JOSS is to patch a broken system of academic credit, where software is not valued as a product, despite being central to the progress of science. I am able to decouple this goal from my ethical stance on proprietary, closed and for-profit runtimes in academic settings.

In reply to @cMadan …

most relevant educational institutions provide access via an institutional license …

One reading of this statement is that it is awfully elitist. Which are the relevant educational institutions? And which are the irrelevant ones? Are all institutions South of the border irrelevant? In Argentina, for example, all universities are public, education is free, and all computers run FOSS. Argentina has certainly produced relevant scientists! (See the NBC article on Gabriela González, one of the leaders of LIGO). (Note: I'm not Argentinian; I'm Chilean.)

Another reading: it's based on a perception, not on data. In reality, MATLAB is available through a site license in a small minority of institutions. And outside of academia, it's a rarity. I heard from a friend who worked at NASA for many years that its popularity and availability there is tiny. We are misled by the pushy marketing of this product!

The bottom line is that this justification is a bad one:

it depends on the availability of the paid product

The justification that JOSS can help you get credit for the large time and effort invested in writing Prism, well, that I can accept.

In reply to @pjotrp …

we should make it a point to state clearly that we prefer and encourage FOSS software that does not depend on proprietary closed source tools, and certainly not on tools that cost money for mentioned reasons (limited audience, hampered auditing). Meanwhile we create a loop hole that we can allow such contributions, provided the authors help the reviewers run the tools …

I can agree to this (reluctantly). But it's important to make a strong encouragement of FOSS.

It's not just that the tools cost money and are unavailable to most researchers (most, if you count the whole world, not just US top-50 institutions). These tools have been known to have bugs in their proprietary implementations! Any code using built-in proprietary functions and toolboxes is hiding some of its implementation and cannot be fully inspected.

[pjotrp]

@labarba I agree 100%. My development toolset is 100% FOSS (turtles all the way down to Debian and GNU Guix, projects that only accept FOSS) because I want to be able to read and fix stuff. Even so, we all use closed and propriety software, such as github, gmail and skype, but as long as they are 'free to use' there are at least no cost barriers for scientists and students (don't forget the students) who don't have the money for elitist products. Then there is the security angle and bugs... Let's keep on hammering on true FOSS. It was what a reader can expect from a journal named JOSS. As a reader I would be severely disappointed if a nice paper turned out to be unusable.

One option would be to state a warning right under the title: WARNING: EVEN THOUGH THIS SOFTWARE COMPLIES WITH OSI IT DEPENDS ON COSTLY PROPRIETY SOLUTIONS.

[danielskatz]

I'm ok with this. While I would prefer as much openess as possible, I agree with your point that we are trying to do a number of things and that insisting on one of them limits our impact in others.

If our credit system worked right, authors would have a natural incentive to write software that could and would be used by as many people as possible, and JOSS is a good step in moving in that direction.

Dan

On Jun 27, 2016, at 23:23, Arfon Smith notifications@github.com<mailto:notifications@github.com> wrote:

Thanks for all the feedback everyone. For me, this topic comes down to 'what is the purpose of JOSS?'. A non-exhaustive list of possible answers to this question includes (no priority order here):

1. To promote open source software in academia
2. To improve the reproducibility of academic research
3. To improve the quality of research software
4. To improve the 'citability' of research software/embed research software in the scholarly ecosystem
5. To enable researchers writing research code to receive career credit for their work

For me, the last one in this list is the most important one by quite some way.

As @cMadanhttps://github.com/cMadan asked earlier:

While free 'dependencies' would definitely be preferable, I think the bigger issue is if JOSS is built around open science practices or FOSS.

I care passionately about open source, and its role in academia and the software industry at large but I see JOSS as primarily as an open science journal, not a journal that adheres to strict FOSS principles. I think closed source languages are a poor choice for many researchers but they're also 1) often not the choice of the individual, particularly in the case of early-career researchers and 2) not an easy/pragmatic choice to make because of the vast amounts of existing code already written in a particular research domain.

As I see it, any open source software is better than none, and I worry that by being strictly FOSS we penalize individuals who have chosen to release open source code even if it does reply upon something closed source.

For these reasons I'm still pretty convinced we should allow submissions that rely upon a closed source/proprietary runtime environment but with the strict requirements that reviewers must be able to install and verify the functionality/performance of the package. This means that we may ask the submitting author to work hard to find reviewers for us.

In addition, as @pjotrphttps://github.com/pjotrp mentioned, I think we should add some language to state that we prefer and encourage software that doesn't rely upon proprietary environments.

How does this all sound? I would be interested to hear both opinions on this topic but also how much people care about the decision we make in this thread. I realize some people have a preference but it's not clear how strongly they feel about this decision.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/openjournals/joss/issues/142#issuecomment-228938266, or mute the threadhttps://github.com/notifications/unsubscribe/ACx2NVj4BYX01-vwXjJqiA_pavZaMfWtks5qQJO1gaJpZM4I_R4T.

[bachmeil]

I'm an outsider to this journal, but as a researcher and open source advocate, I have followed JOSS and have significant concerns about this practice. Consider the following cases:

1. A researcher writes a program that requires five Matlab toolboxes.
2. Researcher A writes a program that depends on a library from Researcher B that is not open. B's program can be downloaded from her website, but there is no guarantee it will always be available.
3. Someone writes a program in Matlab that depends on a library from their own previous work, and that library is not open.
4. Someone writes a program in C++. Only part of that program is open source. The other part is a dynamic library that is called by the open source part. The author promises to make the closed part available to everyone.

[zwets]

@arfon Having worked in Africa now for four years, I feel very strongly about the decision.

Taking MATLAB as an example, the price of an individual license in Tanzania by far exceeds the average annual income of a citizen.

How many years would it take you to set aside in savings your current gross annual income? Ten maybe, if you're thrifty? Imagine what you'd have to forego for ten years, just to be able to benefit from, and make others benefit from a piece of what its author has licensed as "free software".

However well intended, that software is almost insultingly far from being free from where I look at it. I can't justify its use here, not at that cost. I certainly can't justify teaching it, or improving it for the benefit of others, as doing so will equally constrain those down the line, rather than give them more freedom, the way an unencumbered alternative would.

FOSS to me is about the freedom it creates for others more than its gratisness. Promoting or contributing to a code base which requires a non-free platform, while a FOSS alternative is available, however means that both the money and the freedom flow the wrong way (w.r.t. my personal view on how it should be): from the disadvantaged to the privileged part of the world.

@cMadan and others: please don't take this as a personal attack. I couldn't appreciate more your licensing your software under a FOSS license. It's great that it is free for many, and I know how hard it is to counter the "the institute dunnit" argument. (Been there, done it. My proposals to deduct a month's salary off anyone wanting to continue using the for-money alternative never made it ;-).)

As for the JOSS, well, the easy way out is saying that it's not called the JFOSS so the problematic Freedom which inevitably pulls in politics, economics and ethics isn't there. Debian and Ubuntu have done a lot for the propagation of FOSS, even if they support non-free repositories. Likewise, JOSS may contribute more to the uptake of FOSS in academia by accepting papers on "FOSS for non-FOSS platforms". OTOH, there is good reason for the FSF taking its staunchly principled stance, as I think my "view from Africa" illustrates. Certainly in the case where a FOSS alternative exists (without it receiving mention), a paper on a "tainted FOSS" solution will do more harm than good.

[Kevin-Mattheus-Moerman]

I largely agree with @arfon

I feel JOSS submission should be open-source as per the OSI definition. On top of that I feel it is important that we judge submissions on whether or not they are significantly useful for a significantly large scientific research community.

We can require authors to clearly indicate who may benefit from the software. We already do this but perhaps we can phrase this a bit more strongly.

There are various reasons for why a particular software may not be beneficial for a significant research community. For instance if the software is written is an obscure programming language (even if FOSS) or if the software relies heavily on very costly proprietary components.

About the proprietary programming environment MATLAB. I can personally say that in my the field of engineering all universities and institutes I have ever work for or collaborated with so far have had a full campus license (Dutch, Irish, American, Canadian). In addition MATLAB based software are widely used in my scientific community and research papers often refer to the use of MATLAB. The fact that MATLAB is not available everywhere (I have spoken to a friend from Sierra Leone who confirms what @zwets is saying, i.e. MATLAB licenses, and stuff like Elsevier subscriptions are not available there) is very unfortunate. I hope commercial companies work towards providing special offers to institutes on a tighter budget. However the fact that the environment is not available everywhere does not mean we should ignore that there is a huge research community out there that can benefit from open-source MATLAB submissions. Therefore I feel submissions created in a proprietary environment or relying on proprietary components may be acceptable.

If equivalent FOSS frameworks are available JOSS reviewers may be able to judge if translation from proprietary environments to FOSS is feasible/trivial, if so we could recommend translation of the project, e.g. from MATLAB to Octave. However this is not always trivial or even a good thing to do. For instance for my personal work Octave is like MATLAB 2004 and it would take me ~2 months to switch my tools over, and I would in many cases end up with a less efficient equivalent.

I agree we can add a message that there is a preference for open-source software that does not rely heavily on costly proprietary components. This can be formulated in the submission criteria. We can also warn that if the work can easily be translated to FOSS that our reviewers may recommend translation before accepting. However I believe one of the main criteria at JOSS should be that the software is open source and is significantly beneficial to a significantly large community. That community may be a community of users of a proprietary programming environment.

@arfon mentioned "closed source" languages. I think we should all familiarize our self with the definitions of open source vs closed source. In my opinion languages can be sufficiently open source. Not even all FOSS languages are fully open all the way down (out of interest, is the source of built-in Python codes easy to find? Is the source of cpython elements easy to find?). We can maximize openness but it is not always feasible to have stuff open all the way down. It is also not always relevant. I think it is not always fair to describe software as closed source just because it was created using a language which contains both open source and closed source components. Open source in my opinion relates to how open the key features of the software created are.

MATLAB is partially open source and partially closed source. As a result software developed in MATLAB features functions and components that are a mix of closed and open source components. In my opinion, if the key scientific achievements rely predominantly on closed source features the work can be criticized for this and is likely not a very novel/original contribution. In fact the novelty of submitted software cannot be closed source. Novel contributions have to be interesting/useful combinations of programming language elements/functions/tools, and if these developments are openly presented/given they may qualify as open source. It is up to the reviewers to judge the novelty and extend of openness of the contributions. If key claims cannot be verified due to closed source components then this is a grounds for rejecting the software submission. If the key claims are not effected by the closed source dependencies it may be acceptable.

We are in contact with the open source initiative with the intent on forming a close relationship. I'll get back to you on this shortly and open the extend of the relationship up for discussion. However for the moment I'll ask them also to give their view on this matter.

[jakevdp]

(out of interest, is the source of built-in Python codes easy to find? Is the source of cpython elements easy to find?

It's quite easy to find, e.g. https://github.com/python/cpython

[Kevin-Mattheus-Moerman]

Thanks. That is for cpython. Is it equally easy to find the source of the built-in functions, e.g. the function abs()? Or are these in the same spot? https://docs.python.org/2/library/functions.html

[labarba]

I use double question marks on IPython (usually in a code cell in Jupyter) to look at the source. E.g.

import numpy
numpy.linspace??

[jakevdp]

Well, abs(foo) essentially dispatches to the foo.__abs__() method for (almost) any Python object, so you can find the source depending on where the object is defined. If you're asking about built-in functions and modules, it's all in the repo I linked above. For example, all the functionality in from math import * is defined in Modules/_math.c.

[jakevdp]

To better answer your question, the definitions of builtin functions are in Python/bltinmodule.c

[arfon]

OK thanks for the input everyone. In conclusion I'm going to suggest that we do the following:

Add to the submission guidelines the following statements:

• We strongly prefer software that doesn't rely upon proprietary environments.
• Open source submissions that do rely upon a proprietary environment/tool are acceptable provided that it is possible to find a reviewer for the submission and that the submitting author is responsible for finding these reviewers.

Add to the reviewer guidelines:

• That the reviewer should encourage the author to consider porting their tools to be compatible with open source/free variants of the runtime e.g. Octave instead of MATLAB. (This won't be a condition of acceptance however).

If this sounds acceptable then I'll open a pull request implementing these changes and we can iterate on exact language there.

[Kevin-Mattheus-Moerman]

@arfon This sounds good.

[Kevin-Mattheus-Moerman]

Thanks @jakevdp and @labarba for enlightening me. Python really seems open all the way down.

[labarba]

@arfon --- Honestly, I would not mention MATLAB by name in any of our guidance notes. We give them free marketing! Let's make generic statements.

[dimpase]

@Kevin-Mattheus-Moerman : it is cpython; and it is in accordance with its license that you can read (and not only read!) all the sources.

Python is just a language, and there are several implementations (not all of them open-source, IMHO).

[arfon]

@arfon --- Honestly, I would not mention MATLAB by name in any of our guidance notes. We give them free marketing! Let's make generic statements.

@labarba lol, yes. Great point.

[cMadan]

@arfon - I am good with the additions to the guidelines (modified to be generic statements).

[danielskatz]

Sounds good.

On Jun 30, 2016, at 09:54, Arfon Smith notifications@github.com<mailto:notifications@github.com> wrote:

OK thanks for the input everyone. In conclusion I'm going to suggest that we do the following:

Add to the submission guidelines the following statements:

• We strongly prefer software that doesn't rely upon proprietary environments.
• Open source submissions that do rely upon a proprietary environment/tool are acceptable provided that it is possible to find a reviewer for the submission and that the submitting author is responsible for finding these reviewers.

Add to the reviewer guidelines:

• That the reviewer should encourage the author to consider porting their tools to be compatible with open source/free variants of the runtime e.g. Octave instead of MATLAB. (This won't be a condition of acceptance however).

If this sounds acceptable then I'll open a pull request implementing these changes and we can iterate on exact language there.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/openjournals/joss/issues/142#issuecomment-229683263, or mute the threadhttps://github.com/notifications/unsubscribe/ACx2NaVL4iGCBiln72_unp_DxvMSfYC8ks5qQ9iRgaJpZM4I_R4T.

[arfon]

OK I've taken a pass at this in https://github.com/openjournals/joss/pull/146 . Please feel free to suggest edits over there.

[mdnunez]

What is the TLDR of this discussion? I'm thinking of submitting a MATLAB (/Octave?) repository in the future.

[nicoguaro]

@mdnunez, it is discussed in the Journal website: http://joss.theoj.org/about

[Kevin-Mattheus-Moerman]

MATLAB submissions are welcome. Myself and @cMadan are some of the editors that use MATLAB.

Read here for submission instructions http://joss.theoj.org/about.

For authors it says:

What about submissions that rely upon proprietary languages/development environments? We strongly prefer software that doesn't rely upon proprietary (paid for) development environments/programming languages. However, provided your submission meets our submission requirements (including having a valid open source license) then we will consider your submission for review. Should your submission be accepted for review, we may ask you, the submitting author, to help us find reviewers who already have the required development environment installed.

and for reviewers:

What about submissions that rely upon proprietary languages/development environments? As outlined in our author guidelines, submissions that rely upon a proprietary/closed source language or development environment are acceptable provided that they meet the other submission requirements and that you, the reviewer, are able to install the software & verify the functionality of the submission as required by our reviewer guidelines.

If an open source or free variant of the programming language exists, feel free to encourage the submitting author to consider making their software compatible with the open source/free variant.