Hacker News Reader

Comment by iameli | Hacker News Reader

Haven't gone line-by-line on this one, but I like the new trend of "time limit" licenses. If I'm trying to start a business, something AGPL-ish might make sense in the short term to avoid bigger competitors copying everything we're doing. But that doesn't mean I want my great-grandchildren to be able to sue for violations 90 years from now. "AGPL for now, MIT later" seems like a good compromise.

View on HN

The issue with "time limit" licenses is that it effectively centralizes contributions.

As an independent developer, I won't want to write patches for a project that will have already advanced internally. Sure I can make a change, but instead of collaborative development at trunk, I have to fork the year-old codebase to make my change available to users. Or hope that the company behind the project picks it up and it becomes open source after the long waiting period.

As the company behind a "time limit" licensed codebase, this means I won't get much from the community in terms of code contributions. Patches that do get contributed are going to result in merge conflicts. Sure you can privately collaborate with selected other entities, and in that case you've reinvented the Android development model wherein the owner company (Google) privately shares code with phone vendors and releases it to the rest of the world at a later point.

In short, this model may work for companies that want the branding aspect of open source while saying no to code contributions or even community governance models. The recent KDE Free Qt brouhaha also shows that this can easily imply delayed security fixes for the open version as well as increased risks of hostile forks. I don't see this as a particularly popular model going forward, although I imagine it covers some use cases well.

  > As the company behind a "time limit" licensed codebase, this means I won't get much from the community in terms of code contributions.

Which 'in my experience' is the situation for the __majority__ of commercially driven open source projects. Most commercial OSS projects receive few contributions, most often around the edges. In these cases it may well be rational to protect yourself from large competitors (e.g. cloud vendors) taking your code vs losing some small contributions.

It's true that:

  > In short, this model may work for companies that want the branding aspect of open source while saying no to code contributions or even community governance models

Often it's not 'bad faith' that's driving these sorts of trade-offs in licenses. Rather, it's the harsh realities of trying to get open source business to work.

It probably won't be a "popular model" because there's lots of reasons for creating FOSS - from individual drivers to strategic - so by volume of projects etc. But, for someone trying to create an OSS business "time delayed" licenses are not bad.

You don't really need a new kind of license for that; you can just AGPL now, and release MIT later (assuming you're assigned the copyright for all the code).

That doesn't guarantee downstream users that later they'll in fact have the code as MIT licensed. The author can change their minds, or just thinks it isn't worth the hassle. (Or some big corp buys them and they won't care.)

Isn't that always the case if the author is the sole copyright holder (or all copyright holders agree)? (Meaning that regardless of the license the copyright holder can always choose to not distribute new versions under that license anymore.)

But that's completely different than having a released version that we know will be available as MIT in X months.

It might mean you can start developing something based on the code and when it becomes MIT you can launch it and keep your additions to yourself. (Let's say in case of a server side thing.)

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.

At that rate I'd prefer close sourced now, MIT later.

The advantage of AGPL now is that you can get your code into distributions / services that require your code to be under an OSD-compatible license (like Debian, Fedora, Travis CI, etc.) or a source-available one (GitHub, etc.), but it dissuades the AWSes of the world from setting up a competitor, and it may also dissuade certain corporate users from using your OSS release instead of your enterprise one.

can't you just release under a second, AGPL license for that?

You know that the Copyright started with a similar reasonable time limit. Here it's a year. But then lawyers and politicians extended the period and fine prints decade by decade, so that the original sense of the protection was overturned. Now it's a sham. Holding back fixes for one year is Apple/Microsoft like. Google also started holding back critical services for their Linux variant. No good compromise at all.

Reply on news.ycombinator.com