Hacker News new | past | comments | ask | show | jobs | submit login
GPL Time Bomb – an interesting approach to FOSS licensing (boyter.org)
162 points by boyter on Sept 9, 2016 | hide | past | favorite | 116 comments

This is obviously much better than proprietary as people can potentially benefit in the future from your work and I thank you for being so kind as to share it and yet I would probably use something significantly crappier to have real open source and several other things seem problematic.

-- Others are unlikely to contribute to the proprietary fork.

-- What do you do about contributions to the gpl3 version they would be copyright their creators and couldn't be part of a closed source version even the authors without copyright assignment.

-- Do you backport fixes to the gpl version. It would be far simpler to say use the new version wherein issue foo is fixed. If you do its a lot more work if you don't the gpl version isn't just a older version its a known broken pos that will never be fixed.

-- What if people offer fixes to the gpl version will they be expected to assign copyright so you can use them in the proprietary version?

-- 3 years is an eternity. In 1 year someone could make their own version of whatever it is you are doing that is actually open source if it was really worth having it would also have none of the above complications.

To be honest I am not looking for collaboration at this point. The orginal reason for posting the source is because this indexes your source code and many raised concerns that it could potentially be phoning home with your code. Being able to see the code and build the binary distribution to hash check solves that issue.

The reason for the time delay is because I want to look after anyone who does use his in the event of my death or otherwise. It means you are unlikely to be stranded in the future.

I do want to move closer and closer to a full GPL model, however I also want to be paid. If the full version is GPL then what is a strategy to achieve this? I could feature gate but this is also hated by many as seen by the nginx model.

If someone can come up with a better model then "sell support" and have a clean soul I will be all over it. Till then this works in a way that's adventagous for myself without being too restrictive in the future for others.

Define that all the external contributions must be dual licenced Apache Public License v2 and GPL, that way you can integrate it to your lead version (commercial licence) because APL2 allows it, and also you can release it after 3 years in the GPL branch (or rebase it to the current GPL edition right away). This way you don't need the contributors to sign anything and aligns well with your model.

Yeah I agree... I like this idea in theory. But in practice I think you will end up with two major versions: "latest commercial version" and "latest GPL version".

And then people will want to patch the GPL version and not the latest. 3 years is a lot of delta... git is really good at applying patches, but I wouldn't want disincentivize massive refactorings.

> What do you do about contributions to the gpl3 version

Lets define contributions. The author of the project can request that contributions to their official branches are done with additional permission for the proprietary version. If people don't accept, they have to fork the whole project.

We also have contributions to unofficial patches inside distribution repositories. Debian patches would for example not be able to be directly patched into the proprietary fork without additional permissions.

These concerns are why I tend to dislike the GPL.

The gpl is pretty much designed to maximize the freedom of the user by creating an environment where its impossible for to fork the work and keep it to yourself. Its even hard for the creator as he could end up competing with his work so far + the community.

This might mean it is not in useful to you but it doesn't make it bad. In other news your motor home is probably not the best option to commute to work and living in your car isn't the best experience.

I don't see anything GPL-specific about these concerns. The same concerns apply when you replace the GPL by any other non-proprietary license.

If I understand correctly, I think it is somewhat GPL-specific. You basically can't port fixes and new features from a GPL codebase to another codebase that is not under a GPL-compatible license.

I think you don't have this issue with more permissive licenses like MIT/BSD. At least then you have a chance of having the commercial-licensed one having all the fixes from the open-source version, in addition to its own fixes and new features.

