[Edit] Interestingly, they cover that. I suppose if you're just running Pijul rather than integrating with its code, it might be safe to use in a corporate environment. Still, it's likely to be offputting.
I feel that AGPL for a product is misunderstood and pre-rejected without justification by far too many. Now, if you are developing a library, then AGPL sucks as a license for it, but for a cohesive product? Seems acceptable to me (not sure if it's my favorite choice)
Isn't that precisely the parent comment's point?
Perhaps it shouldn't be this way, but the argument is that the AGPL will make pijul "untouchable" by businesses, de facto.
Anyway I don't really care anymore. We act based on what we believe not on facts (this is not directed to any parent comments, to be clear). Whatever
You're saying AGPL shouldn't be offputting. He's saying that by some quirk of circumstance, it is.
In other words, his argument is that picking AGPL was a poor strategic decision, given its (admittedly undeserved) baggage.
This sounds like taking some of Pijul's source code and putting it inside another project. That would certainly have business implications, which justifies ninjas. It's possible to use AGPL as a business strategy (I worked at a company whose main product used CPAL[1] which has a similar network-use clause); but such decisions should not be made via VCS commit.
Of course, if the choice of AGPL prevents a business from reusing Pijul's code then presumably that's why they chose AGPL. That's kind of the point of copyleft.
I imagine very few businesses would care about Pijul's source code though. If Pijul matures into a compelling tool, then the relevant phrase would be "if you used an AGPL command"; no need for ninjas there, unless (as others note) you're building a PijulHub or something.
[1]: https://en.wikipedia.org/wiki/Common_Public_Attribution_Lice...
If you say "we don't plan to patch the code, just use the binaries as-is" then you're asserting that the software today your needs forever into the future. That's a terribly foolish bet.
A business founded on a principle of radical openness might be compatible with AGPL. But any business that wants to have some internal software (HR, etc) is well advised to stay the hell away from AGPL.
Yes, but this has nothing in particular to do with the AGPL and everything to do with copyright laws. There is no licence except public domain/CC-0 that allows BigCorp to incorporate other people's code without any obligations whatsoever (attribution, at least). Copyright laws forbid such incorporation by default.
I agree; one of the many reasons I'm against proprietary software is that it forces users into this helpless situation.
I don't quite get the "internal barriers" idea; is it common for companies to mix together code from multiple projects, including ones they don't own, such that it's difficult to disentangle them? Regarding your example, why would copy/pasting code from an internal code search be treated any differently from, say, searchcode.com? A modicum of diligence is always required regarding ownership, licensing, appropriateness, trust, etc.
Basically, ghostscript says you cannot distribute AGPL code with your commercial code, even though they are not linked together, not even on the same media.
Yes, you can, but if you add something - like issue tracking, user/access management etc.. around that then you need to publish that under AGPL as well..
It means it will never be part of something like github, bitbucket or AWS CodeCommit.
And then there are plugins to CIs (checkout from repository ...) - would those be affected?
If you are just calling the service through it's API (either CLI or through the programming language interface), then you don't need to distribute anything.
This just protects against people taking open source code GPL, modifying it for themselves, using it in backend services, and then never distributing their modifications.
afaik this means any kind of linking (static or dynamic), using a jar or using a npm package or similar..
>through the programming language interface
which implies some version of the above
That's contestable afaik.
> through the programming language interface
i.e. dynamically linking which is usually understood to be prohibited unless linking code has a compatible license.
> either CLI
Here's the problem - you can take any GPL library, make small CLI or REST adapter for it and license it GPL as well, then use that adapter from your proprietary application - is that still allowed? Because if it is then GPL can't ever be enforced and if it isn't you can't call CLI APIs even if original libraries themselves provide it.
However, I think if you just installed Pijul on a server and then called it through your operating system interface, then you _might_ be fine. You might need to make it so the interface to Pijul is generic and could swap out with other VC systems.
I still might also be wrong about this. I'm not a lawyer and the comments in [0] are on both sides of the argument.
[0] http://softwareengineering.stackexchange.com/questions/10788...
EDIT: edited to express less certainty over my interpretation of the license
Might, exactly. Depending on various courts accepting there is a loophole in GPL, and my layman understanding is that there isn't. Skimming GPLv2 I don't see them differentiating in derivative works between those that use compile time linking and those that use mechanisms like CLI. I'm weary of bringing after the fact constructs to justify something that GPL doesn't talk about. And after all how is CLI that much more different than dynamic linking - CLI is merely an interface that is subjectively a bit more friendly in certain situations but this imo shouldn't a have a bearing in legal discussions.
Mission accomplished?
It's easy to imagine wanting to add Pijul support to Tower, SourceTree, Gerrit, Phabricator, etc. - projects that all dwarf Pijul. But these projects will be unable or unwilling to risk doing so, because of the AGPL.
It definitely be part of something like Gitlab (or github, bitbucket or AWS CodeCommit), you just have to model your business around the fact that the software is available to everybody. You know, like wordpress (sure, they are GPL so they can have some proprietary components but the practical implication is that you CAN create your own, for pay, wordpress.com service).
Plugins can be a different story. Does the software have a rest interface? then use that, no license virality. If it doesn't, you release them AGPL
Now that we've started to use Pijul for the website (about two weeks ago), we want to change the license.
I'm slightly annoyed by all the political statements in GPL3, AGPL3 and several versions of LGPL, such as "you cannot use this on impure devices", or "you cannot use this on platforms with poor support for shared libraries such as windows or mac os" (by which I mean that these platforms don't have real package managers to handle dependencies, and the end user has to either (1) install DLLs manually or (2) install "unshared shared libraries", i.e. one full instance of the library per program using it, which OSX calls an "app").
I am not a lawyer, but GPL2 seems to be free of these. We're not likely to pick anything much more permissive for now. Also, the Pijul and Darcs teams agree that we don't particularly enjoy discussions about licenses, especially when they're not based on factual arguments. Here are answers we've already given:
- If you think that "a new anarchistic jurisdiction not recognizing any copyright law will soon emerge, hence Pijul should be in the public domain", we don't agree. The movie Dunyayi Kurtaran Adam, also known as Turkish Star Wars, is available full-length on youtube, to remind everyone that copyright laws may be broken, but not totally useless. Therefore, your dream country may not "emerge" that soon.
- Or maybe you think "I'd like to make a living from selling a small wiki based on Pijul, leveraging not only your research ideas, but also the database backend you spent 6 months full-time writing, as well as you SSH library. Why would you not allow me to do that?". The answer is: because if your wiki is useful, we want to use it too, without having to pay! What sense of fairness is this?
> But maybe we’ve missed something, and the AGPL actually prevents some use of Pijul that we’ve not thought of, and that does not aim at centralizing the internet. If this is the case, please discuss your idea with us on the mailing list.
Second, I wonder how many companies really had to change the source code of git, subversion, mercurial etc. What somebody could do is build a web services around it. As far as a service interfaces pijul with a system() it won't have any licensing problems. Encapsulate it into some RPC wrapper for extra safety. You might have to distribute the wrapper but it won't make it much easier for the competitors. The bulk of the web service can still be closed source.
Third, GPL licenses are fair to the original developers and the end users (they get to see the code they use). I understand why other developers might like BSD style licenses and we could spend another 30 years arguing about the virtues and the flaws of the two approaches. I won't get into that but given their goal of decentralizing the Internet I think they picked the right license.
Even that overstates the matter. Companies could modify the code all they want as long as they don't distribute that code. That would impact Github competitors - maybe 10 or 20 companies in the entire US.
Also, "distribute that code" can be interpreted very broadly. A contractor may access your internal HR system, and now you have to share it with them. A factory line worker may be entitled to the source controlling the robot fixture. A airline passenger may use the in-flight entertainment unit, and be entitled to its source. Etc.
Spot on for PHP and MySQL. PHP has its own license (kind of BSD?) and MySQL is GPL2 or commercial. I bet Facebook could buy the rights of any AGPL product, unless the owner is really firm about principles.
The thing they worry about is deciding what falls under AGPL. With GPL it is easy, if an executable leaves the building, source goes with it. With AGPL, when almost very thing is web connected, it can be hard to draw the line on what you have to open source (or just tell people you are using.. do I have to add every AGPL program in an Ubuntu server install, just in case one is getting used by something else?)
Whether rightly or not, https://www.theregister.co.uk/2011/03/31/google_on_open_sour... and other writings on the topic had a big impact on enterprise adoption of AGPL software.
There's also the fact that most prominent AGPL licensing tends to be around commercially backed software where the main backer owns all the source and is therefore in position to not hold themselves to the same standard of sharing changes as their customers and third parties must do.
I run a tiny business. AGPL is banned there too.
It isn't an "unreasonable fear". It is a reasonable decision based on mitigation of risk. AGPL is a risky license for end users; it goes too far beyond the Four Freedoms.
The speculation I have heard is that the terms "deploy" and "link" are both ill-defined and have not gotten proper testing in the courts. So there is no case-law saying that pushing your changed binaries to 1,000 internal sites (or even better: partially owned subsidiaries) does not invoke the clause. Or what does "linking" mean in the context of a database driver? What happens if a well-meaning employee loans out a modified binary to a customer to see if it fixes their problem? All of that makes lawyers nervous, and what makes one lawyer nervous has the potential of making other lawyers rich at their companies expense.
Just because you read something and come to a conclusion does not mean that people who come to other conclusions are "uneducated".
It's not about GPL, it's about GPLv2 vs GPLv3 and the requirements that come with it.