Licence guidance

[Stephen De Gabrielle]

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 abandoned project that I’d love to fork but can’t because it lacks a licence)

With that in mind- what licences should be used when making code available on the package repository/github in the following situations:

a) general purpose library that I am happy for the broader community of evelopers to use without restraint - but is unlikely to ever meet to be included in Racket e.g. I have an number checksum validator (UK NHS ID number) 

- is dual licence Apache/MIT appropriate? or is it completely up to me.

b) library, tool or DrRacket plugin that may(or may not) become part of the Racket distribution

- is dual licence Apache/MIT appropriate or should it also be LGPL?

c) anything else?

Kind regards,

Stephen

--

Kind regards,
Stephen
--
Ealing (London), UK

[David Storrs]

It depends very much on what you want to accomplish. 

If your goal is to help people get things done in the general case then you should choose a liberal license such as BSD or MIT.   These will guarantee that you get credit for your work and that the person using that work can make a living off your code or enable someone else (including a company) to make a living off your code.

If your goal is to ensure that all users have maximal freedom with their software and you're okay with undermining the system of intellectual property that enables people to make money directly off of selling software (as opposed to indirectly, such as by consulting on open source software), then you should choose a restrictive license such as GPL.

If you want to be somewhere in the middle, you could choose a license such as LGPL, which allows people to use your code as part of something from which they make a living, but not to directly make a living off your code.

As to things that will be included under DrRacket, the dev team can speak to that better than I, but Racket itself is distributed under an interpretation of the LGPL:  https://download.racket-lang.org/license.html

Dave

--

Kind regards,
Stephen
--
Ealing (London), UK

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Neil Van Dyke]

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 the idea of sharing in the same spirit,
but has very modest limitations that aren't a barrier to most commercial
use.  At the same time, if someone wanted to make commercial
inconsistent with even those modest limitations (e.g., make the package
a closed network service), that was OK, but I'd want some of that money,
in lieu of common benefit warm-fuzzies.

I don't recall ever being contacted about a different license other than
LGPL.  Some of my Racket packages are used by an important large
closed-source production server system, for example, without any
different license.  (Though, at one point, someone who wanted to
incorporate my CSV library into an open source something initially
seemed to be interested in an older version that was LGPLv2 rather than
v3, perhaps for compatibility with their license at the time, but then
they quickly straightened that out somehow.)

That said, I don't know whether LGPLv3 is the best default license for
third-party Racket packages.  Maybe that should be revisited.

Today, Racket hasn't yet taken off commercially nearly as much as it
might've,[1] and maybe the biggest concern with the licenses of open
source Racket packages shared altruistically is that we not
inadvertently lock out some positive later effort (because, e.g., we
didn't leave a permissive enough license before we went to live off-grid
on a sunny beach with our Racketeering plunder).

I'm not saying that licenses shouldn't be totally permissive, though, or
we'd just release everything to the public domain. Racket is pretty
neat, and, for example, there's still an icky element or two in industry
that have been known to sabotage projects, and licenses can offer some
defense.  I think there's little danger of Racket ever being a threat or
underhanded opportunity to anyone -- but, with all the students around,
we should try to serve example of good open source licensing, in the
best spirit of engineering and goodwill.

[1] It's not too late. :) https://www.neilvandyke.org/racket-money/

[er...@snafu.de]

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 anyone to distribute his or her Racket application as compiled executable without making the source code available on request, too, whenever that source code was made with an LGPL Racket library. So for users of your library, LGPL is pretty much equivalent to GPL. They have to provide the source code, or the program has to load the library with dynamic 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" <ne...@neilvandyke.org>

An:

"Stephen De Gabrielle" <spdega...@gmail.com>, "Racket Users" <us...@racket-lang.org>

Cc:

Gesendet:

Mon, 24 Sep 2018 13:06:15 -0400

Betreff:

Re: [racket-users] Licence guidance

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.

[Philip McGrath]

David linked above to https://download.racket-lang.org/license.html, where the Racket maintainers (who are not lawyers, and neither am I) explain their interpretation of how "linking" in the LGPL applies to Racket. I think it's worth copying here for the record:

Since the LGPL license that Racket uses was originally designed for C programs, parts of it require some interpretation to apply to Racket in detail. The following is how the Racket maintainers interpret the license.

First, if you distribute your Racket application in source form or as compiled bytecode files, the Racket license does not restrict you at all.

Second, if you distribute your Racket application as compiled binary generated by raco exe, there are no requirements placed on the licensing of your software. However, the LGPL requires that you make it possible to re-link your software with modified versions of Racket. This means, basically, that you need to provide the compiled bytecode files used to produce the compiled binary, if requested by someone who got your software from you. Note that this does not mean that your software has to be made open source, nor do you have to give the source code to anyone, nor do you have to make the compiled bytecode files available to the public or let other people redistribute them. Furthermore, this is not revealing any more of your source code than the raco exe format, since the bytecode is embedded in an extractable way in the resulting executable.

