Fork me on GitHub
#off-topic
<
2020-12-19
>
Ben Sless13:12:07

qq regarding copyright and IP: If as part of my project I'm providing a ns which should provide a sort of drop-in replacement to clojure.core and the code in it is very similar, do I need to include the copyright heading from the original clojure.core file?

andy.fingerhut13:12:37

I am not a lawyer, but that sounds like a pretty clear case of derived code, and sounds safest to me if you would keep the copyright notice of the original file.

borkdude13:12:57

@UK0810AQ2 A colleague of mine made an "alternative" clojure core: https://github.com/dunaj-project/dunaj Maybe worth checking.

👀 3
Ben Sless13:12:36

It is fair to say the code is pretty derivative. The main question is do I need to just include a EPL1.0 header and/or keep

;;; Copyright (c) Rich Hickey. All rights reserved.

borkdude13:12:30

If have copied a couple of core namespaces and made modifications for graalvm. e.g. clojure.test. I left the original copyright statement on top

borkdude13:12:11

Maybe best to ask @U064X3EF3 about this

👍 3
Ben Sless13:12:10

Thanks for the answers in the meanwhile 🙂 We'll see what Alex says when he has time

alexmiller14:12:24

It’s not up to me, just follow what the license says. If you copy or modify the code... “When the Program is made available in source code form: a) it must be made available under this Agreement; and b) a copy of this Agreement must be included with each copy of the Program. Contributors may not remove or alter any copyright notices contained within the Program. Each Contributor must identify itself as the originator of its Contribution, if any, in a manner that reasonably allows subsequent Recipients to identify the originator of the Contribution.”

alexmiller14:12:21

It’s your legal responsibility to read, understand. and follow the license

Ben Sless14:12:59

Which is exactly why I'm here, double checking myself. I think > a copy of this Agreement must be included with each copy of the Program Answers my question

Ben Sless15:12:33

And I apologize if it appears like I'm being lazy, I'm neither a lawyer or a native English speaker, so I'd rather ask now than hire an international IP lawyer down the line

alexmiller16:12:24

I’m not trying to say you’re lazy or anything, just that I can’t advise as requested other than to say, follow the license, that’s why it exists

👍 3
Ben Sless16:12:50

No worries, just trying to make sure I'm actually following it and didn't miss anything, which, for example, I think I missed the requirement to include a copy of the original licence in code form distribution, so it's good that I'm going over it again and asking questions

p-himik16:12:59

Just noticed that my app restarts more often than it should on Heroku. Apparently, it's supposed to: "Dynos are also restarted (cycled) at least once per day to help maintain the health of applications running on Heroku". Not sure how I feel about this approach...

Timur Latypoff16:12:38

I think this approach is pretty rude, but also it is very practical. At least it forces developers to ditch the assumption of "always on", to think about proper persistence of state and fast startup (which are all important for proper on-demand scaling as well).

p-himik16:12:11

True. But this practicality is a one-off. When I adopt that approach, I no longer need that kick up the butt every 24 hours.

andy.fingerhut16:12:36

I do not know the reasons they do it, but I have heard that AWS charges people less for CPU rental if they are willing to have their application shut down on short notice. I suspect this is cheaper for AWS to provide, since it allows them to re-balance load on a time basis of their choosing, in case things became unbalanced, and/or some new higher-priced offers to rent bare metal machines or clusters come along later.

p-himik16:12:04

The AWS approach makes sense. But it's unlikely that it's related to Heroku - after all, they promise you a particular uptime and this cycling is unconditional (assuming you don't restart dynos yourself - then the timer resets).

orestis17:12:33

I think this is more related to common practice of Python/Ruby apps that would restart after serving eg 100 requests to avoid memory leaks.

😱 9
💯 3
😆 3
javahippie17:12:07

As I understood it, Heroku restarts your application once a day to apply patches to the underlying engine and pods, if they are always on, there was no way to do this. If you need 24/7, you have to throw some bucks in and scale up to two nodes. If you have two, Heroku will perform the restart at different times, so your app will always be available

orestis17:12:37

That’s actually a good strategy. AWS applies managed patches to Elastic Beanstalk and relies on your rolling policy for HA

p-himik17:12:11

@U0N9SJHCH This is separate. At least, according to my understanding of this sentence: "In addition, dynos are restarted as needed for the overall health of the system and your app". I can understand a restart every other week or so because of some updates (and even then, AFAIK in principle containers can be suspended and resumed on a new host). But "every 24h" goes beyond that.

javahippie17:12:14

This is the sentence I’d interpret as “applying patches”, but you are right, it’s very ambiguous.

noisesmith18:12:20

yeah, heroku started out as a ruby oriented service, and the only way to run ruby apps is to constantly restart to constrain memory leaks

noisesmith18:12:08

I've run clojure apps for a year + at a time with no memory issues...