(My understanding of open source/free software licenses can be quite fuzzy, so correct me if I'm wrong.)

You can't port fixes and new features unless you have a license to do so. That's true in all cases. If you only license you have is GPL, it doesn't allow you to use those in a non-Free way, which I think is the point you are making, and I agree that's how it works.

But that's a feature of GPL, not a bug.

If you are a company producing code and trying to make a living from it, it's risky to release code as BSD/MIT unless you can afford to have someone clone it, close it and sell an improved version, passing it off as their own without giving you anything (like Microsoft did with the BSD TCP stack, and with NCSA mosaic for example). If you release as GPL however, that can't happen. It's much safer in that regard, and more socially considerate too, which is why it's the license of choice for most Linux distro vendors and other major open source vendors such as MySQL.

Yes, I do understand that people can take the BSD/MIT codebase and make a proprietary/closed source version. In that case you don't even see how the bug fixes are implemented in the new closed source version. So you are free to independently come up with the most obvious, efficient fix.

My point is that with GPL, the implementation of the fixes/new features is right in front of you, you see it, yet you can't merge it into your GPL-incompatible codebase. Let's say we are talking about a security fix that turns out to be really easy. Somebody patched it in the GPL version, the fix turns out to be dead-easy and obvious, but now you can't use the same dead-easy and obvious fix in your own non-GPL version because it would be a violation of GPL. So now you have to come up with a suboptimal, ugly fix. In this case, GPL makes it painful for the original author of the proprietary version.

Yes, I do understand that people can take the BSD/MIT codebase and make a proprietary/closed source version. In that case you don't even see how the bug fixes are implemented in the new closed source version. So you are free to independently come up with the most obvious, efficient fix. My point is that with GPL, the implementation of the fixes/new features is right in front of you, you see it, yet you can't merge it into your GPL-incompatible codebase.

There BSD/MIT licenses don't prevent you from doing this either, though it's possible in practice it happens less. You can create not only closed-source proprietary forks of a BSD/MIT code base, but "source-available" or "shared source" proprietary forks, where the source is public but under a proprietary license that prohibits unauthorized redistribution or derivative works. There's nothing in the BSD/MIT license that requires you to keep your proprietary forks secret.

"My point is that with GPL, the implementation of the fixes/new features is right in front of you, you see it, yet you can't merge it into your GPL-incompatible codebase."

1) You almost certainly can as long as it's trivial, or you didn't look at the fix but did it independently based on a description of the bug. Legally, it all comes down to whether your work was a derived work or the original, not whether the result looks the same.

2) That's the idea anyway! Allowing someone to copy the work of others into a codebase that doesn't allow similar copying is exactly what the GNU GPL is designed to prevent. It's a risk you take if you decide to maintain a proprietary fork.

K_sze's point was that it is a lot harder to prove you have not seen and were not inspired by publicly available code than it is to prove you were not inspired by code that was kept secret.

And while someone using free software in a non-free fork can release the changes as shared-source leading to the same problem, this has rarely happened.

