GPL Time Bomb – an interesting approach to FOSS licensing
boyter.org
boyter.org
-- 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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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).
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 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.
Like the pills.
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.
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).
I wish you were right, because finding good engineers is REALLY hard.
It only takes good engineers produce maintainable, efficient, less buggy software.
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/
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 aren't many megacorps that would pay you loads to customise a code search engine.
But don't the receivers of the source then have the same right to redistribute it without charging?
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.
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...
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.
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.
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.
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.
Either way, Stallman didn't like it, but he was willing to work with it, because it was better than the alternative.
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.
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.
#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.
#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.
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.
https://techcrunch.com/2016/08/19/mysql-founder-tries-a-new-...
https://github.com/boyter/searchcode-server/blob/master/LICE...
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...
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.
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.
'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.
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.
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.
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).
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).
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.
"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.
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.
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.
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.
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.
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.
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.
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.
The README.txt does: https://github.com/boyter/searchcode-server/blob/master/READ...
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.
[0]: like this
/bslMScl => https://falseisnotnull.wordpress.com/2016/08/24/thoughts-on-... | Thoughts on MaxScale new license
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.
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.
But you are correct, except with the note that because moral copyright rules vary by jurisdiction it's not necessarily "forever".
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.
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.