Discuss the license here

[haf]

...if you have an opinion on it. Keep it friendly.

License as its stands in master/beta:

• Logary as a library when used on IIS/Kestrel costs money; how much depends on how much you use it; quotes via e-mail.
• Logary together with other non-commercial OSS is free.
• Logary Facade v1-v3 is plain Apache 2. This is what all my OSS projects use.
• Logary Facade v4 I haven't decided yet, but it's tentatively the same as Logary proper. I'm considering changing this; because I want F# to have a happy path logging drop-in for Hopac libraries as well.
• Expecto accidentally used a Facade v3 that had changed header but not implementation; this was a mistake.
• Suave has never been involved in any changes; we've updated the repo to make that explicit.

Motivations for the new license is:

• if you use it on an obviously commercial stack, it costs money.
• if you use it together with open source, it's free.

GNU has a tendency to lock you in, it's extremely viral and can generally not be used with corporate software. I don't want that. I want people to be free to choose. I want the effect it aimed to bring: increased open source cooperation, but with a clean alternative.

Resulting TODOs:

• Clarify license / decide for Facade v4
• Clear CLA for contributions
• Improve wording away from "general design" in license.
• Clarify that Logary is free of charge unless it tells you otherwise while running, so just try it out
• Add license FAQ to README or similar.
• Consider changing the license to commercial=BSD, OSS=Apache?
• Idea: let people vote on the license at a cost of a caffe latte per vote?

[Thorium]

I cannot reason why not to use an OSS as logging is never business-critical for companies.

I think it is actually; perhaps you haven't reached that scale in your company yet or you have a low write-load.

You are right, our scale is minor, it'll take more than 3 years to build a software platform and try to make any profit out of it.

This is bit off-topic, but I don't agree that eventually the logging would be business-critical:

Logging typically generates unstructured data, i.e. the data is serialized to somewhere and then the reader, after some time passed, having lost the schema, tries to figure out later if e.g. the data is shaped Chomsky Type 2 grammar (context free grammar) or not.