Independent creation is a valid defense against copyright (as contrasted with patent law where it's not).

If the fix is dead-easy and obvious ("change that = in a if statement to an ==", "add a check for foo", or "make this assignment a 1 instead of a 0"), the GPL license of patch A doesn't prevent anyone from creating (from scratch) patch B that does the same thing. For legal proof purposes, you probably want to ensure that the author of patch B hasn't seen the contents of patch A, though for something as obvious as the cases I present, I'm not even sure I'd worry about that.

Additionally, you can always require copyright reassignment for the main repository.

Such things might not even be copyrightable.

" If you only license you have is GPL, it doesn't allow you to use those in a non-Free way"

I consider your wording deceptive. Why do fans of GPL engage in this deception? Stallman, the FSF and everyone else agrees that MIT, BSD, Apache and other are Free (as in freedom) software licenses and conform to the FSF definition of free software.

Therefore your sentence should be "If the only license you have is GPL, it doesn't allow you to use those in certain Free ways (non-GPL Free ways) or in any non-Free way".

While GPL licensed software is undoubtedly free software, the GPL is not synonymous with free software and by it's nature it is at odds with all other licenses free or non-free. It is incompatible with every other free license. I agree that the virality of copyleft is incredibly useful to drive adoption and resilience of free software but it is not the only way software can be free.

There are multiple ways to drive software freedom: social pressure, standards, law reform, etc. Between a project developed behind closed doors with periodical GPL code dumps and no community and an MIT/BSD/Apache licensed project with a vibrant and involved community I think the latter is a lot closer to the spirit of free software and is a lot more resistant to close sourcing even without the added protections of the GPL.

From the point of view of a user there is not much difference between:

1.a software maker deciding to abandon the GPL and release future versions of a project as closed source

2.and a software maker deciding to incorporate MIT/BSD/etc. code into a closed source project

And both are equally vulnerable to being turned into SAAS. The GPL does not guarantee software freedom for the users unless there is no CLA (and there are multiple copyright holders like in the case of Linux) or in the case of a CLA there is some other agreement like the Qt-KDE.

To make clearer the issue MIT/BSD/Apache/etc. projects have with the GPL think of it like this: It is the same issue you would have if you have a GPL project and you want to use an AGPL library or if someone creates improvements to your GPL project and releases the combined work (yours + his/hers improvements) under AGPL.

Any license that would allow you to take your fellow contributes work and add it to your own without requiring them to explicitly assign copyright to you would also allow a third party to make their own closed source fork of your work add improvements and sell it.

RapidMiner was doing something like this a few years ago. https://rapidminer.com/news-posts/rapidminerembracesitscommu... I haven't followed closely but I think they gave up on the complexity and started offering the same product as either AGPLv3 (a hostile license for the kind of customers who pay for software) or commercial license. A straight dual-license model reduces confusion about what is in which edition. If you are going to have an open and a closed product you really have two products, which should ideally have two separate reasons for existing. Just being the old version is not the right kind of difference.

> Just being the old version is not the right kind of difference.

In a purely commercial context this worked for some time for products like PagePlus: you would get an older version from on magazine cover disks. For many the older version was good enough to do what they needed, for others the upgrade path to get the extra features was obvious and they would often buy the newer version of what they'd already played with without even looking for alternatives.

Depending on the product I'm not sure I would trust an older version these days though. A desktop only DTP app like PP maybe, but anything online, at all security related, or just that I might put credentials into; I would have security concerns unless there was some sort of guarantee that security updates were getting back-ported. That and in a lot of cases there may well be a Free+free option as good as the 18+ month old version of [whatever].

As you and others have already stated, the straight dual-licensing model makes more sense from the user PoV (and maybe form the developer PoV too, though I expect opinion to differ more widely there).

Language matters.

The idea is neat, but "time-bomb" gives it a negative connotation. Instead maybe call it anti-abandonware licence, or public-benefit timer, or something else. (I'm sure HN can come up with a better phrase).

I had a similar idea years ago and the name I came up with was "Eventually Open".

It wasn't a case of abandoning code more gracefully per se, but simply that after a set period of time, code would be relicensed as open, regardless of the state of the business. So you might have a timeline like:

* Today: release version 1.0.

* 6 months into the future: release version 2.0.

* 12 months into the future: version 1.0 becomes GPL.

* 18 months into the future: version 2.0 becomes GPL.

* 24 months into the future: version 1.0 becomes MIT.

* 30 months into the future: version 2.0 becomes MIT.

And so on. The latest version would be proprietary but source-included, and previous versions get relicensed as soon as they age out.

The other alternative is to have the same mechanism, but with a donations system to speed up the relicensing. If your codebase is worth 30k to you, then if people chip in 30k, it gets relicensed immediately. If people chip in 15k it gets relicensed earlier than it would normally.

It's not a good alternative to open-source, but it's preferable to completely proprietary as it makes it possible for abandonware to be picked up and maintained by third parties, and it offers an alternative mechanism for funding development of code that will eventually be open.

I would love see a full post discussing just this type of scheme and implications.

I really like the donation to speed up access system. It feels like a libertarian wet dream for funding projects. It also opens a very interesting feedback channel between the community and the developers.

I am glad someone else is mentioning this; I have come to the same conclusion regarding non corporate software development a few years ago. It could potentially help, as well, closed source software, where the price would fluctuate (downward) depending on the number of initial buyers, so as not to inflate artificially the value of the product because of very sudden spike in popularity. Just a thought.

'Eventually open' sounds promising.

How about "GPL Failsafe"?

Fail-open license.

"GPL Time Lock"

Time-release open source.

Like the pills.

Auto-release time lock

how about just "auto release GPL?"

GPL countdown something?

self releasing license

I applaud the spirit of this, i.e. in trying to lay out a covenant with the community while still being entrepreneurial about building a commercial business to fund continued innovation and maintenance of the software.

The problem is that it falls into an outdated framing of the value of software. Namely, as more people around the world have gained significant expertise in coding, the skillsets needed to produce software is commoditizing. That skilled labor used to be scarce, and that meant that the fruit of that labor was scarce, and therefore the artifact itself was the thing to monetize.

Creative and clever licensing around software can "protect" software from certain kinds of things, but they cannot protect the software from being commoditized. And commoditization pressure is very high right now. Over the last 10 years, OSS has permeated into real enterprise adoption, and many of the deep reasons for enterprises to adopt open source software are tied precisely to those commoditizing factors.

So to build a sustainable business around software, you have to tie your price to the actual business value. In our modern times, when the skills to produce software are abundant, the thing that's valuable, then, is creating alignment on your API or framework or service, by earning the greatest mindshare among the collective labor pool that can maintain and innovate on software. And there's a huge virality to that, too - the game of developer mindshare is a winner-take-all game.

All this is to say: don't worry so much about defending the software, because that's not the valuable thing. The community around your software is what determines whether it is relevant 3 years from now. And having weird/new/different licensing terms can stifle the growth of that community.

I understand where you're coming from, but I disagree.

The skills might be abundant[0] but the effort and knowledge of the domain (business logic) are not available to many. It depends on the domain, games in IOS don't count for example, but I feel like there are lots of situations where the software can be directly monetized.

Lets assume that's not true - how do you actually monetize a community? Developers around a 'platform' are difficult to monetize. SaaS works for some things but not everything.

The idea that 'developer mindshare is a winner-take-all game' is true if your Google or Facebook - it's a total different game if you're one person or a medium sized software business.

[0] I actually don't think this is true. There are abundant skills to do trivial things, but skilled problem solvers for harder classes are still constrained - we can see that by the rocketing salary bands of developers over all compared to the rest of the economy (at least in the USA/Western Europe).

> Namely, as more people around the world have gained significant expertise in coding, the skillsets needed to produce software is commoditizing

I wish you were right, because finding good engineers is REALLY hard.

Being hard to find does not mean they are scarce. Also, sadly, it does not take good engineers to produce software. There are tons of average and bad engineers. They produce a lot of software.

It only takes good engineers produce maintainable, efficient, less buggy software.

Agreed. What a lot of people here in HN don't seem to realize is that the reason why Software Is Eating the World is because software can be really really bad, and still be better than not-software. When presented with "a pile of enterprise Java garbage code produced by crap devs that just barely works", your software customer's BATNA is "pencil and paper". That's a low bar.

And finding good software can be really hard.

This theory only makes sense if the number of things that need to be coded had remained constant, which isn't the case. There is still an insufficient number of good coders available to meet market demand.

You have another option, keeping the GNU GPL as a license and avoiding this time-shift complexity: sell the binary, and offer the source only to those who buy the binary -- don't make the source code public on github. It's not only possible but it's what sustained many GNU projects, until they were acquired by others.

Nobody in the comments mentioned the most successful case: Cygnus Solutions had been developing the GNU Compiler Collection (GCC) for good money, all under the GNU GPL. Notably, they made a lot of cash from a deal with Sony to support the original Playstation in gcc.

A good read about how they marketed Free Software on John Gilmore's pages: http://www.toad.com/gnu/cygnus/

> sell the binary, and offer the source only to those who buy the binary -- don't make the source code public on github.

The problem with that model in many software markets is that the proven value of the bazaar development model means that when you do that, eventually one of the purchasers of the binary is going to make the code public (because the GPL means they can), and once they do that, the cat's out of the bag, and people (both users and alternate service vendors) can roll their own binaries), commoditizing the software and reducing (likely, eliminating) your ability to charge for binaries rather than ancillary services like support and custom development.

Selling the binary is difficult, which is why it's best to provide a "service" of a mix of things which also happens to include access to the binary. Then, you can refuse to provide future service if the end-user makes the code public.

It's a bit sticky, because the GPL doesn't allow any constraint on distribution. However, the argument intellectually is that you're not stopping distribution you are merely refusing to deliver the "service" due to a breach of the service agreement - "I'm not stopping you distribute, I'm saying if you distribute then I won't be providing this separate service X".

Here's a 2014 example from a RedHat APAC service agreement:

"Distributing the Software or any portion of the Subscription Services to a third party or using any of the Subscription Services for the benefit of a third party is a material breach of the Agreement even though the open source licenses applicable to individual software packages may give you the right to distribute those packages (and this Appendix is not intended to interfere with your rights under those individual licenses)"


"Software” means Red Hat Enterprise Linux, JBoss Enterprise Middleware and other software programs branded by Red Hat, its Affiliates and/or third parties including all modifications, additions or further enhancements delivered by Red Hat.

URL: http://jp.redhat.com/licenses/apac_enterprise_agreement_appe...

Add to this idea the Redhat-Centos rulebook: Make the project name and assets with trademarks (non GPL) so if the customer wants to distribute the code they need to rip off the trademarks (name and images) from the project.

That definitely would only work where you can get paid for customisation. GCC is probably the best case scenario.

There aren't many megacorps that would pay you loads to customise a code search engine.

> offer the source only to those who buy the binary

But don't the receivers of the source then have the same right to redistribute it without charging?

And why would they do that? Try know well that they get support and features from the author, they gain nothing from sharing something they paid for. There is no economic incentive

People confuse Free Software to mean gratis rather than libre. It can be, but it doesn't have to be.

> People confuse Free Software to mean gratis rather than libre. It can be, but it doesn't have to be.

It doesn't have to be initially, but once you redistribute it to others with the permission to redistribute it that defines Free Software, the probability that you end up competing with gratis derivatives of the same code base tends to unity over time.

So, Free-for-a-price software really relies on a premium price charged to early users (often only the first user); IOW, its more like selling bespoke software development services than like selling other software licenses.

There is something similar for Qt. Back when Qt was licensed more proprietarily (with a GPL option for pure FLOSS), the KDE folks were worried that Trolltech could just release new versions as proprietary-only. Therefore, an agreement was reached and codified that, should Trolltech fail to do an open-source release of Qt for more than 12 months, the last release shall fall under the BSD License to facilitate a community fork.

Unfortunately, this doesn't support regular expressions, which is a very useful feature for a code search engine. See https://github.com/google/codesearch for one implementation of this.

Believe it or not thats actually one of the least requested features.

The most requested is the one I am implementing for the next release 1.3.0 which is historical searches across every commit for auditing purposes. That said I am working on experimental regex search support as well.

I remember Stallman once advocated a license similar to this (for things like games, so people can make money on them, then release shortly after. His timeframe was more like months though iirc).

A model that works well for games can be summarized as “free code, proprietary assets”.

But even freeing the assets eventually would be really nice.

There's plenty of creative effort involved around extending and improving existing content from old games, or making something new loosely or not-so-loosely based on the originals, but this often involves creating derivative works of the original proprietary assets which means these mods are illegal.

In some cases you can work around these limitations with code. E.g. in the doom community you find that making custom palettes is very popular nowadays, as the original makes some bad tradeoffs and many nice color schemes are out of question without a custom palette. But to completely overhaul the palette, you must re-do the original assets or create some sort of a mapping that source ports would understand.

Problem with this model is fact that in modern games a lot of code is scipts that are part of assets.

This was done twenty years ago with Ghostscript, google for AFPL to see the details. The author made enough to retire, so it can work for some people some of the time.

Ghostscript was dual-licensed, and not exactly the same as this scenario; though the end result is pretty similar. The Ghostscript folks never set a specific date on when the proprietary version would be GPL, as far as I know; they would do new releases of the proprietary version, and then the older and slightly less capable version would be open sourced.

That's not to say calling it a time-bomb makes it an entirely novel idea. My company has been doing it for 10+ years now with Virtualmin (which has a GPL and commercial version, and we roll the commercial features down into GPL as new features come along in the commercial version, and as we can afford to do so). But, honestly, it's kind of an awful business model. We've been making a living at it all this time, but I wouldn't call it a success; we'd make higher salaries working for others. I'd like to find other ways to make a living from Open Source, that pay better (and aren't doing service contracting), but I haven't had much luck at it in 20 years of trying.

ISTR there being a promise mentioning some period... 18 months? I don't care though. I think L. Peter Deutsch made his money by means that have ~nothing to do with the license. His licensing didn't break his business model, that's all.

My own little palace is also largely paid for, and open source has something to do with that pleasant fact, but I hindsight I don't think licensing mattered much. FOSS licensing, and all the arguments about varieties of licensing, is a digression. Success comes from luck+work+xfactor, and whatever xfactor may be, license discussions isn't it.

It was a specific time period. I thought it was 12 months, but maybe it was 18.

Either way, Stallman didn't like it, but he was willing to work with it, because it was better than the alternative.

Proposed by MySQL's Monty some time ago under moniker "Business Source”.

My gut-reaction to the title was to assume (based on the negative connotation to "time bomb") that you had some code that was permissively-licensed (something user-friendly like MIT or BSD), and then when the bomb "goes off", it switched to GPL, rendering it unusable in most commercial software.

I'm planning to do something similar with some of the source-available proprietary software that I'm writing nowadays. If I die or otherwise fail to maintain the software for some time (much shorter than 3 years), the license will revert to GPL.

This kind of arrangement might be more difficult to pull off when there are multiple copyright holders or if some of them are corporations. But for projects maintained by individuals or a small group of like-minded people, I think it hits a nice balance between making a profit and giving back to the community.

I also had a similar kind of license in mind. My idea was: the software becomes lincensed under an open source license once any one of these happens:

1. I earn x amount of money out of my work

2. It's n seconds since EPOCH

3. I am pronounced dead by a qualified proffesional or nobody has heard from me for m years.

#1 is difficult for other people to verify.

#3 needs a better definition of "nobody has heard from me". Has anyone heard from you if it becomes widely known that you made a billions dollar from an unrelated business and retired from programming? It will probably work better if you say something like n seconds since the last commit, or since your last public activity on your Github, HN, or Twitter account.

Anyhow, it would be useful to have a standard, legally proven way to make these kinds of promises. Non-lawyers like me trying to be too clever are likely to leave serious loopholes.

Regarding #1, I'm assuming my own good faith in this :)

#3 in the second clause is indeed tricky, but I suppose it could be worded in legally unambigous way. And anyway I always assumed the dealine in #2 would be no more than three years in the future since the software is first published under these terms.

The model is simple, each version 'expires' and falls into free software domain after some specific time. If you stop making useful new releases your users fork the last good release. That's it, no need for more complex mechanisms.

If you really want to make money, it's probably not the best idea to put a fixed time into your time bomb, unless you are targeting a fast moving platform like mobile OSes. At some point your previous version will be sufficient to 99% of people and any new features will be just nice-to-haves. Maybe you can consider per-feature time bombs? You'll still have time to build a sustainable business on top of it, still allow people to study/modify your code, but with greater control over your cashflow.

I considered that but assuming things get to that point I feel I will have either done well enough for it to be a moot issue or I have run out of ideas. At this point I feel it should be available for all to use.

I think that having a license that is both open source and that protects the creator's ability to earn money from his creation (thus paying for it's maintenance really) is a very good and important idea.

Personally though I wouldn't go with the TimeBomb idea, I think that if I ever get the chance I'll decide on a single expected revenue stream (such as sass hosting) and provide an open source license for use except for that purpose.

I had considered that but since this is a product that indexes source code a lot of companies want to host on premise.

I'm not sure if this will work as it is currently, and here's why:


Clearly shows that it is released under the Fair Source License, version 0.9 with no mention of license termination and restricted rights. It is NOT free.


then states:

'After the following date 27-August-2019 you may choose to use this software, version "1.2.3" or "1.2.4" under the GNU General Public License Version 3 with terms specified at https://www.gnu.org/licenses/gpl-3.0.txt'

This is so wrong. Not that it is GPL, but this both contradicts the license and states that you "may choose to use this software..." under the GNU GPLv3. Also, the missing comma after "1.2.4" is a mistake in grammar.

I'd say, as-is, you should consider this licensing unreliable. Yes, he posted in his blog stating his intention, but as it is now, it would appear that if a ruling had to be made on the actual license, it could very well be that the only valid license is the one in LICENSE.txt.

Since that is unclear, though, if I were a user and cared about the license, I'd get a good lawyer to figure this out before making any assumptions.

And, I would suggest that he get a lawyer to help craft the required changes to his license.

Dual licensing happens all the time, often with GPL and some other, more restrictive license. He clearly states that until X date, you may only use the code under the Fair Source License. After X date, you may choose which of the two licenses you would like to use.

There's no conflict in adding another license, it's his code, and the license and his directives dictate how people can copy and distribute it. Nor does the fact that there's only one license in LICENSE.txt really mean anything. README.txt is clear about the dual license in its "Licence" section.

What about the following text in README:

'If you are building from source then you get no support and must work within the restrictions specified of the fair source licence (see LICENSE.txt for details). To purchase support see https://searchcode.com/product/#downloadlinks'

And what about:

'Use of this software is governed by the Fair Source License included in the LICENSE.TXT file'

No period there at the end, but that seems to indicate to use the LICENSE.TXT.

And then, even worse:

'In order to deal with the case of my death or this software becoming abandoned it has a time-bomb where the licence will change exactly 3 years after the publish date of a version release. This means that if version 1.0.0 was released on 1 July 2010 then it can be taken using the listed alternate licence on 2 July 2013. This licence, version and time is all specified below.'

There is no definition of what 'software becoming abandoned' (Which 'software'? What does 'abandoned' mean?). There is no definition of what 'it can be taken' means. The example date is one day more than three years and the dates given as examples could confuse the date intended for expiry. There is no definition of what should be used as the 'publish date of a version release'.

While these things may seem common sense to a developer, they should have a clear legal interpretation.

> clear legal interpretation

In US, those only exist from precedent. Which means after going to court and getting a ruling, often several times as different courts will rule differently. Eventually being normalized by supreme court.

The US legal system is not well-speced or deterministic for new concepts.

You're picking nits. The intent is clear from multiple reproducible sources. For there to be any issue, the developer (or an assignee) would have to file suit, at which point it would be trivial to demonstrate that it was clearly communicated that the old versions assumed a second license. The copyright holder would have a very steep uphill battle to show otherwise.

Actually following that time frame I will be updating the fork to relicense to avoid this issue. I had hoped that the intent mentioned was clear enough to avoid any issues.

If someone with legal chops wanta to provide a nice legal way of saying that feel free to do so and I will provide due credit.

Great! Might try contacting FSF. They could help you get it sorted:


I like the intention, but a few thoughts: - If you're dead, to whom have you legally clarified copyright should go? No one but that person can enforce the GPL, because the foundation of enforcement is that it's otherwise copyright violation. - IIUC, new releases don't reset the date of old releases, so old releases become fair game after a few years. The reason that doesn't help people is that most of the value is in what you're doing right this very minute and your ability to support that today. That is why companies can make money from existing licenses. They're paying your for support, paying you to develop new features that matter to them, etc. But at the same time they can accept collaboration and contributions from even competitors right now. I think you're losing most of the benefits of open-source for making money despite the time window.

I have been toying with a similar idea, but for born-FOSS source projects.

I like copyleft licenses but I find the legalese in them too complex and I fear that they will cause problem down the road because of changes in the legal landscape. I am also worried about leaving code around that is useful but unusable by other for legal reasons. For all these reasons I would like to license my projects like this:

  * They are born AGPLv3/OHL.
  * All the published revisions older than 5 years are
    released into the public domain (CC0).
Simple and easy to state, incredibly complex to write down. Especially if you want to make it enforceable without me (or the other contributors) being alive. From what I understand, the concept of a "legally binding promise" is even more fuzzy across the jurisditions than that of a "simple" copyleft license.

> From what I understand, the concept of a "legally binding promise" is even more fuzzy across the jurisditions than that of a "simple" copyleft license.

Couldn't you work around this by granting usage rights now that you're only allowed to exercise in three years?

Contracts with specified durations are quite common, including those whose start date is in the future (like, renting a booth or a flat for a specific duration).

IIRC, Ghostscript used a scheme like this prior to 2006.

Yes, I believe that's true. I was reminded of it a few months ago when someone was asking for advice on how to monetise some software that they felt would require ongoing effort. If I remember correctly it was widely disliked, but perhaps the world has changed in the last 10 years!

This is an interesting take on licences that turn 'abandon-ware' in to public domain or close to public domain code when the maintainers are unresponsive.

I like how it mandates that there are 3 years for innovation to occur within. However I feel like the license before that needs provisions for things like the ability to make local changes as needed, and also to publish /security patches/ freely.

Edit (Beneath):

The impression I got was that he has ONE version, and a built in escape clause for anyone using it. I took the view of this licensing scheme ensuring he'd have to 'compete' against a 3 year old version of the product with compelling features; not that there'd be an intended 'free' version of the product.

He's definitely assuming that this commercial version remains primary:

"I will be forced to continually improve it and upgrade if I want to keep a for sale version without there being an equivalent FOSS version around (which in theory could be maintained by the community)"

But, is mostly discounting a community fork, or divergence between his commercial version and the older GPL version. If he receives patches he'll have to have a copyright assignment policy so that he can apply the features to both trees - which will risk a fork as many people strongly dislike them.

I dont think hes expecting other people to contribute code to his project whilst hes working on it.

That is correct. I do not anticipate much feedback from others.

I made a very similar proposal back in 2003, which I called the Temporary Proprietary License, or TPL:


I interpret this as "I don't want to collaborate with you people yet - I want this all for myself because I think I can make more money that way. But in case I fail, I'll change my mind and hey let's work together!"

No thanks.

GNU GPL is an excellent choice for a license for a commercial product if you do it right. It fosters collaboration and community from the start. Look around at the most successful companies whose major products are open source, especially the GPL ones. Note that none of them started off refusing reciprocal collaboration with potential contributors.

You might be right in part: it's his product and his business and I'm not sure he means for the community to contribute to his wealth (like you say "I don't want to collaborate [yet]" is probably more or less accurate). However the "I'll change my mind and hey let's work together" part I think is wrong.

He provides the source for people to see in the first place. Assuming there are no patents involved, that makes anyone free to re-implement ideas there, which is a risk for him, but nice for everyone who wants to see source code of stuff they use (I do). Then, when it turns out he no longer needs the product, it's free for everyone. If people don't find it worth the money but do want to use it and hack on it, they're free to do so, with or without him. So he's not asking to work together or for help in later years, he's giving the opportunity to use it after he stopped doing so himself.

Re-implementing "independently" once you have seen the source code can be legally problematic. (see https://www.gnu.org/software/classpath/faq/faq.html#faq3_2 ) for an example.

No longer needing the product kind of means that it's failed. In which case, why would it suddenly be valuable to others with a simple change of license?

It's more likely to succeed in the first place by fostering collaboration from the start. This is how successful open source projects operate. It's all about community, mutual respect, and bi-directional sharing.

Having the source available but not open (yet) strikes me as a cynical attempt to appear open while retaining control of other peoples freedoms, and I for one would never work with such a project. I'd probably rather use a completely closed product with no source available; at least you're getting something that's not pretending to be more open than it really is.

Actually the reason I posted source was not because I wanted collaboration but due to fears that it was somehow phoning home with your valuable source code. I wanted resolve this issue by allowing anyone to vet the source code before rolling it out.

It's not about wanting to appear open and deceive anyone as its not an open source project. I'm open to change this in the future though if circumstances change.

Actually it's nothing to do with collaboration. The source is fair source because I want you to be able to check that there are no phone home methods sending me your source code.

The GPL portion is there to ensure that if someone does use this and I loose interest or die at a specified time they can continue to use it as they see fit.

I'm not trying to deceive anyone through these decisions.

It seems to me that a lot of strategies to fund the development of open source software are over complicated reactions to our failure to voluntarily fund the infrastructure that technology relies on.

I also have to wonder if instead of coming up with more and different ways to do so we ought to just start taking out our collective wallets and paying for things that are useful without expecting a t-shirt.

a) Site is down, google cache is here http://webcache.googleusercontent.com/search?q=cache:NBcmXVo...

b) The license file on GitHub does not mention GPL, a time frame or something even remotely related to the post - looks like some sort of shareware license.

c) If it's a good product today, will it still be a good product in 3 years? In today's version? I doubt it.

