Hacker News Reader

Comment by jorams | Hacker News Reader

That is the license for the contents of the "ee" directory. The top-level LICENSE is Apache 2.0.

I don't know to what extent this code is integrated into the rest, but it's a valid way to develop open-core software.

"The concept of open-core software has proven to be controversial, as many developers do not consider the business model to be true open-source software. Despite this, open-core models are used by many [...] software companies." [1]

[1] https://en.wikipedia.org/wiki/Open-core_model

I rather go with this definition. Opensource != opencore. Despite this, you're right, that is the license for `ee` folder.

Could they make it open source by turning it into a library that a separate EE repo with a different licence includes? Would that stop it being open core?

I think it depends on the feature set that is available in the open source project. Often that exists to lure people in, but they quickly find out that the project is too limited or even crippled and they need the EE parts for an actual production-ready solution.

In this case the EE thing just has feature flags and billing things.

IMO it's fair to call it open source if you can reasonably use the open part of it in its own right, if the core stands alone and there's just some closed source plugins or whatever.

Where 'open core' is to be scathingly applied and '!= open source' etc. is, IMO, when you have a system with only some piece open, and other integral pieces not. Like an open backend but closed source clients, keys required so a third-party client wouldn't work anyway, etc.

That is because you are cherry picking the ideas you want from the wiki page. The first line reads:

> The open-core model is a business model for the monetization of commercially produced open-source software.

The open core movement is about finding a way to financially support open source development so people can eat and work on open source. It is quite obvious that the model which makes some of the code open source and some of the code not, is the best model we have right now. Some of the best open source is produced by these for profit companies. What are the alternatives? We'll before this model gained popularity, there was low quality open source or closed source alternatives for many of the projects we enjoy and see competition amongst today. All of this leads to a more vibrant software ecosystem.

Do you support open source in words or money?

I was with you up until that strange closing question.

The biggest complaint from open source maintainera is around freeloaders. People want projects and support for free, from primarily volunteer developers. Many toute the benefits without putting money where their mouth is. The open source community is more actively trying to figure out how we can support the creators, than it ever has been.

The question is about reframing how one thinks about their support of open source. The GP that is arguing that open core does not count as open source seems like the kind of open source user that wants it for free from volunteers without consideration for the effort and compensation that it requires and deserves. Open core is a valid way to build and support open source IMHO.

What features of supertokens are not open source and part of that "enterprise" directory?

I see a feature flag and a license check class.

https://github.com/supertokens/supertokens-core/tree/master/...

As of right now, nothing. The only thing that is in there is a license key checker and basic infrastructure for feature flags.

I am always wondering: If I take the ee directory and garble it through a LLMA, is it protected by copyright?

Does GitHub Copilot take the license change into account for the ee directory, or does it take the tag from the main directory?

Good question.

Does LLM prompt conversion erase license? Probably no.

Does LLM training erase license? ClosedAI argues yes.

Legislation is missing around it. There are many smooth sliders that blur line between yes/no where on one extreme it’s definite yes and on the other definite no.

Bonus-Question: If I am a malicious actor and just want to argue, obfuscate the fact that I blantly stole the code. Could I just prompt: Refactorate this code? Would somebody notice and could it hold in court?

This would, of course, depend on the code. But you could ask it to rewrite the code in another language, and add it; claiming it was your own work (which it is, just using an AI tool) This again opens up the debate of AI generated vs 'hand written' code...

I mean, if you--as a human--read that code yourself, learned how it worked, and then tried to write something similar later--even in a different programming language!--that is highly likely to be contaminated and considered a derivative work <- this is the reason why clean room design--where you have one team look at the original to write documentation which is then cleared by a lawyer to not contain any expressive intent before being handed to a second disjoint team to implement--is a thing people have to do. That GitHub Copilot is somehow afforded some kind magic assumption that it perfectly removes expressive intent is kind of ridiculous and highly unfortunate.

I find it terrifying that this type of reasoning is actually legitimate law.

Think about all the drive by licensing felonies everyone has comitted by accidentally reading open core code and then, at a later point implementing something vaguely related....

EDIT: Typos & punctuation

IANAL but that's why law has to be interpreted by judges rather than being a book of absolute rules.

Lots of codified laws are bent or modified by prevailing social attitudes, customs or precedent, so you could argue "I looked at it a couple of years ago and then independently decided to implement something similar" is a very different situation to "we read through the code and a week later started on a competitor".

Whether you'd get away with it is another matter, depending upon interpretation and perspective.

The clean room described above is a fairly bullet proof technique, but it's only been employed very few times and is not necessary to create an original work. Nearly every work was produced by people who were exposed to other copyrighted works. Unless something is a straightforward copy, it's a high burden to show that something is effectively a copy or translation. A lot of these kinds of things are untested in court probably because it's so difficult to make an abstract case.

Hmm, to be honest, I don't know. But I just found an article from Codeium and they stated some problems with licensing stuff with GitHub Copilot, here: https://codeium.com/blog/copilot-trains-on-gpl-codeium-does-....

Reply on news.ycombinator.com