I’ve recently been giving more thoughts to the way I license my packages. While I don’t anticipate the choice becoming practically significant any times soon, I’ve realised that the topic probably deserves more consideration that I’ve previously given it. Why we need to think about licenses While m…

[image] Sukera: I am concerned with how people treat others wanting to use that software, including derivatives. Thanks for clarifying. Can you share an example? :slight_smile: What treatment exactly? What is a practical situation where MIT fails in your view?

[image] juliohm: What treatment exactly? What is a practical situation where MIT fails in your view? MIT doesn’t govern at all how modifications should be shared, so some third party/company is free to just take your code and relicense it to sell it, with or without their modifications applie…

Thanks @Sukera for the additional clarifications. [image] Sukera: MIT doesn’t govern at all how modifications should be shared, so some third party/company is free to just take your code and relicense it to sell it, with or without their modifications applied. I can see how this can be a con…

[image] juliohm: In my experience this is not a realistic scenario in the sense that the company/institution wouldn’t allow opening the source code before the submission of the patent. I think the key point here is that if there’s sufficient novelty for aspects of the work to be patentable, r…

[image] juliohm: Most packages I develop are libraries, and so I really want to see people building products out of them. And nothing stops them from doing that with MPL or EUPL :slight_smile: It’s just that they can’t hide that fact if they’re building e.g. a SaaS. With MIT, they can, becaus…

[image] Sukera: Or consider cases where you’ve made some nifty new algorithmic discovery - MIT doesn’t prevent a third party from swooping in and claiming a patent on that discovery, collecting royalties in the process (of course, the patent office in theory checks for prior work, but in practic…

[image] Ben Elkin: So what is the difference in effect between a license explicitly forbidding patenting the algorithm that you invented and published in your package, and a liberal license like MIT? The MIT license just doesn’t explicitly address the patent side of IP at all. In this regard…

[image] tecosaur: Since the MIT license leaves this ambiguous, you can’t clearly point to a part of the license and instead would have to rely on certain interpretations and proving prior art in court: a much more complicated and costly process. It’s actually also a bit worse than that - sinc…

On the foibles of the MIT license, I’ve just come across another lawyer writing on it that may be of interest to some folks: https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html . The conclusion is it’s mostly fine and has generally served well, but is “by no means a panacea for a…

Package licenses: Contemplations and considerations

Community

tecosaur August 7, 2024, 5:24pm 9

Not to oversimplify, but it really does seem to me that the MPL and EUPL can be roughly described as: MIT + more robust legalese + reciprocity + credit, with no restrictions on use.

Topic		Replies	Views
How are the intellectual property rights of Julia package developers protected? Community package	30	2189	March 16, 2024
Copyright and license of Julia packages General Usage question	37	1388	July 18, 2025
How does licensing work for packages that wrap other-licensed binaries? General Usage packages , licenses	25	1919	June 9, 2026
GPL and virality Community faq , licenses , legal , gpl	39	9410	December 20, 2017
RFC: REUSE compliance plugin for PkgTemplates.jl — API, docs, and root LICENSE behavior Package Management pkg , licenses , pkgtemplates	43	585	May 7, 2026

Package licenses: Contemplations and considerations

Related topics