Still better than just selling binaries, but not by much.

> b) The license file on GitHub does not mention GPL, a time frame or something even remotely related to the post - looks like some sort of shareware license.

The README.txt does: https://github.com/boyter/searchcode-server/blob/master/READ...

Yeah that tripped me up too. The article had no links so I clicked the tweet on top, checked out the license file, saw nothing of the sort, and as a last hope scrolled through the readme. There at last.

Something for me to fix. I will sort this issue out over the next few days.

I for one welcome this experiment.

Making money from Open Source is hard, and while this isn't quite about making money from Open Source, it's still an interesting experiment in this direction.

as long as you are going to experiment, why not use a smart contract to implement your license? If someone meets your reserve price, it goes open source earlier. You can have a salvage value close 3 years in the future if the terms of the Code Tontine are not met.

For the record--this is basically the same as http://bit.ly/toxicBSL, http://bit.ly/bslMScl, therefore the same arguments apply.

Next time can you not use a URL shortener but instead use cliff notes[0]? Mysterious links (especially from new users) definitely arouse suspicion of phishing/malware.

[0]: like this

/toxicBSL => http://swanhart.livejournal.com/140324.html | Basically Shitty License

/bslMScl => https://falseisnotnull.wordpress.com/2016/08/24/thoughts-on-... | Thoughts on MaxScale new license

