The key difference being that while not under the GPL, highcharter is still
open source. There isn't a single compiled library in the entire package.
WinBUGS otoh is closed source (although there is an open source version of
it, OpenBUGS). As far as I understood, CRAN doesn't accept packages
containing any binary executable code without the proper source files
attached. So including the closed source libraries as Mario wanted to do,
is not accepted on CRAN.
https://cran.r-project.org/web/packages/policies.html#Source-packages
On a sidenote: I'm not a legal expert, and I might have been misusing the
term "proprietary software" where I should've written "closed
source". My
apologies if I confused anybody doing so.
Cheers
On Fri, Mar 24, 2017 at 4:21 PM, Ganz, Carl <carlganz at ucla.edu> wrote:
> There are also packages like highcharter, which package proprietary
> software without a license, but it is incumbent on the user to respect the
> license of the underlying library.
>
> -----Original Message-----
> From: R-devel [mailto:r-devel-bounces at r-project.org] On Behalf Of Joris
> Meys
> Sent: Friday, March 24, 2017 8:14 AM
> To: Marc Schwartz
> Cc: R-Devel
> Subject: Re: [Rd] non-infectious license for R package?
>
> My humble 2 nonlegal cents:
>
> There are multiple packages that make the link between R and proprietary
> software. One example is R2WinBUGS which connects to WinBUGS, but there are
> a lot more of these.
>
> All of these use essentially the same idea:
> - create the package under a standard GPL license
> - use the (command line) interface provided by the proprietary software to
> connect with it, eg by calls to sytem(). That's exaclty how R2WinBUGS
> operates. It doesn't contain a single closed source library to achieve
> this, all those are kept within WinBUGS itself.
>
> So taking the route others took before you seems the way forward to me.
>
> Cheers
> Joris
>
> On Fri, Mar 24, 2017 at 3:44 PM, Marc Schwartz <marc_schwartz at
me.com>
> wrote:
>
> > See inline...
> >
> > > On Mar 24, 2017, at 8:52 AM, Mario Emmenlauer <mario at
emmenlauer.de>
> > wrote:
> > >
> > >
> > > Dear All,
> > >
> > > I've been following this mailing list for over three years
now, but
> > > its just now that I have realized that R is licensed under GPL!
:-)
> > >
> > > I'm not a lawyer and I don't want lawyer advice, but
I'd like to get
> > > your feedback on a license question.
> >
> >
> > Hi,
> >
> > With the usual IANAL caveat and that I am not speaking on behalf of
> > any other parties:
> >
> > The questions you are posing will require legal advice, so your desire
> > above to not get legal advice is in direct conflict with what you
> > actually need here.
> >
> > To your comments below, you cannot change existing licenses on
> > software, R or otherwise. That is only something that the copyright
> > holder(s) can do and you are not one of them.
> >
> > The GPL has a FAQ here:
> >
> > https://www.gnu.org/licenses/gpl-faq.en.html <
> > https://www.gnu.org/licenses/gpl-faq.en.html>
> >
> > that you may find enlightening.
> >
> > A very general statement, which is that if your compiled code (in
> > whatever
> > language) does not "link" against R's libraries and does
not directly
> > contain GPL licensed code (e.g. copying and pasting R Foundation
> > copyrighted source code into yours), that is one way to steer clear of
> > the viral part of the GPL license vis-a-vis R, if you want to, but not
> > the only way and not a guarantee either. There can be nuances, some of
> > which are covered in the FAQ above.
> >
> > On the other hand, if your compiled code is linking to R's
libraries,
> > which you seem to suggest may be the case below, then your code, at
> > least the relevant parts of it, will need to be licensed under a GPL
> > compatible license.
> >
> > This again is part of the nuance, in terms of the scope of the impact
> > on your code (all or parts) and where legal advice is needed, to steer
> > clear of downstream potential issues that could result in legal and
> > financial liabilities for you.
> >
> > The issue of linking to third party proprietary libraries is something
> > that you will have to evaluate with respect to their licenses and any
> > limitations that they may impose on your code and it's licensing.
> >
> > Since you seem to also be suggesting that you may use closed source
> > components in your package, you should be aware, that vis-a-vis CRAN,
> > you would not be able to submit your package for distribution via that
> > channel, since CRAN submissions may not contain pre-compiled binaries
> > or similar and the entire package must conform to a compatible open
> > source license. Thus, if you go down that path, you would have to find
> > other distribution channels for your package, such as a company web
> site, etc.
> >
> > None of the above should be construed as legal advice and if you plan
> > to go down the path of offering a commercial service that you would
> > charge clients for, a lawyer is mandatory to provide legal guidance
> > and to assess your business risks. Even if your actual R related
> > package is offered free of charge, while generating revenue through
> > other means, if you should run afoul of software licensing
> > requirements, that can still leave you open to financial liabilities
> > and put your business and even personal assets at risk.
> >
> > Regards,
> >
> > Marc Schwartz
> >
> >
> > > My goal is to develop commercial
> > > software for image analysis of biomedical samples that may be
used
> > > i.e. in academic institutions. Since I've been an academic
software
> > > developer for long, a priority for me is to make the data and
tools
> > > easily accessibly for other developers. I have toyed with the
idea
> > > to make a (free) R package that can very efficiently fetch data
from
> > > the database and push back results for visualization. To clarify:
I
> > > am not using R in my software. I'd rather like the
institutions of
> > > my customers to have open (internal) access to their data.
> > >
> > > Now for the question: To efficiently get the data into R, I
assume a
> > > package (possibly in C or C++) is the most reasonable way? If
yes,
> > > would such a package automatically be infected by the GPL? If the
> > > package links to (proprietary closed source) libraries to
> > > efficiently access the data, would the libraries in turn be
infected?
> > >
> > > I'm asking this very naiively because I understand statement
[1] in
> > > such a way that it is generally encouraged to make data available
in
> > > R. Obviously open source is the preferred way, but my
understanding
> > > is that also closed source extensions can add value and may be
> > > welcome.
> > >
> > > I was therefore hoping that somebody has prior experience in this
> > > regard, or can shed further light on statement [1]. Is the R-C-
> > > interface infectious per se, even when data flows only into R,
not
> > > vice versa? If its infectious, could just the very core of R be
> > > licensed additionally under a non-infectious license?
> > >
> > > Furthermore, can I avoid infecting my full software stack, for
> > > example by making only the package open source under a permissive
> > > license? Are there any guidelines how to legally bridge between
the
> > > proprietary and the R-world? I guess other people have tried this
> > > before, can someone share his/her experience?
> > >
> > > [1] https://stat.ethz.ch/pipermail/r-devel/2009-May/053248.html
> > >
> > > All the best,
> > >
> > > Mario Emmenlauer
> > >
> >
> > [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
>
> --
> Joris Meys
> Statistical consultant
>
> Ghent University
> Faculty of Bioscience Engineering
> Department of Mathematical Modelling, Statistics and Bio-Informatics
>
> tel : +32 (0)9 264 61 79
> Joris.Meys at Ugent.be
> -------------------------------
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Joris Meys
Statistical consultant
Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics
tel : +32 (0)9 264 61 79
Joris.Meys at Ugent.be
-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]