I would add the observation that the word "easily" is subjective, and doesn't appear in the LGPL anyway, but I don't think this process for Racket is objectively more difficult than replacing a library for a C program. The process for C might be more familiar, but that's only because Racket is still in the process of conquering the world :)

-Philip

[Neil Van Dyke]

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 to
need the most masochistic brainiac lawyers to wrestle, so I'd only like
to throw out 3 quick comments at this time:

* The Racket package system, and ways that systems using Racket are
distributed in practice, as well as the market potential, have changed
since I picked a license.

* I think industry and open source practice, the information technology
infrastructure, and the world have all changed substantially since open
source people really-really rethought licenses.

* Having been engaged with GNU and FSF for many years, and occasionally
talking with RMS, including about "linking" subtleties and
implications... the various FSF technicalities are usually imperfect, or
not entirely clear.  (The reason seems to be difficulty of legal
constructs that capture intent over decades, for evolving technology,
and without the benefit/curse of a legislative system.  Though the FSF
remains an interactive component, for one-on-one interpretation, as well
as leaving the "or any later version" evolutionary hook in the language.)

[Stephen De Gabrielle]

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 pages!

https://download.racket-lang.org/license.html and https://docs.racket-lang.org/license/index.html 

Thanks again,

Stephen 

[George Neuner]

On Mon, 24 Sep 2018 20:18:15 +0100, er...@snafu.de
wrote:

>Are you sure that's a wise choice of license?

I don't like either the GPL or LGPL.
But as a technical matter ...

>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(*).

You can dynamic-require a .zo (object) file.

I think the real question here is whether Racket's dynamic-require is
sufficient to meet the requirements of the LGPL license. From a
purely technical viewpoint, dynamic-require (and even normal require
for that matter) has similarities to library linking in [more]
conventional languages.

I'm not a lawyer, so I am not competent to answer the question.

Unfortunately I doubt the GNU folks even considered the needs of Lisp
or similar languages in formulating the LGPL, even though RMS cut his
teeth working on Lisp.

>Therefore, LGPL doesn't allow anyone to distribute his
>or her Racket application as compiled executable without making the
>source code available on request, too, whenever that source code was
>made with an LGPL Racket library. So for users of your library, LGPL
>is pretty much equivalent to GPL. They have to provide the source
>code, or the program has to load the library with dynamic require at
>runtime, if that's possible at all.

YMMV, but I think this is debatable.

George

[Neil Van Dyke]

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, you can always email RMS.

You can get as technical as necessary.  Organizationally, besides the
FSF being founded by and attracting some high-powered techies, some
advisors are very noteworthy Scheme people.  Also, a Scheme with
multiple `#lang`s (though it wasn't called `#lang`) was actually a
central part of the GNU roadmap, from early on.  (And probably would've
been in popular use atop Linux for over a decade now, but for another
party's business decision, outside of FSF's control, not a technical or
acceptance reason.)

[Deren Dohoda]

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? 

[Philip McGrath]

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

[Anthony Carrico]

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.

--
Anthony Carrico

[Norman Gray]

Greetings.

That doesn't necessarily solve the problem, or at least not
internationally.

In UK law, for example, 'public domain' means simply 'known to the
public', and doesn't have a link to licence information. Also, it seems
that there isn't the notion of 'unowned (intellectual) property', so
that 'I place this in the public domain' could at most be interpreted as
a vague disavowal of interests. That is, it would be an absence of a
statement of a licence, rather than a statement of an absence of a
licence.

Thus the BSD licence is probably the most permissive thing that's still
unequivocally recognisable as a licence.

Best wishes,

Norman


--
Norman Gray : https://nxg.me.uk

[stewart mackenzie]

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, <spdega...@gmail.com> wrote:

c) anything else?

[Hendrik Boom]

One of the Creative Commons licences is equivalent to the concept of
public domain we eem to want, formulated as a licence for jurisdictions
where "public domain" isn't a concept.

-- hendrik

[Joel Dueck]

Most of my projects are like Stephen's (a) scenario.

I typically want a non-copyleft/permissive license for these.

In such cases I have usually followed the FSF's advice and used Apache 2.0. However...

Recently I read the following blog post by Kyle Mitchell, a practicing IP lawyer:

  Deprecation Notice: MIT and BSD. https://writing.kemitchell.com/2019/03/09/Deprecation-Notice.html

Kyle and a few other coding/IP-law types recently formed Blue Oak Council to provide guidance specifically on permissive (non-copyleft) open source licenses.

As part of this they have designed their own "model" permissive open source license:

  https://blueoakcouncil.org/license/1.0.0

I know it's extremely new, but (though not a lawyer myself) I find the rationale behind their plain-English model license appealing.

I'll be strongly considering it in the future. I thought it was worth including in this thread.

It was discussed on HN a few days ago, with some additional comments from the author:

  https://news.ycombinator.com/item?id=19347797