This almost but not quite sounds like the concept of public domain.

Public domain is a specific legal term denoting that something is entirely without copyright protection. His project is still covered by copyright using terms set forth in his license agreement.

Be aware that the phrase "public domain" is often misused to describe content "publicly available on the internet" or "in a public space". Usually that content is indeed covered by copyright since that is the default in law. Copyright applies automatically from the moment something is created.

I think the grandparent meant the rule that a copyrighted work becomes public domain after certain period of creation or author's decease.

Except that GPL is not at all like public domain. An MIT- or BSD-style license might be close enough to public domain to count.

> Copyright applies automatically from the moment something is created.

That only became true, for US jurisdiction, in 1976 https://en.wikipedia.org/wiki/Copyright_Act_of_1976

The original purpose of Copyright and Public Domain and stated purpose of time-bomb license are practically identical.

To promote creation, innovation, etc by providing a limited period of monopoly to authors (implication being to make money on it). After which the work would join our shared cultural heritage (in the Public Domain).

It's only the perverse twisting and expansion of copyright in modern times that makes such a "new" license required.

Where did I say anything contrary to what you just wrote?

Not "entirely without copyright". Once you create something the moral copyright is yours forever.

What this means is that nobody else can claim they did it, even if its in the public domain.

I cannot claim i wrote the Shakespeare works even though they are in the public domain. He still has the moral copyright over them.

This is only true for countries like Germany and France, where a more accurate translation would be "authors' rights law" or "creators' rights law", instead of "copyright law".

In countries with an actual "copyright law" like GB and US, things are different. There may still be "moral rights", but not nearly as good we know it from Germany and France.

In order to prevent ambiguity "moral rights" is the term generally used for what you are calling "moral copyright" as I understand it.

But you are correct, except with the note that because moral copyright rules vary by jurisdiction it's not necessarily "forever".


Actually, in the US, you can!

I hate when people don't even try to make money off FOSS

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