Hacker News new | past | comments | ask | show | jobs | submit login

Is it difficult legally to draft a meta-license that says "This work is licensed under X upon release; Y months after release it will be licensed under the terms of Z"?

Presumably you'd have to also specify what it means to do a non-release pull from their git repository -- when does that particular git commit switch to Z -- but that can't be too hard. Just make the clock not start ticking until a release is made, and if you want a safety valve for the case that someone wants to fork, or if the company folds and doesn't make any more releases, you can have a clause where it switches to Z after N*Y months or something, where N is chosen with an understanding of the usual release cadence.

I could understand how all this might be legally risky for another company to base their business on software licensed like this, but I kinda think that's ok. If we're talking about X=AGPL and Z=MIT, I imagine many non-corporate developers would be happy to use the software under the AGPL, while corporate types will -- as intended -- be more likely to use (for example) the developer's enterprise hosted version, or some other paid self-hosting agreement.




Hm, they could simply put the exact date into the LICENSE file upon release and be done with it.

So by default the code in trunk/master/main has AGPL license in the LICENSE file.

Then when they do a tagged release they just specify 2021-09-08 or something.

Also they can probably refer to the git commit date as release date for the code. (After all it's reasonable to specify a canonical place and method for source code access by the author in the license itself. That is, unless you got the code via this and this site then the code is unlicensed.)

Usually successful (widely used) code has simple licenses. Sure, in the future it's possible there will be complex licensed successful things. But currently big corps just don't really touch complex stuff, they spend rather large amounts on preventing these kinds of risks, even if that means buying an inferior software or reimplementing it. (But then there's also the risk of patent infringement.)

It's going to be interesting anyhow.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: