Affero General Public License (AGPL) Affero General Public License - Wikipedia
Pro: Popular licenses are easier to defend because they have legal precedent and everyone has invested interest in bad precedents not being set.
The Reciprocal Public License (RPL) Reciprocal Public License - Wikipedia
Pro: Removes the GPL’s “privacy loophole” enabling the hiding of improvements.
Preventing proprietary code leaking into the project?
What’s best practice for insuring proprietary code doesn’t end up in the project?
Example #1: Someone copies in their own code which they’ve licensed as All Rights Reserved on a different platform.
Example #2: Someone submits unlicensed code they’ve written which may technically be considered intellectual property till they’ve open source it even though they’re submitting it to an open source project.
Require all code submitted to the project be licensed by the author under the AGPL or compatible free software license, OR dual licensed (like Ghostscript) and useable by the project under the AGPL or compatible free software license OR require all code submitted to change ownership to the project.
Upon further further review it’s late and my previous edit was so so wrong.
AGPL does protect user freedom… Sort of. @MichaelTunnell has raised concerns that someone might use the source code without notifying the community. This is actually fairly common.
The AGPL v3 (and most other copyleft licenses) only requires you to make the source code available to your users, not to the original author.
They also do not require you to notify the original author or the community at large, that you have forked their project.
This means that the original project could be missing out on important feature- or security-updates.
AGPLv3 also has it’s section 7, which allows for additional permissions that some have interpreted (incorrectly in my opinion) as meaning you can require derivative work to include your branding.
Since their logo is their IP and they can deny you the right to use it in your product, this effectively makes it a proprietary product.
I see this as a conflict with the following statement, also in the AGPL v3:
You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License
I’m not sure I like the idea of a license that forces you to notify other projects of its existence. Seems very non-free to me.
I agree that that is a misinterpretation of the AGPL.
It sounds like the license decision is already been made because @MichaelTunnell wants the project to perpetually get publicly credited. The RPL is the only license floated that does that.
Oh well.
At the very least, if the product decides not to go with a copyleft license, please reconsider the Apache 2.0 or one of the modified BSDs
No no. I’m not even sure @MichaelTunnell is aware of the existence of that license. The license is very much up for debate.
There are many different concerns that need to be considered and the RPL is simply the only one I could find that addresses that specific issue. This is the reason it is on the list.
I don’t know what the best license would be but there has always been something that bothered me about the GPL. @kobberholm expressed that complaint fairly well.
I don’t like the fact that the GPL allows for companies to take code and then never even attempt to tell the original author that they are forking the project. This allows for companies to take open source software and effectively turn it proprietary as long as they release the source code in some obscure place and never admit where it came from. This is still not technically proprietary but it could still be presented as if it was and as if it was original code.
My preference is GPL for the most part but also a clause that requires a “reasonable attempt to inform the original author of the fork”. This wording I think covers the issue when it is difficult or when the author doesnt give a way to contact them because it only requires that they put in some effort to tell them rather than trying to force it to happen when occasionally it wouldnt be possible.
I would say that only a bare minimum would be needed from the forker of sending an email to the original author that is listed in the code to let them know it is being forked. This way if a developer puts out a way to contact and finds their code being used without even a notice it gives some recourse to address this form of proprietary by obscurity.
I don’t know if this is the best way to do it nor if this is even possible at all. I don’t know if RPL is a solution for this or not either.
I do know that GPL/AGPL is close to what I want but not quite.
I also know that BSD, MIT, Apache or any other incredibly permissive license is a big no thanks because those allow for anything to be taken and turned proprietary at the whim of any company. No thanks.
Please don’t make a custom license. It can become really problematic because now we have yet another corner case. Instead, a standard practice is to add “please inform me if you’re making forks or changes” in a README or other documentation. Plus, your custom license may not actually do what you expect it to, unless you get many lawyers involved. It’s really, really not worth it.
On the “how to make sure submissions are good” front, there are a number of approaches (including contributor license agreements), but I’d suggest using the Developer Certificate of Origin in combination with requiring Signed-off-by in commits. Check out this FAQ the Chef project put out when adopting this — it covers things pretty nicely.
And again, with this approach, it’s not engineers writing legalese. It’s a established practice you can just take up.
The EU published this nice tool to figure out the differences between most licenses. I think it’s best to find something that fits our specific needs instead of creating a custom one, as @mattdm mentioned.
That being said, I lack the knowledge to comment on legal matters. Even so, I think it’s unfortunate that the project might be stagnating before it’s even started because of legal issues! We’re trying to think of every exception and special case, which of course is important, but that’s assuming the project gains any traction and accomplishes its goal.
I think it would be fair if a restrictive license was chosen for now so that the project can get started and we can figure out the details later. Matt’s approach sounds very reasonable and well founded, so I think it covers most cases mentioned so far.
That’s an interesting site @chrismin13. I had never seen that before.
@mattdm Just to make it clear: There is absolutely no way we would be using a custom license. It has never even been suggested at our meetings.
The Reciprocal Public License is a niche license for sure, but it has been around for a long time and is approved by the OSI. It is basically a GPL v3 with an additional requirement. Should it ever end up in court, you would be defending the GPL and then just adding “AND YOU WERE SUPPOSED TO NOTIFY US ABOUT IT!”
It is not approved by the FSF, not because they don’t know about it, but because they see the extra demand of informing the original developers/the community about forks, is taking away some freedom.