That is un-optimal. Instead of logging you should save your data in a structured manner (to event storage or database, doesn't matter) so that you also have a history. That way you can do mining to your database to gather good business decision making information. So, you don't have to do mining logs or any other unstructured data. Structured data is a better and more maintainable way to store information than unstructured data. By saving structured data you store information in a way that its leverageable.

I support Rich Hickey's views about this: https://www.youtube.com/watch?v=-6BsiVyC1kM

seeing how quickly people turned coat when that happened before.

I disagree that "using a best tool for a job" would be turning coat to others. You have some control of what the best tools are for distributed (or micro-services) environments, which are your speciality. I've put some effort to SQLProvider to make the scenario of "F# data access" as good as possible. In some cases, people move to other tools like Rezoom.SQL for their "F# data access"-scenario, and that's totally fine. Actually, I've sent some PRs to these other F# data access tools also, and want to help people with those, as I already know quite a lot of that topic. In 5 years’ time I rather do consultation to some commercial product when they use F# data access rather than Go/Python. Currently the case with distributed computing is that the reputation is that the best environments are Erlang and Go.

Logary is not well known in F# nor .NET communities. Usually in London user groups people don't know it. Logary has 36K downloads in NuGet while log4net has 16173K, NLog has 13621K, Serilog has 10610K. So there is a long way to go. More people tend to know Suave. 36K downloads will not be enough for you to generate profit out of the product.

If you want to try, for Logary, I would suggest transaction-based licensing, and:

• slow down the event processing with a small delay that can be purchased away
• after certain amount of transactions, e.g. 1M in a month, there will be autogenerated events that do complain about licence to the log.

OSS will not auto-generate profit for you (as been cried by k_cieslak). OSS will allow you as the library author building your name as a brand. This is like a Michelin star restaurant: while the restaurant generate loss rather than profit, they will build the name for the chef who then can use it in a way they want. I know one who sold his name for Lidl advertising. If you try to cash-out the main brand (like adding half litre of water to every bottle of Coke) you will make some money for a short while. But many people will leave and not return.

I would rather buy some consultation hours from you (if you would be in UK), and I know that has been possible and not used a lot, but the reason is that Logary/Suave is just not well known enough, and not having enough people in the community, to be a relevant source of profit for you. Sorry about the negative-realistic-views, that's my Finnish mentality.

[ninjarobot]

Transaction based would be quite nice, I agree, hard to pull off in a library without introducing some licensing system to track usage, but maybe some "phone home" system could work.

Another model that works well is to provide the base platform as FOSS, offering features that target commercial and enterprise use under commercial licensing terms. Puppet and Hashicorp's Terraform are two great examples of this, and it doesn't seem like a stretch for Logary. The ElmahIO and Loggr targets are both for commercial systems, so people are paying anyway, same could go for the targets. Targets for WMI or Windows Event Log could be a way to provide commercial features for those that are monitoring their Windows systems.

[haf]

Also, adding a confusing license will also hinder adoption. I would have a straight OSS and Commercial license.

We can change the license; it's not a GA release yet. What licenses would you choose to pay for?

[haf]

slow down the event processing with a small delay that can be purchased away after certain amount of transactions, e.g. 1M in a month, there will be autogenerated events that do complain about licence to the log.

That could work, sure. But it also leaves systems up for failures to occur when they are under load and not otherwise. It would have to be very very explicit and well thought out to work.

[haf]

Might I also suggest that you open up publicly what the license fees are?

@isaacabraham I want this thread to as much as possible reach a consensus about how to:

1. Finance development of Logary
2. Improve development of the eco-system in F# (hence Kestrel, which is C#) — people improve what they use. Of course it's a competition between libraries and languages! and they peek under the hood in languages they use, not other languages.

@rmunn You have good points, but I'm not sure C# devs even would consider going away from logging frameworks written in C#. Do you think they would?

There are upsides to v5 that haven't even been mentioned:

• The Facades now support metrics out of the box
• There will be a corresponding logary-js package that ships client-side errors to the server
• Rutta has been revamped and now also functions as a docker container/router/shipper/side-car handling logs
• There's a new codec abstraction that lets you compose any codec (log4jxml, json, binary-fspickler) with any transport: TCP, UDP, HTTP
• Logary itself has a new event processing engine
• A new bisecting API and scope/span support for Zipkin

No other .Net logging framework has this. I think selling F# is easier if there's a complete story. Would you pay for a complete story like this?

The ElmahIO and Loggr targets are both for commercial systems, so people are paying anyway, same could go for the targets. / @ninjarobot

I don't think people will pay for targets; that's been tried the last two years to no avail.

@ninjarobot How would such a license be priced, do you think?

I'm thinking it to be a per-active developer, per-core-used license that approximates 2 days of my consulting per year for a large deployment using Logary. This is the quote I've been giving to those who have asked. One way to decide is this; everyone who pays a token sum of a caffe latte (45 SEK) gets a vote on the license and how it should be written. What do you say?

[forki]

regarding C# in kestrel: I don't think that's an issue. Giraffe and Saturn people did send PR to it.

[haf]

@forki Do C# people send PRs to F# libs? F# to Go libs? Do companies not mandate single languages making any contribution to another language political?

[haf]

@rkosafo Ignore @isaacabraham — if the web server is the OS and you can't avoid that, it's a different thing. Have you tried v5 with it?

[forki]

Yes a lot of "C# people" send PRs to fake and paket. Projects seem to be useful enough to learn a new language (or at least to learn just enough to fix their own problems).

Henrik Feldt notifications@github.com schrieb am Di., 12. Juni 2018, 18:33:

@forki https://github.com/forki Do C# people send PRs to F# libs? F# to Go libs? Do companies not mandate single languages making any contribution to another language political?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/logary/logary/issues/345#issuecomment-396653650, or mute the thread https://github.com/notifications/unsubscribe-auth/AADgNDojpFZIVCiuEsDfSRgxOp9jErTnks5t7-1igaJpZM4UiJNC .

[haf]

@forki That is not my experience. Let's agree to disagree then and get on topic again.

[forki]

Well, just look at fake's and paket's contributions...

Henrik Feldt notifications@github.com schrieb am Di., 12. Juni 2018, 18:46:

@forki https://github.com/forki That is not my experience. Let's agree to disagree then and get on topic again.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/logary/logary/issues/345#issuecomment-396657821, or mute the thread https://github.com/notifications/unsubscribe-auth/AADgNFdYPkhGNEZaJ_Qzs6rK1gOZ14hpks5t7_B9gaJpZM4UiJNC .

[isaacabraham]

@haf with respect, how on earth am I supposed to know that IIS on app service is a "different thing" to IIS on a plain VM?? I certainly didn't expect that to be the case. Where do you draw the line? Is IIS on a docker container ok? what about a VM?

Have you actually considered any of these cases?

[haf]

@isaacabraham Look, I want people to say what they think; I don't need you to explain the license to people. I want to hear what people think is reasonable, so while I recognise you want to help out, I'd prefer it if everyone get to have their say. I don't mean to offend you. Instead of being frustrated with me, tell me how you want it to be and show that you have a stake in the game. Are you a user of Logary, first of all?

[isaacabraham]

@haf I don't get it. In your earlier comment regarding Azure App Service, you specifically asked whether that runs on IIS. Since you didn't know the answer, I did and answered. Now you're saying IIS isn't the important thing. So what is?

Leaving aside this though, let's address your other point. We have customers that use F#, customers that use Azure, and some that use both. Some may use Logary, some may be considering it. As a consultancy and development firm, it's not just interesting but critical that we can recommend tools and technologies that have well understood license terms and roadmaps. If we recommend Logary to our customer and it inadvertently violates the license, think about where that leaves them, and indeed us? I've seen you contradict yourself twice in this thread regarding the license, which doesn't fill me with confidence - you can't just make this up as you go along, no one will touch this with a barge pole. At the same time I don't know what the pricing model is - so how can we even consider it?

More than that, I'm still not clear what your true motivations for this non-MS license is. Is it just about web servers, or might it one day include Entity Framework? What about JSON .NET? Both have F# alternatives - where does it end?

[haf]

@isaacabraham So you're not even a user then and you obviously have a chip on your shoulder. Your commentary is no longer needed here as you are not having this discussion in good faith.

[adamchester]

I don’t think it’s fair to mark @isaacabraham’s comments as off topic, and I believe they were in good faith. I believe he has a stake in the game. I believe he wasn’t just here to make trouble.

[haf]

@adamchester His comments are about my person and whether I'm duplicitous and that's not the friendly discussion that I want this to be. If he can rephrase his comments without attacking me, then it would be great.

[Thorium]

From what I've seen enterprise companies won't care the implementation language as long as component works well and there is a reason to use it. The people that do care about the implementation languages are not in low-level enough in organization hierarchy to control the actual real-world events. When a team comes and says "here is the service our customer needs, and by the way it uses component X", it's too late for company internal bureaucrats to deny the service from the customer.

So Logary could have a lot more users, like Paket. Documentation is in good level also. But the reasons why it's a better choice than log4net is not known well by the developers. It doesn’t have the reputation.

I return to NuGet statistics:

• Because of clearing of cache, breaking of machines, etc. one user can 5 to 10 downloads over few months.
• On enterprises you have also CI-machines. CI-machines usually do totally clear builds. Most of the developers download the components for building the environment, even if they don't actively use the product. So, if there are 10 teams, 5 developers each, and one team is using component X, one enterprise user may cause easily 500 to 2K downloads in few months. There could be sometimes enterprise internal Nuget cache but often it's missing as it needs some advanced configuration over multiple teams.

Logary's single release has only a few thousand downloads. We can expect that it's not used by many large enterprises, and there is something like 20 small companies or OSS projects using it. Small companies are agile to "turn their coat" as you phrased it.

[haf]

Ok, this is going nowhere. Thank you everyone for joining in. Further discussion can be done via e-mail and the license stands.

[lust4life]

https://www.visualstudio.com/wp-content/uploads/2017/11/Visual-Studio-2018-Licensing-Whitepaper-November-2017.pdf

Hi @haf , Does a license like this(visual studio community version) provide some reference? Maybe license like this will make peoples less sensitive to this issue? Even so, compare to the specific product, library's situation gets more complicated.

I think most here is focused on blaming the status quo instead of giving advice on the current situation. I have not seen anywhere says that the decision on the license has already been set. Issue title here is Discuss the license, I think it means that license can be the result of an open discussion. I suspect that the @haf 's main purpose about changing the license here is how to make logary operations more healthy (if no more developers are willing to participate in the contribution, then it may need some commercial support from the commercial users to continue to improve logary).

[Thorium]

What Logary would need is at least 10 consultant users who actively recommend it and take it into use in new companies and projects. This can be only achieved through good user experience. Including low learning curve and clear licence policies.

[haf]

@lust4life You're very right and I'm going to do a survey of licenses before releasing the new version. Like the license you refer to; the purpose and intent must be clear when people read the license.

@Thorium Agreed and in terms of user experience I think we're getting there.

[Thorium]

Would the commercial license include some consultation hours from @haf or other Logary expert?

Even though there is already very good documentation, I find that a) tutorials, b) best-practices are not well enough communicated. So to take real advantage of the library is still easily missed.

Some examples:

• How to log from a software library (that won't decide the targets yet but rather merges to user's targets)
• How to do efficient content-filtering based on events: some events skipped? some events sent to some targets only (e.g. a file target) while some others to another targets only (e.g. another file)?
• How the performance metrics / timings should work and be able to enable/disable it easily without spending resources when it's off?
• How to keep business code clean and not flood logging to everywhere, or at least keep the logging code as one-liner even though there are different parameters
• What is the real benefit of strongly typed parameter objects? E.g. in file-logging?
• What are the best practices to log an System.Exception, or attach more details to log for that without duplicating log-entires?

[haf]

@Thorium I think that's a great idea; and a good syllabus to get started. I don't mind spending a few hours for every purchase either, and all the consulting machinery is already set up.

Would you be interested in purchasing such a license yourself? Are these questions things you've been wondering about yourself?

[Thorium]

Well, those could be the questions if our software would have customers/events enough that logging would be a significant feature. I'm technical person and I don't make purchases. Those who do, want features, not technologies. So, it depends of pricing, but I wouldn't expect too much.

However, I already made a wrapper to replace Logary with log4net because I was trying to compile .NET Core and back in then Logary didn't support .NET Core/Standard.

[haf]

Summary; #351

Closing.