Hacker News Reader

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.

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.

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.

Such things might not even be copyrightable.

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

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

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.

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

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.