Though it’s taken for granted, I suddenly became curious: in the world of open-source programming languages such as Julia, how are the intellectual property rights of its package developers protected?
For instance, if a developer creates a Julia package and uploads its code to GitHub as a public repository, how does he prevent others from plagiarizing his code to develop new packages, or extracting its principles for academic publications, or for commercial purposes? Can a Julia package be cited as a reference in academic papers? If so, how should it be cited? What would be the appropriate citation format? If one develops a Julia package with some academic significance, should it be made public after the publication of the associated paper? If so, how should it be linked in the paper?
In Julia’s world, what are the mechanisms behind all of this?
If you can cite a software package in an academic paper depends more on your Journal. But in general, you can simply put a ref link in your text, or you cite a Zenodo record, or a JuliaCon Proceedings paper if there exists one, …
Also, if you develop source code for a scientific paper, it depends on your journal whether it has to be made public or not. In general, I try to always publish source code for a scientific work which contain large parts of programming. How should you reproduce it without having access to the code?
Take DifferentialEquations.jl as an example.They indicate the license and also a scientific publication which you can cite if you use this package.
There’s nothing special about Julia with any of this
how are the intellectual property rights of its package developers protected?
If you have intellectual property rights, it would be up to you to protect them. You’d have to identify people violating your IP rights and take legal action
For instance, if a developer creates a Julia package and uploads its code to GitHub as a public repository, how does he prevent others from plagiarizing
That would be scientific misconduct, and you should report it to the journal/university
his code to develop new packages, or extracting its principles for academic publications, or for commercial purposes?
These would be governed by the license you choose, although with open source, “develop new packages” is mostly what you want to encourage.
Can a Julia package be cited as a reference in academic papers? If so, how should it be cited? What would be the appropriate citation format?
If in doubt, contact the authors. If there is a paper associated with the package, cite that. Otherwise, follow the guidelines of the journal you’re publishing in. Generally, I go with <Name of Maintainer> and Contributors, <Name of Package>, <Github URL> (Year of last release)
If one develops a Julia package with some academic significance, should it be made public after the publication of the associated paper?
I personally try to have citable papers for the more prominent packages of mine, and at least Zenodo-DOIs for the others.
That way you can always cite something, where I would prefer if one cites the publication for sure.
Concering publication of code – I usually upload code that accompanies a paper of mine shortly after putting the preprint on arXiv (shorty == after I had some time to polish the code a bit in style).
To be clear: I was making a distinction between a package that has an associated paper (making the package citable), and a paper that has some associated code (like a bunch of scripts / Jupyter notebooks / prototype implementations). A package you would want to make public before you publish a paper about it, or even a preprint. Making sure that the package name is acceptable for registration is just one reason. You also want a package you write a paper about somewhat “mature”, which requires some engagement with the package. Typically, publishing a paper about a package is when you’d want to go from <1.0 versions to v1.0.0.
Code or data that accompanies an arbitrary paper is different. That code you would publish together with the preprint or publication. You’d want to have reviewers of the paper to have access to it. It should be a GitHub repo, and maybe have a Zenodo-DOI as a true stamp of immutability, but it generally wouldn’t be a published package – even if it might grow into a published package at some later point.
As an accademic package author, I usually try to publish a paper describing the package.
IMO, the package should be made public as soon as possible. Having users is the best way to improve the package anyway. And if you’re lucky you can get people to contribute to the package, making it better and increasing it’s impact.
I am delighted to see everyone’s responses, and I am immensely grateful for the invaluable insights!
Now, I would like to inquire about another scenario: If someone uses Julia to implement methods from another person’s paper and uploads it to GitHub, or creates a Julia version of an existing software package written in another language by someone else, is it necessary to obtain the original author’s consent? To whom does the ownership of the final product belong?
In the US (and much of the world), everything you write has a copyright. Everything anyone writes has a copyright. Open source licenses explicitly give permission to others to use/modify/copy without fear of a copyright infringement suit.
Generally, a source-to-source translation is considered a “modification” that would be considered a copyright violation without such permission. Thus, direct translations of existing code should typically preserve original authorship and licensing — note that pretty much all open source licenses require you to preserve the copyright notice (without which you wouldn’t know who licensed it to you) and allow you to redistribute and relicense the materials. If there’s no such license already granted to you, then, yes, you must ask the original author. If you already have such a license, it can still be cool to thank the person.
Also generally, abstract algorithms are not considered part of the copyright (but patents can be messy). If a paper or someone else describes the general algorithm and you implement new code from that description without looking at a proprietary or more-strictly-licensed-than-you’d-like implementation, then your implementation is considered your own work and you can license it as you’d like. This is called a “clean room” implementation.
This is not legal advice. I am not a lawyer. I am not your lawyer.
they should acknowledge the original paper, but that’s it
or creates a Julia version of an existing software package written in another language by someone else, is it necessary to obtain the original author’s consent?
“Translation” is a gray area, legally. If you are sticking to the terms of the orignal license, you’re definitely fine. If you’re going beyond the original license, you should ask permission. Although the risk of actually getting sued over it may be near zero, so make your own common-sense decisions (or consult with a copyright lawyer)
To whom does the ownership of the final product belong?
Generally to you, assuming the original license was sufficiently permissive. But you may still have to give attribution to the original work. That’s for the code. In acadamia, you always have to give attribution to original work, no matter the license, or it’s plagiarism. But plagiarism is distinct from copyright.
That’s not correct, not as I understand it. Copyrights in open source are generally additive, and everyone in the chain (including translations and other derived works) hold some of the ownership unless it was explicitly assigned away with a CLA or somesuch.
For example, Julia’s ryu implementation was a direct translation from a C implementation written by Ulf Adams and others and licensed for use. When Jacob Quinn converted this to Julia, it was a derived work of Ulf’s copyrighted code. Now both Ulf and Jacob have contributed to the copyright and both have “ownership” claim of the code. Another dozen or so Julia contributors have continued working on this code, each adding their own copyrighted work (and explicitly licensing it for use as they submit it to the project). Note that the permissions in the licenses are explicitly granted upon “obtaining a copy” — so as long as this continues to be distributed folks will continue to receive license to use and modify and redistribute.
It should be noted that “derived work” (at least when it comes to software) is not at all a well-defined term in the legal sense. Specifically, the extent of the modification required to be (or not to be) considered “derivative” is open to interpretation. In the end, a dispute comes down to specifics of each case, and interpretations differ heavily by jurisdiction.
E.g. the EUPL even goes so far as explicitly calling out that it depends on the country the licensor is based in, falling back to Belgian law if the licensor is outside the EU.
‘Derivative Works’: the works or software that could be created by the
Licensee, based upon the Original Work or modifications thereof. This Licence does not define the extent of modification or dependence on the Original Work required in order to classify a work as a Derivative Work; this extent is determined by copyright law applicable in the country mentioned in Article 15.
Applicable Law
Without prejudice to specific agreement between parties,
this Licence shall be governed by the law of the European Union Member State where the Licensor has his seat, resides or has his registered office,
this licence shall be governed by Belgian law if the Licensor has no seat, residence or registered office inside a European Union Member State.
Sure, but since this entire house of cards is predicated on the risk of someone suing you or not, it seems wise to hedge conservative in the absence of more solid legal footing. Having the legality of your code (and a good chunk of your personal or corporate worth) depend upon a particular jurisdiction or interpretation by a judge or jury ain’t a situation I want to find any of us in.
Since you’re talking about the EUPL: it grants you the right to create derivative works, even as it says it’s poorly defined! So if you can comply with the obligations it imposes, why wouldn’t you? And if you can’t comply, then maybe you shouldn’t create or distribute such a work unless you have a legal team and deep pockets.
In many cases, the obligations of the license are much less cumbersome — often as minimal as preserving the original copyright statement.
You seem to think I’m disagreeing with your overall point - that is not the case, I fully agree that it’s up to each licensee to make sure they comply with the license. I only wanted to expand on the term “derivative work”, which could be read as being a well-defined thing from your explanation, which is not the case.
When it comes down to it, a court might very well decide that the language of implementation is no longer the same and any modifications required to make it work were substantial enough to warrant no longer being called derivative.
Like it or not, that’s the situation international copyright is currently in In Google v. Oracle, the ultimate decision famously skirted around defining “derivative work” explicitly, and rather only ruled on the specific case. German law even has multiple kinds of “derivative work” (article in german), each subtly different (in particular, under german law when you edit a piece of code, you only gain copyright on your edit, not on the piece at large). European law at large is not really streamlined in this regard either, and never has been.
Sure, and to circle it back around to the original topic: The IP rights of Julia package developers are only insofar protected as those developers are willing to go to protect them. Copyright law is a cruel world.
You seem to think I’m disagreeing with you - that is not the case. I’m in violent apathy.
I love a good bit of legal-technical pedantry myself, but the fuzziness of these terms doesn’t matter unless you’re willing to go to court. The common interpretation is that folks consider translations to require permission from the original copyright holder. 1234…
What various online fora and the GNU foundation think exactly constitutes a “derivative work” doesn’t really matter to a court though (not to mention the usually overly america-centric perspective on the matter). I’m trusting the EU lawyers who’ve written the EUPL on this one, by deferring to the relevant copyright law of the licensors country in question
I would be rather surprised if the basic copyright doctrine that an author holds copyright over translations of his or her work wasn’t the law in any EU member state. In fact I would be willing to bet you twenty Euros that this is the case. Translations from one (human) language to another are the paradigm of a derivative work, the original situation to which the term was applied is just that, translation.
There’s nothing particularly America-centric about this, it was established in the Berne Convention which, I believe, you’ll find that whichever jurisdiction you were hoping to count on is signatory to.
Oracle vs. Google is about a different question of law, whether an original program which uses an API from another program is a derivative work or can be a clean-room implementation, this is an actual edge case.
A source-to-source translation is not an edge case, it is a cut-and-dried derivative work, because, again, translations of copyrighted material into a different language were the original derivative work, the entire legal doctrine (yes, on the Continent as well, and originally) is based on that question.
That is to say, this:
Is vanishingly unlikely. It’s rather easy to cooperate with the licensing terms of open-source software, and yes, most developers are unlikely to pursue a lawsuit, let alone across national lines. But this has no bearing at all on what the law is.
The Berne convention has unfortunately been written without modern computers in mind; let me give an example of where “translation” in the literary sense (as was originally meant) can be really weird to apply.
Say you have a program written originally in Prolog, describing the conditions necessary to solve a particular problem, as well as another implementation taking those conditions and vastly changing them to solve that particular problem (perhaps more efficiently) in another imperative programming language. Is that “translation” under copyright law, that is, is it a derivative work? As far as I know, this is the crux of the matter and why everything hinges on “the extent of the modification”, which isn’t settled law (to the best of my knowledge). This case isn’t really comparable anymore to translating a book from french to spanish, or translating a literary work to braille, which is exempt from copyright in pretty much all countries that are signatory to the Berne convention (let’s not think about the implications for software copyright if you were to translate source code to braille, or whether reproducing source code on the internet and making it accessible to screen-readers falls under the Marrakesh convention). This hinges on interpretation what exactly is the fundamental essence contained in the original Prolog, whether that is copyrightable, and whether using that in another implementation is a derivative work.
Sure, one-to-one source-to-source translations are the easiest to apply the convention too, but those are not the only cases copyright can cover.
Yes, definitely. In the cases of licenses like GPL or EUPL you’re pretty much always on the safe side if you just apply the same license to your translation/modification that the original work had. It’s also the nice thing to do, to continue sharing what you built, no matter what it’s based on.
If you’re doing really large scale modifications though, it’s much less clear-cut whether you’re really obliged to do that (that being said, the vast majority of “modifications” that happen in software are likely not substantial enough to fall outside of being derivative).
The question of how much difference between one work and another makes it a transformative work can’t really be settled in advance, this is a fact about copyright law, not source code specifically. What is on solid ground in both source and natural language works is that translation is not transformative, it’s derivative.
If the originating party is upset enough to sue, this is settled on a case-by-case basis. It gets very expensive.
An interesting wrinkle in copyright law, to be sure. I would wager that attempts to use this as a loophole in source code copyright would go poorly, but again, ultimately, torts are decided by judges, in court, with lawyers. Or sometimes by the bankruptcy of one of the parties forcing them to end the case because they ran out of money. Lawsuits are expensive.
I’m really only interested in the question of translation here, copyright law is an enormous field, and where the boundaries lie with respect to source code in particular isn’t something which can be cleanly determined without a lawsuit. Just the nature of the beast.
But it’s worth noting that first translating, then modifying (perhaps extensively) a copyrighted work is a translation, primarily, from the law’s perspective, making it no different from extensively modifying the original source: it doesn’t matter what percentage of the lines you’ve changed, your work must respect the original license. Given the widespread use of git, this can be fairly easy to demonstrate during the discovery phase of a ruinously expensive lawsuit. Trying to evade this sort of thing, by, say, making a fresh git repo containing no history of the code, as though it burst forth from one’s forehead, is the sort of shenanigan judges look rather poorly upon.
The question of what a judge would decide about your Prolog example would hinge upon the history of the repo, not just its final form. Revision control is so ubiquitous that a lack of such history (especially if the prosecution can show that one is otherwise in the habit of using it) would likely be taken to indicate that one is concealing evidence. But sure, who knows what they might ultimately decide. Someone might win, after spending six figures and a few weeks defending yourself in court. Or lose and have to pay damages.
The question of what someone should do here is, I think, much easier to answer. Adhere to the terms of the license of the original code. For the permissive licenses most common in Julian circles this is as simple as copying over a copyright notice. For GPL, of course, you must choose your license to match theirs, which is why I refuse to even look at the stuff.
In 