On Fri, Jan 19, 2018 at 10:28 AM, Chris Brien <chris.br...@unisa.edu.au> wrote:
> Hi Barry, > > Ideally, I would prefer that my package remain open source. > > However, I have considered MIT and the two BSD licenses and I understand > that they are permissive. I have not ruled out using one of them. > > The thing about those licenses is that I have not been able to find > anything on the web about linking a proprietary and free package under > those licenses. The information is not nearly as comprehensive as it is for > GPL licenses. > > You're not distributing the proprietary package, and the MIT license doesn't restrict use in any way, including linking with proprietary software. So you can MIT-license your code and it remains open source, can link with EvilCorps `bar` package, and it guarantees your (c) notice and the MIT license will be preserved on copies of your code (it can't be re-licensed under a different license). > The problem as I see it is that they are GPL compatible and so I do not > understand how that can be the case and that you can apply the licence in > my situation. > > GPL-compatible means you can put MIT-license code together with GPL-license code and distribute the combination *under the GPL license*. This doesn't work the other way round - you can't bring GPL-licensed code into an MIT-license codebase and distribute that under MIT-license! Interestingly GNU doesn't seem to acknowledge the existence of a "MIT License" although OSI does. To GNU, the "MIT LIcense" is a number of possible licenses, and this might be why CRAN insist on inclusion of the license file itself with anything branded "MIT License": https://www.gnu.org/licenses/license-list.html Barry > I agree that to write your own license is rather daunting. I would much > prefer to use a pre-existing license. > > Thanks for your comments. > > Cheers, > > Chris > > > > From: b.rowling...@gmail.com [mailto:b.rowling...@gmail.com] On Behalf Of > Barry Rowlingson > Sent: Friday, 19 January 2018 8:00 PM > To: Chris Brien > Cc: r-package-devel@r-project.org > Subject: Re: [R-pkg-devel] Licensing of an R package > > Chris, > > you've not said what *you* would like the license for your software to > do. You could release the software under a "public domain", "no rights > reserved" style license, and then if people want to link it with > proprietary materials then nothing can stop them. But it wouldn't stop > people commercialising (what was) your code, modifying it, re-releasing it > as binary and without source, and so on. > > Once you've decided which things you want to permit or restrict under > your license then you can see if there's a pre-existing one that matches > your requirements, or whether you have to write one yourself! Good luck > with that option! > > https://opensource.org/license/MIT is one of the more permissive open > source licenses - check the others on there for more info. > > Barry > > > > On Fri, Jan 19, 2018 at 8:31 AM, Chris Brien <chris.br...@unisa.edu.au< > mailto:chris.br...@unisa.edu.au>> wrote: > Dear list members, > > I have come to realize that my understanding of free software licensing > was somewhat naïve. The problem is that I now find that, in spite of > spending quite a bit of time reading about various licenses on the web, I > have been unable to identify a suitable license for the situation that I > have with one of my packages. > > I am solely responsible for the development of my package, `foo' say. > However, most functions in `foo' call functions from a proprietary package, > `bar' say , the latter not being available from an online software > repository and consisting of R functions that call routines in a library. > That is, `foo' enhances `bar'. > > I had thought that a GPL licence was appropriate because (1) `foo' is free > software and (ii) I do not distribute `bar' with `foo'. That is, I am > distributing only free software. However, I have come to understand that > this is not the case because a free software package linked with a > proprietary package does not satisfy the requirements to be GPL. > > I have found it difficult to work out a license that might cover my > package because much of the discussion online covers cases that are the > opposite of mine i.e. cases where `foo' is proprietary and `bar' is > freeware. I can appreciate why this needs to be avoided. > > I can also understand that a disadvantage of what I am doing is that it > tends to entrench the use of such software. While I agree that it is > desirable that `bar' be replaced with free software, unfortunately `bar' > has functionality that is currently infeasible to replace with free > software. At least I am not profiting from the enhancements that I have > made. > > I am hoping that someone more experienced in software development and > licensing issues can suggest a license type that might be suitable for > `foo' such that at least the enhancements that it incorporates remain > `free'? > > Cheers, > > Chris Brien > > Adjunct Senior Lecturer in Statistics > ----- > Phenomics and Bioinformatics Research Centre > University of South Australia > GPO Box 2471 > ADELAIDE 5001 South Australia > Phone: +61 8 8302 5535<tel:%2B61%208%208302%205535> Fax: +61 8 8302 > 5785<tel:%2B61%208%208302%205785> > Email: chris.br...@unisa.edu.au<mailto:chris.br...@unisa.edu.au> > WEB page: <http://people.unisa.edu.au/Chris.Brien> > CRICOS No 00121B > > ______________________________________________ > R-package-devel@r-project.org<mailto:R-package-devel@r-project.org> > mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
