
GPL Time Bomb – an interesting approach to FOSS licensing - boyter
http://www.boyter.org/2016/08/gpl-time-bomb-interesting-approach-foss-licensing/
======
michaelmrose
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.

~~~
rocqua
These concerns are why I tend to dislike the GPL.

~~~
wcoenen
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.

~~~
k_sze
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.)

~~~
martingxx
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.

~~~
k_sze
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.

~~~
sokoloff
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.

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

------
tibbetts
RapidMiner was doing something like this a few years ago.
[https://rapidminer.com/news-
posts/rapidminerembracesitscommu...](https://rapidminer.com/news-
posts/rapidminerembracesitscommunity/) 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.

~~~
dspillett
> 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).

------
anilgulecha
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).

~~~
JimDabell
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.

~~~
noobiemcfoob
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.

------
pwang
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.

~~~
thatfrenchguy
> 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.

~~~
njharman
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.

~~~
pwang
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.

------
randoramax
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/](http://www.toad.com/gnu/cygnus/)

~~~
dragonwriter
> 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.

~~~
slgeorge
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)"

Where:

"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...](http://jp.redhat.com/licenses/apac_enterprise_agreement_appendices_one_and_two_webversion_japan_20141111.pdf)

------
majewsky
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.

------
Scaevolus
Unfortunately, this doesn't support regular expressions, which is a _very_
useful feature for a code search engine. See
[https://github.com/google/codesearch](https://github.com/google/codesearch)
for one implementation of this.

~~~
boyter
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.

------
ktRolster
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).

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

~~~
clarry
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.

------
Arnt
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.

~~~
SwellJoe
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.

~~~
Arnt
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.

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

------
ubertaco
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.

------
kijin
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.

~~~
Mchl
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.

~~~
kijin
#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.

~~~
Mchl
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.

------
bitL
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.

~~~
boyter
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.

------
Illniyar
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.

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

------
MasterYoda
Got me to think about BSL that is something similarly.

[https://techcrunch.com/2016/08/19/mysql-founder-tries-a-
new-...](https://techcrunch.com/2016/08/19/mysql-founder-tries-a-new-software-
licensing-model/)

[https://mariadb.com/bsl-faq-adopting](https://mariadb.com/bsl-faq-adopting)

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

[https://github.com/boyter/searchcode-
server/blob/master/LICE...](https://github.com/boyter/searchcode-
server/blob/master/LICENSE.txt)

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.

[https://github.com/boyter/searchcode-
server/blob/master/READ...](https://github.com/boyter/searchcode-
server/blob/master/README.txt)

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'](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.

~~~
tghw
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.

~~~
IANAD
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'](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.

~~~
njharman
> 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.

------
TallGuyShort
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.

------
gioele
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.

~~~
perlgeek
> 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).

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

~~~
slgeorge
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!

------
mjevans
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.

~~~
slgeorge
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.

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

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

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

[https://thunk.org/tytso/TPL.html](https://thunk.org/tytso/TPL.html)

------
martingxx
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.

~~~
lucb1e
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.

~~~
martingxx
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](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.

~~~
boyter
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.

------
michaelmrose
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.

------
burgerdev
a) Site is down, google cache is here
[http://webcache.googleusercontent.com/search?q=cache:NBcmXVo...](http://webcache.googleusercontent.com/search?q=cache:NBcmXVo-
izcJ:www.boyter.org/2016/08/gpl-time-bomb-interesting-approach-foss-
licensing/)

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.

~~~
m3adow
> 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...](https://github.com/boyter/searchcode-
server/blob/master/README.txt)

~~~
lucb1e
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.

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

------
perlgeek
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.

------
jegoodwin3
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.

------
m-ueberall
For the record--this is basically the same as
[http://bit.ly/toxicBSL](http://bit.ly/toxicBSL),
[http://bit.ly/bslMScl](http://bit.ly/bslMScl), therefore the same arguments
apply.

~~~
jzelinskie
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

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

~~~
mthoms
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.

~~~
HugoDaniel
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.

~~~
vog
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.

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

