Infinity.jl is GNU GPL licensed

[Byrth]

Infinity.jl is GNU GPL licensed, meaning that LibPQ.jl and anything that depends on it is implicitly GNU GPL by virtue of including Infinity.jl.

I appreciate that it is a smoother way of handling infinity and -infinity timestamps, but there is a cost. It means users have to maintain a fork of LibPQ.jl where they revert to the old behavior and remove Infinity.jl to avoid accidentally open sourcing the software they are developing. Not the hardest thing in the world, but not really in the "we're mostly MIT licensed" spirit of Julia.

[iamed2]

There are several ways to approach a solution for this, but it's important to note that Infinity.jl here is used both alone and through Intervals.jl, so it's not just the representation of infinity that would need to change.

---

Option 1: someone writes a full replacement for Infinity.jl. I'd be willing to replace Infinity here, and advocate for replacing it in Intervals.jl. Or, Infinity.jl is re-released under a permissive license (which is now looking likely).

Option 2: Pkg.jl introduces auto-loading glue packages, a solution proposed a few times by Stefan Karpinski. Then code for using infinities with LibPQ would only be loaded when Infinity.jl was loaded, and thus any compiled version of an application using LibPQ.jl but not Infinity.jl would not contain any code from or regarding Infinity.jl.

Option 3: All code for handling types from other packages is spun off into a pirate package called LibPQTypes.jl or something. By default the package would work only with Base types, but loading LibPQTypes.jl would replace that behaviour with other types where appropriate.

Option 4: A flipped version of Option 3, where the basic functionality is spun off into a package called LibPQBase.jl or something, and then LibPQ.jl re-exports that functionality and adds interactions with other types.

[Byrth]

True, I had not considered Intervals.jl because it is hidden behind Requires and thus would ultimately not make it to my compiled code.

Option 1) If taking it over and relicensing it is an option, that seems best because it immediately spreads it throughout the Julia ecosystem. I have been avoiding reading the code in case I have to rewrite it, but let me know how that goes and I can probably help with or do the reimplementation if it comes to that.

Option 2) I believe I am still following this thread and very much need conditional dependencies in my life. I view it as the biggest weakness of the Julia Pkg system.

Option 3/4) These seem like a long way to go to solve the problem. I dream that some day option 2 will be viable and hate to see too much fragmentation before then. I would sooner just maintain a fork of LibPQ (could do regular post-release PRs to a branch here if you want) that has the old infinity behavior.

[Nosferican]

Seems re-licencing it as MIT would be the optimal approach here.

[Byrth]

Ok, I will move ahead with the fork approach today and will maintain it until the maintainer of Infinity.jl gets back about relicensing.

[mbravenboer]

Could this fix be addressed in the official libPQ package?

Technically anything written that depends on libPQ is currently a GPL violation. That's a serious problem for commercial usage of Julia.

Thanks!!

(Edit: I also commented on cjdoris/Infinity.jl#9 )

[mbravenboer]

Update: the Infinity package has switched the license - see cjdoris/Infinity.jl#33 . I suppose it's best to wait for a new version, and after that it should be easy to update LibPQ?

[iamed2]

New version of Infinity.jl is out; since it's compatible with the current requirements, any downstream users can specify Infinity = "0.2.4" to ensure they get the MIT-licensed version, and thus I don't think a LibPQ.jl update is necessary.