
Run .NET Core Apps Directly from a GitHub Gist - shanselman
https://www.hanselman.com/blog/SharpScriptFromServiceStackLetsYouRunNETAppsDirectlyFromAGitHubGist.aspx
======
password4321
Discussion of SharpScript 2 days ago, including some attempts at explaining
its licensing:

[https://news.ycombinator.com/item?id=20738557](https://news.ycombinator.com/item?id=20738557)

TAForObvReasons: _The actual Project
repo[https://github.com/ServiceStack/ServiceStack](https://github.com/ServiceStack/ServiceStack)
appears to be AGPL3 with some exceptions_

mythz: _The Exceptions are for OSS projects, where it can be used as the OSS
license for that project. Regardless it 's completely free to use for both
commercial/non-commercial usage._

[https://news.ycombinator.com/item?id=20738557#20739419](https://news.ycombinator.com/item?id=20738557#20739419)

~~~
mythz
Yeah I'm surprised there's so much focus on the license of a free library
that's also OSS. The AGPL/OSS license only applies if you're creating a custom
build from source in OSS projects, if you're just using #Script from the
official NuGet package you're using the commercial license which is free to
use without restrictions for both commercial/non-commercial usage.

#Script started out as an alternative to Razor Pages [1] (where it was
initially called ServiceStack Templates [2]) to give ServiceStack Apps a
productive alternative to Razor for developing server-driven Web Apps, but as
it's highly extensible without external deps or reliance in external tooling
it was easy to re-purpose as a dynamic emeddable language to be able to
basically script any .NET App, hence the rebrand to a stand-alone #Script
language, all the whilst its implementation remained in the core
ServiceStack.Common assembly. If it becomes an issue we can look at pulling it
out of the main ServiceStack repo in a stand-alone repo with a weaker copyleft
OSS license, but it would require a bit of work and would need to ensure it's
not disruptive to existing ServiceStack Customers, I just didn't expect there
to be any issue for a gratis library that's also OSS.

Incidentally the ServiceStack.Glue library that the Desktop Apps use to embed
.NET Core Apps in a Chromium Desktop Shell is MIT [3].

[1] [https://sharpscript.net/docs/sharp-
pages](https://sharpscript.net/docs/sharp-pages)

[2]
[https://github.com/NetCoreApps/TemplatePages](https://github.com/NetCoreApps/TemplatePages)

[3]
[https://github.com/ServiceStack/ServiceStack.CefGlue](https://github.com/ServiceStack/ServiceStack.CefGlue)

~~~
bob1029
Surprised? Let me give you my perspective on this whole thing.

I was almost sold on sharpscript for handling our email templating needs until
I realized how obfuscated the licensing and overall project structure is. I've
been reading through threads about it on HN for 2 days now, and still don't
have a clear understanding of what the real intentions are here.

If I just follow the rabbit hole from the #script nuget.org page:

[https://www.nuget.org/packages/ServiceStack.Common](https://www.nuget.org/packages/ServiceStack.Common)

I wind up at the following license URL:

[https://servicestack.net/terms](https://servicestack.net/terms)

Which has the following:

"Use of the Software and Documentation is subject to the restrictions
contained in this Agreement. ServiceStack, Inc. grants you a non-exclusive,
limited, non-transferable, freely revocable license to use the Software.
ServiceStack, Inc. reserves all rights not expressly granted herein in the
Software and the Content and may terminate this license at any time for any
reason or no reason."

I will not be using this software. If anyone wants to change my mind, pull
sharpscript into its own repository, give it its own nuget, and post crystal
clear license terms alongside each which do not contain any sort of legal
backdoors where you get to rip the rug out from under me at some arbitrary
point in the future. If you want money for this, just ask for it up front and
be honest with your intentions. I may actually consider purchasing a license
if the terms aren't trashy like in the current license above.

~~~
mythz
Sure, you shouldn't use anything you don't feel comfortable with. That clause
is common in other commercial Software license agreements, e.g. Xamarin
originally had the same clause before they were acquired. IMO it's a good
deterrent to protect against bad actors from suing us, and why it was
included. Fortunately we've never had a bad actor sue us to ever need to test
it in courts.

As mentioned in my parent comment you've replied to, I'll consider pulling it
into its own repo with a liberal OSS license, but it would be a lot of work
since it's included in a core library and any changes can't disrupt existing
Customers already using it. But wont be anytime soon as I'm already overloaded
with other higher priority features I have to work on.

> I may actually consider purchasing a license if the terms aren't trashy like
> in the current license above.

I've no intentions to ever sell any licenses to use #Script, it will always be
free.

------
bigtex
ServiceStack is one of the best pieces of software I have ever used and saved
me from WCF/WSDL hell back many years ago. Just the breadth of detail in the
release notes shows that Mythz puts a lot of thought and effort into designing
features. I just wish instead of Aspnet core MVC they would have just made SS
the web framework.

------
mighty_bander
This is the first time in a while I've seen something that really gets me
excited about software.

The promise of "run anywhere" has more or less been fulfilled by the web, but
it leaves a lot to be desired: shared code is duplicated on every site, the
only language available has... quirks to say the least, and performance is
always an issue. This seems to solve a lot of these problems, while usable
webAssembly is still a long way off (and doesn't resolve all the issues
above).

I have seen lots of cool stuff from MS wither on the vine. Hopefully this does
a little better.

~~~
s_y_n_t_a_x
> the only language available has... quirks to say the least, and performance
> is always an issue.

I see this a lot, can you point out which quirks still remain in modern JS?
Performance is quite fast with today's modern JIT VMs.

------
tkubacki
Why is .net core not taking the world by storm ? Because most 'real .net devs'
still work on .NET 4.x legacy windows apps.

~~~
pjc50
My personal opinion is that Microsoft's absolutely terrible naming scheme
fails to sell anyone on why it's different or important.

Edit: can anyone give me the one-paragraph rational for why Net Core _should_
take the world by storm? C# is a nice language and I'm a mostly happy VS user
(except when I have to fiddle with MSBuild), but why should I go in and change
the dropdown from ".Net Framework 4.5.2" to ".Net Core"? Let alone why any
user of, say, Python or Node should drop everything and come over to C#.

~~~
pjmlp
As someone that has been on and off .NET since the pre-release days (thanks to
working at a MSFT partner back in the day), the constant reboots from the last
couple of years, and breaking changes across .NET Framework and .NET Core
(e.g. WCF, EF 6 tooling), inspire a wait-and-see attitude among a large
majority of us.

~~~
kogir
Absolutely this. They changed names, project format, build tooling, etc faster
than the ecosystem could keep up. You couldn’t even be sure there existed a
set of compatible ASP.NET Core, EF, and standard library packages in nuget
without endless trial, error, and binding redirects.

I tried 2-3 times up to and including .NET Standard 2.0 to switch and got
burned by busted tooling and package conflicts every time. I’m starting a new
project now and am still wary.

~~~
LandR
Nuget conflicts is still a big issue IMO.

One of the major pains of my life as a .NET dev who does .NET core right now
is Nuget and binding redirects!

