Just to state the point clearly - it is illegal to transcribe a package from R to Julia. Fortunately, it’s mostly unnecessary 
Without sounding too evangelical, I’ve found that the best results always comes when rethinking functionality from the bottom up in Julia.
3 Likes
ExpandingMan,
I still have doubts about illegality. The word transcribe may be inappropriate. When I say transcribing, I mean by incorporating the same statistical metrics into Julia. The incorporation will not be imitate the R and yes, write the same functions used in the statistics of the most convenient way in Julia. I also agree that transcribing characteristics of the R language to Julia is not interesting. Maybe now you see that what I mean is cool.
1 Like
This is not correct. Please don’t talk about these issues without spending sufficient time to understand the underlying issues (and even then, most people shouldn’t).
Transcribing a package is absolutely legal provided the original license is respected.
To clarify this a little more: under copyright law, by default, usage rights are very limited. A license grants more rights, provided the provisions of the license are respected. The GPL (and MIT, BSD, etc.) provides the legal right to use someone else’s copyrighted code under those specific terms.
One of the rights explicitly enumerated in the GPL is the right to modify, which is commonly understood to include rewriting with a substantially similar structure in a different language. Such a “transcribed” package would be fully legal to distribute as long as done under the GPL.
5 Likes
Respectfully, I’d say that tone is unwarranted.
Anyway, what I meant is that it is illegal to transcribe a GPL R package to Julia and release it under the MIT license. Of course there are R packages that aren’t GPL but the number is small enough to almost not matter (and both betareg and nortest are GPL). There is a strong push towards MIT in the julia community, and people tend to react less positively to GPL packages - there are ~80 packages in Metadata that are not MIT, compared to ~1350 packages that are.
Of course you are technically correct - you don’t break GPL by porting a language and releasing the port GPL. That’s they key point of that license.
2 Likes
I’m not sure why you say it is illegal to transcribe a package from R to Julia? Surely the packages WRITTEN in Julia can be under any license whatsoever? Unless they become part of base Julia, I don’t see why the language licensing would impact the licensing of the packages.
1 Like
That’s true of course. I think that’s the reason for @ihnorton 's remark as well – I was cutting short corners in my explanation. It is simply that there is a strong culture for making julia packages MIT, which cannot be used for code that is derived from GPL-licensed projects - see my comment above. Julia packages can in principle be GPL, and the most obvious advantage of doing that is that you can derive code from other GPL packages.
Maybe the reverse? MIT is GPL-compatible. And the licenses of packages don’t affect interoperability of the packages, only the fact that you might not reuse code of a package in another one.
The phrase “GPL-compatible” is a misnomer (i.e. an incorrect name): the so-called “compatibility” is only in one direction: code from a MIT-licensed project can be incorporated in a project with a GPL license (hence “compatibility” from the GPL point of view), but not vice versa: code from a GPL project cannot ever be incorporated in a project with an MIT license. (This is due to the infamous “copyleft” clause of the GPL license, which requires any derived code to be GPL licensed.)
In this respect, as stated by several people in this thread, anybody writing an MIT-licensed package must not even peek at GPL-licensed code.
2 Likes
[quote=“dpsanders, post:33, topic:4271”]
The phrase “GPL-compatible” is a misnomer (i.e. an incorrect name): the so-called “compatibility” is only in one direction: code from a MIT-licensed project can be incorporated in a project with a GPL license (hence “compatibility” from the GPL point of view), but not vice versa: code from a GPL project cannot ever be incorporated in a project with an MIT license.[/quote]
In fact I got that @mkborregaard was suggesting that MIT code cannot be used in GPL code, did I get it wrong?
I don’t quite agree with “infamous” here, but that’s probably off-topic.
I would just like to point out how completely bonkers all these licensing issues are.
At the risk of getting to philosophical, I strain to see what the “underlying math” of a particular algorithm is rather than the set of all possible implementations of said algorithm. What is the difference between writing a Julia program using a paper as a reference or writing a Julia program using R source code as a reference? Should it matter whether the paper I use as a reference is written in Mandarin as opposed to English? Regardless of how closely you mimic the R code, the Julia implementation will compile to different assembly code, so can they ever be the same?
I started writing another paragraph but it started going off on too large an angry tangent.
I’d really prefer that lawyers stay out of things that they clearly don’t understand and that legislators would occasionally aspire to some goal perhaps a little more lofty than law firm profits.
The purpose of copyleft licenses, like GPL, is to ensure that code contributed freely to an open-source project doesn’t end up constituting the majority of some company’s closed-source for-profit code. This is sensible, as much open-source software is produced by people who altruistically and freely work to improve a software product that is free and in the public domain. It aims at protecting the integrity and free availability of open source code.
There are some issues with that copyleft license though, which exactly boils down to that it’s hard to define what a ‘derivative’ work is. I think those issues are the reason for more of the community moving towards less restrictive (which does not equate to more open) licenses, like the MIT.
I’ll also just acknowledge, if there’s an admin in the thread, that this licensing discussion started by my post is off-topic to the original post (though highly interesting and important) and should probably be split to elsewhere.
1 Like
Yes.
Sorry, I thought that «MIT[-licensed code], which cannot be used for code that is derived from GPL-licensed projects» meant that MIT-licensed code cannot be used for GPL-licensed code.
Ha ha, the devil is in the details. The stuff in your square brackets should be “the MIT [license]… cannot be used for code that is derived from GPL-licensed projects”
1 Like
Yep, I’d also prefer that, but we have to live within the current rules, or face the consequences.
About using the paper (i.e. the ideas) vs. the code (an implementation), that’s the way the law works, to protect people’s work from getting ripped off (the precedent goes back 30+ years, see Whelan v. Jaslow - Wikipedia).
As an example, if I were to translate “The Lord of the Rings” into Klingon, it would still belong to J.R.R. Tolkien!
The “no peeking” thing is almost certainly overly conservative. The problem is that courts haven’t ruled on what exactly precisely constitutes a “derived work” in the sense of the GPL so the safest thing is to not even look at GPL code if you’re writing a non-GPL implementation of similar functionality.
4 Likes
Unfortunately, these legal issues are quite real and not entirely clear cut. What we do know is that implementing based on a description of an algorithm is safe. Copying a working implementation is definitely a derived work. Everything between is somewhat murky.
2 Likes
While I understand and take to heart your point about not getting into legal peril, I can’t resist pointing out that source code is a description of an algorithm. Suppose we have a language that looks identical to pseudocode (this is pretty much the case for Julia and Python by design)? What if I write the description of the algorithm in lojban (a machine parsable constructed language)?
Again, I take the point that this is a real issue that people have to deal with… it’s just so unbearably stupid. My opinion of the people who write intellectual property law is not high.
IANAL, but AFAIK most laws consider source an implementation of the algorithm. Except for very simple algorithms, you have to make additional decisions when implementing it, in addition to the algorithm per se. There is no bijection between source and algorithms.
That said, most of these discussions are dominated by a US law perspective, in which deep pockets are at least as important as being on the right side of the law when you go to court. So people are overly conservative: you could be right, but easily go bankrupt proving it.
4 Likes
Yup, that’s a very good point.