Shen Programming Language for Android | Hacker News Reader

Shen Programming Language for Android

chatolab.wordpress.com

44 pointsdoall16 comments

Chris Double ported Shen to Wasp Lisp, which is a very interesting combination. Wasp and MOSREF (a secure remote injection framework) are something I have been playing with over the years, and having Shen in there makes for an interesting combination [1]. He also ported Wasp Lisp to Android [2].

  [1]  https://github.com/doublec/shen-wasp
  [2]  https://bluishcoder.co.nz/2013/05/09/building-wasp-lisp-and-mosref-for-android.html

Shen is a genuinely interesting Lisp that is implemented using around 46 primitive functions - porting Shen then just requires the implementation of this 46 function substrate in whatever programming language you are using.

In addition to a built-in Prolog and also optional type checker it also uses pattern-matching like other modern functional programming languages. This is unlike Clojure which to my mind wrongly downgrades pattern-matching to simply an optional library. (Apparently Rich Hickey isn't keen on pattern-matching).

Shen is certainly worth investigating if you have an interest in Lisp.

I'd be very careful of looking at it given the author's ...unusual... views on copyright/licensing. In particular the author claims that releasing derivative works of Shen under the GPL is copyright infringement; Shen's license is a standard license that is widely agreed to grant the right to release derivative works under the GPL, but few people would want to have that fight, or the unknown other fights you might get into with an author with a wildly different interpretation of their license from the common consensus.

> the author claims that releasing derivative works of Shen under the GPL is copyright infringement

Do you have a source for this? The closest I could find was this[1]:

> Appropriating other people's work by copying the code and changing the license is IMO immoral.

If this is indeed the source material, then I think your characterization isn't _necessarily_ correct. Saying it's immoral isn't the same as making a claim about law.

The link provided[2] does indicate that de Raadt thinks it is a violation of copyright law however. Finally, I question whether there is actually a consensus on this matter at all. If you relicense BSD code as GPL, then consumers needn't abide by the GPL; they can simply opt to use the original license. Does that really mean a relicensing has occurred? Of course, in non-trivial cases, there's likely additional code that has been intermixed with the original code, which would make it impossible to separate. But the release of the GPL code would still technically need to comply with the BSD license itself. Even at that point, it doesn't feel like "relicense" is actually correct.

(Note that I picked up on this because I firmly believe that such relicensing is indeed unethical, while simultaneously not knowing whether such relicensing is definitely a violation of copyright law or not, while also believing that copyright law shouldn't exist at all.)

[1] - http://www.marktarver.com/fsf.html

[2] - http://undeadly.org/cgi?action=article&sid=20070913014315

> If this is indeed the source material, then I think your characterization isn't _necessarily_ correct. Saying it's immoral isn't the same as making a claim about law.

At the bottom of that page he says "my library work is BSD... I do not give permission to relicense my work under GPL", which I think carries my point since most people would understand the former to mean the latter. I think I remember a mailing list post talking more explicitly about derivative works, but I can't find it now and could easily be misremembering.

> If you relicense BSD code as GPL, then consumers needn't abide by the GPL; they can simply opt to use the original license. Does that really mean a relicensing has occurred?

People who wish to distribute derivative works based on copyrighted code need a license to do so. Some jurisdictions require licenses to be conveyed in writing, others allow oral or implicit transfers. I'm not sure any jurisdiction would be willing to acknowledge the conveyance of a license when there had been zero interaction between the parties. So it seems like if A were to license some code under the BSD license to B and B were to license it under some more restrictive license to C (which the BSD license certainly grants B permission to do), then in theory C doesn't necessarily have a BSD license to the code. Of course in practice it's moot since if B hasn't made any copyrightable changes then the only person who could ever sue C for copyright infringement would be A.

> the release of the GPL code would still technically need to comply with the BSD license itself. Even at that point, it doesn't feel like "relicense" is actually correct.

Technically the combined work (which multiple contributors hold copyrights on) can only be distributed in compliance with the requirements of both the GPL and the BSD license, sure. But since the requirements of the GPL are a superset of those of the BSD license, for all practical purpose the whole is GPLed.

Sure, I guess I can't really dispute any of that, but I'm not sure I buy that what you've written has any kind of strong consensus backing it.

Anyway, I do agree with your larger point. I'd stay away from this language for a variety of reasons.

I'd say there's a strong consensus that you can form a work that combines (3-clause) BSD-licensed and GPL-licensed content and distribute the result under the GPL - the FSF has been publishing its list of "GPL-compatible" and "GPL-incompatible" licenses for decades now, and copying BSD-licensed libraries into source trees (GPL and otherwise) without changing the license of the whole for a similar length of time. I'd agree there probably isn't any kind of clear consensus about what happens in the case where there is no substantive GPLed contribution in the first place, because that doesn't seem like a case that would come up very often. (To me it seems obvious, but I guess to other people some other interpretation might seem equally obvious)

Only a copyright holder can change the license. You can't relicense anything you don't own as GPL. Copyleft doesn't work without well defined ownership.

Owning is not the same thing as licensing. You can license things you don't own if you have a license to. The BSD license grants you license to distributed the covered code under other licenses.

Your understanding is wrong I'm afraid. You cannot license software you have not written or over which you have no ownership. It is unfortunate that some people believe that the BSD license in itself gives people the rights to relicense the work under GPL. It does not.

This misunderstanding arose from a deliberate attempt by the FSF to co-opt the open software movement by trying to relicense BSD work under GPL without seeking the author's permission. The attempt was successfully challenged by Theo de Raadt in 2007 (http://undeadly.org/cgi?action=article&sid=20070913014315) and the ensuing discussion in which Stallman was thoroughly educated in the law of copyright can be found here.

http://openbsd-archive.7691.n7.nabble.com/Real-men-don-t-att...

(A lot of that discussion concerned whether openbsd was open, but much revolved around the issue raised).

Most programmers are catching with the law in 2017, but the disinformation is still around.

Of course you can use BSD code inside a GPL project; but that does not entitle you to relicense the BSD code.

Of course you can license code you don't own. Otherwise there would be no way to have a license that allowed its recipients to redistribute and then allowed the people who received the code from them to redistribute it themselves.

I'm afraid you don't really understand licenses. A license like BSD gives you the rights to distribute the software subject to certain provisions. It does not give you the right to change the license. I can't really spend any more time on this but I'm sure people around you can point you in the right direction.

Just tried building shen-c[1]; it seems my gcc (5.4.0) doesn't like the code with -std=c99 and prefers the -lgc at the end of the line.

[1] https://github.com/otabat/shen-c

    diff --git a/Makefile b/Makefile
    index 3ae5a55..458200d 100644
    --- a/Makefile
    +++ b/Makefile
    @@ -26,5 +26,6 @@ ${TARGET}: ${SRC_OBJS}
     #	cc -g -O3 -std=c99 -lgc -lprofiler -Wl,-no_pie -o $@ $^
    -	cc -O3 -std=c99 -lgc -o $@ $^
    +#	cc -O3 -std=c99 -lgc -o $@ $^
     #	gcc-6 -g -O3 -std=c99 -L /usr/local/lib -lgc -lprofiler -Wl,-no_pie -o $@ $^
     #	gcc-6 -O3 -std=c99 -L /usr/local/lib -lgc -o $@ $^
    +	gcc -O3 -o $@ $^ -lgc
     
    @@ -34,5 +35,6 @@ ${OBJ_ROOT}/%.o: $(SRC_ROOT)/%.c
     #	cc -O2 -std=c99 -fno-optimize-sibling-calls -c -o $@ $<
    -	cc -O3 -std=c99 -fno-optimize-sibling-calls -c -o $@ $<
    +#	cc -O3 -std=c99 -fno-optimize-sibling-calls -c -o $@ $<
     #	gcc-6 -g -O3 -std=c99 -fno-optimize-sibling-calls -Wall -I /usr/local/include/gc -c -o $@ $<
     #	gcc-6 -O3 -std=c99 -fno-optimize-sibling-calls -Wall -I /usr/local/include/gc -c -o $@ $<
    +	gcc -O3 -fno-optimize-sibling-calls -c -o $@ $<

Presumably some readers bought the book when Shen appeared on the frontpage because its price on Amazon has risen from 40 usd to 230 usd: https://www.amazon.com/dp/B01K3JCGGI

Every time I hear about Shen I think about this talk: https://www.youtube.com/watch?v=lMcRBdSdO_U

Pretty cool language but there's no way to save your work in the app.

Reply on news.ycombinator.com