On Thu, Sep 27, 2018 at 01:21:15PM +0100, Norman Gray wrote:
>
> Greetings.
>
> On 27 Sep 2018, at 3:48, Anthony Carrico wrote:
>
> > On 09/26/2018 05:32 PM, Deren Dohoda wrote:
> >
> > > I put a package up but it has no license info in the code. I would
> > > add
> > > one which is the most
Hi,
Take a look at MPLv2, it's a share-and-share-alike but at file level so you
can include it in proprietary code if you want.
This is a good license for hackers and businesses.
kr/sjm
On Mon, 24 Sep 2018, 18:04 Stephen De Gabrielle,
wrote:
> c) anything else?
>
--
You received this
Greetings.
On 27 Sep 2018, at 3:48, Anthony Carrico wrote:
On 09/26/2018 05:32 PM, Deren Dohoda wrote:
I put a package up but it has no license info in the code. I would
add
one which is the most permissive possible that wouldn't cause
conflict.
I guess this is BSD? MIT?
In this case,
On 09/26/2018 05:32 PM, Deren Dohoda wrote:
> I put a package up but it has no license info in the code. I would add
> one which is the most permissive possible that wouldn't cause conflict.
> I guess this is BSD? MIT?
In this case, don't license your code, declare it to be in the public
domain.
If you want a permissive license, the FSF itself says that "Apache 2.0 is
best" because it addresses patent issues:
https://www.gnu.org/licenses/license-recommendations.html#small
-Philip
On Wed, Sep 26, 2018 at 4:32 PM Deren Dohoda wrote:
> I put a package up but it has no license info in
I put a package up but it has no license info in the code. I would add one
which is the most permissive possible that wouldn't cause conflict. I guess
this is BSD? MIT?
On Tue, Sep 25, 2018, 12:30 PM Neil Van Dyke wrote:
> BTW, I don't know the status of possible new GPL and LGPL versions in
>
BTW, I don't know the status of possible new GPL and LGPL versions in
progress, but, if any Racket people have some insights into how to
improve the "linking" concepts or some other aspect, in the spirit of
FSF goals, the FSF has seemed open to comments. If you don't know who
else to contact,
Thank you all. Sounds like a case-by-case approach is probably best.
I did find the github licence advice pages. It seems that not choosing a
licence is probably a bad choice when publishing a racket package:
https://choosealicense.com/no-permission/
I can't believe I missed the Racket licence
Yes, it could be that LGPL is not the best for Racket package authors
who intend something analogous to LGPL for C libraries. (Or who intend
not necessarily that, but something in the neighborhood of that flavor
or degree.)
Law quickly gets way outside my expertise, and the finer points seem
amic require at runtime, if that's possible at all.
>
> (*)=the user must be able to easily update the library that the executable
> uses, e.g. by linking to another dynamic library
>
> - Ursprüngliche Nachricht -
> Von:
> "Neil Van Dyke"
>
> An:
> &
Are you sure that's a wise choice of license?
Racket does not dynamically link to Racket libraries when applications
are deployed as compiled executables - as far as I can see, the
standard module system does not link dynamically in the sense required
by the LGPL(*). Therefore, LGPL doesn't allow
What's seemed to work over many years for my Racket open source packages
(a couple of which are useful things that would be expensive to rewrite)
is LGPL (initially version 2.x, but lately version 3), plus a statement
to contact me about other possible licenses.
My thinking was, LGPL suggests
On Mon, Sep 24, 2018 at 6:03 AM, Stephen De Gabrielle <
spdegabrie...@gmail.com> wrote:
> Hi,
>
> I sometimes see Racket packages on PLaneT or Github, but lack a licence.
>
> I don’t feel I can redistribute or fork abandoned code if it lacks a
> licence. (I can give an example of an 11yo
13 matches
Mail list logo
