> weird poorly-documented helper scripts which have strange interactions
I've never found a packaging tool without an extensive and clear manpage with examples.
> I think the biggest issue is the social problem of the long and arduous process to become a trusted Debian Developer. Although there's now an easier Debian Maintainer option for restricted access, it's still not easy to become one. Other people have to go through a developer to update or add packages.
There is an arduous process to become a senior engineer in a FAANG, or a tenured professor, or an airline pilot.
> I've never found a packaging tool without an extensive and clear manpage with examples.
That might be fine if you already know which packaging tool to start with. Debian has several and it's not clear upfront which one is the preferred one. But even then I'd say that there is something like too much information.
And the process is complex. If I want to package a standard autoconf/cmake program, I have to do a lot of command typing. If you compare that to Gentoo, Arch or even Homebrew packages where you essentially edit one file and one or two command invocations, that's just cumbersome.
I recently tried to find out what I would have to do to for a NMU and I just couldn't find any entrance point that made sense to me. It felt like trying to get into a cabal and all the information is encoded in arcane Latin.
The process is indeed complex, but there are efforts to standardize on a single simple way to do packaging. Unfortunately with an archive of 30k source packages, that is a slow process.
A great resource is https://trends.debian.net/, which tracks some of the different ways of doing packaging, as well as the progress on convergence.
With the new style debhelper that we're converging on and a straightforward package, creating a new package should not have to involve a lot of typing - although it's still split across multiple files.
> AGPL is unchallenged in court. The risk to being wrong about it as huge. It’s risk aversion, not ideology, and it’s important to remember that identifying an argument as part of legal review does not call it the correct one. Anyone who’s ever worked with legal matters knows there is no such thing as “correct,” there are rulings. The existence of the argument condemns the license for FAANG, not its validity.
Having worked with lawyers, this largely overstates the risk. Companies are happy to discuss, modify and sign new contracts every day.
All these contracts are "unchallenged in court", by definition, because they are entirely custom.
A lot of software licensing contracts for closed source have complex and restrictive clauses to prevent "renting" such software through SaaS or weakening limitations using legal loopholes.
Yet companies still sign such contracts.
Another type of custom and complex contract is employment.
Furthermore, companies sue each other every other day over contract violation around IP, copyright, trademarks, patents but also employment contracts, rent, building regulations, shipment delays, all of that.
The idea that a FLOSS license is some scary monster is propaganda.
The goal of such propaganda is to drive the FLOSS community to provide valuable software for free and with zero strings attached - aka free labor.
No, companies are not happy to discuss, modify, and sign new contracts every day. They are quite hesitant to. At Matasano, it became our practice simply to tell new clients we'd be happy to sign their paper and not ours, because we'd lose weeks just to get to the point where their legal would consider looking at our contracts. At my last company, we non-negotiably used our own contracts, and budgeted a month to legal review for every signup. New contracts are a big deal.
And, what's more, the contracts we're talking about are all basically pro-forma. They're nothing like the AGPL, which has, in reasonable interpretations, far-reaching impact on IP across the whole company.
> No, companies are not happy to discuss, modify, and sign new contracts every day. They are quite hesitant to.
[citation needed]
> And, what's more, the contracts we're talking about are all basically pro-forma.
I had very custom employment contracts with 2 well-known large tech companies. When asking to remove some clauses and add new ones they did not flinch at the ask and let me have meetings with their lawyers.
I have many other examples but a quick search on the internet can show how many contract-related discussions happen between large companies, suppliers, local governments & so on
Matasano is not the size of a FAANG and similar or maybe it has a small legal team by choice.
The authors of AGPL packages are also not the size of a FAANG! That's the point! If they were, they wouldn't be negotiating AGPL with Google; they'd be negotiating an actual contract.
(I have zero problem with AGPL and happily use it myself for things, but I use it the same way I feel most of my peers use it, as an explicit "no, FAANG, you can't use this code, pay me instead" marker.)
>If they were, they wouldn't be negotiating AGPL with Google; they'd be negotiating an actual contract.
This would stop being true if (and when) FAANG figured out how to effectively use AGPL internally. In my opinion, this is inevitable as long as software continues to be published under this license. From their perspective it seems they don't even have to do anything besides wait for other smaller companies to get in legal disputes and set a precedent. Or better yet, wait for a potential acquisition to come along that happens to have won one of these disputes.
If you're trying to pivot this to a place where I'll concede that AGPL is a good thing, you're wasting energy, because I already think AGPL is a good thing. I'm not making this point about contracts because I'm motivated to talk down AGPL; I'm doing it because, in my experience over the last 15 years, it has definitely not been the case that companies are comfortable entering into arbitrary contracts. It's just not true.
Precisely. Also the negotiation takes a long time and usually the risk is not as high as agpl, since these contracts dont have clauses like 'all your ip is mine'(except one player here known to try to sneak such a clause in every time).
From doing many sales negotiations with companies, my experience has been nobody is _happy_ to modify their contracts. Full stop. They can be convinced to do so if you've got appropriate leverage, but time with lawyers is expensive, and hard to automate (currently). Employment contract changes are not the same as commercial contracts, nor the same as IP arrangements.
>I have many other examples but a quick search on the internet can show how many contract-related discussions happen between large companies, suppliers, local governments & so on
It would be surprising if these negotiations were accomplished within a small number of months. I am a small company (smaller than Matasano) and have had my contract accepted, but it is a non-trivial effort. There will certainly be items that come back, then they go to my lawyer followed by more discussion.
In the past, I did a contract negotiation with a very large (non FAANG) company and it took months, and required me to recruit internal advocates for my position.
The remedy for a violation is also in play. Private contract between two companies, cutting a 10 figure check makes it all better. Being wrong about AGPL, you have to release a lot of code that you really don't want to release, that is very important to your core business.
That's the other side, uncertainty with acceptable error bars vs uncertainty with unacceptable error bars.
And most companies do resourcing months in advance on top of that. AGPL could have solved all of this with an explicit redress clause that wasn't effectively unbounded downside risk.
The obvious solution is to completely reimplement the AGPL-ed software on your own, as a stub, in case the AGPL-ed software you want to use goes nuclear on you. Surely this will not cost a lot of developer time.
Unfortunately, many software companies obtain their revenue through the exchange of money for their software. This is like asking McDonals do stop serving food (and possibly recall all of the eaten burgers?).
A company which sells that much software can certainly afford to re-implement an AGPL component; or at least implement a good enough stub implementation to make the software run acceptably. Especially if, as Chris DiBona of Google claims, all AGPL software is useless and unneeded.
However, the point was that releasing the proprietary (oh so secret) source code is never the only option, and it is indeed false scaremongering to claim that it is.
> A company which sells that much software can certainly afford to re-implement an AGPL component; or at least implement a good enough stub implementation to make the software run acceptably.
If you ever work at a software company, you'll understand that you never have enough time to do what you want, and you have to pick and choose the most valuable tasks and go with those. Rewriting perfectly working code is never valuable.
I do, in fact, work at a tech company, and do, in fact, write a lot of code to do my job. However, it is not a software company, as it does not sell proprietary software directly.
> Rewriting perfectly working code is never valuable.
It might be far more valuable than the other option, i.e. releasing the proprietary software under a free software license. An AGPL licensing issue will only ever, in a worst case scenario, force you to choose one of those two options, no more.
Every GPL violation that I've ever heard about remedied was remedied over time often months to years. If you never create derivative works you don't intend to share you will never have an issue. If you do clearly and obviously conspire to break the law you can probably still negotiate yourself enough time to comply with the law and retain the rights to your own software after having tried to get away with breaking the law.
Having worked for a software producer who all but owns one segment of the industry, while they do discuss with their potential clients modifications to the contract, it is fair to say that the terms discussed all relate to fees. There are certain things with respect to IP that are totally not up for discussion.
Additionally, every use or purchase of software undergoes strict legal review, and there are some licenses that are flat not accepted.
This is not propaganda, and it is not in particular motivated to do anything economic to the FLOSS commmunity.
Google doesn't really care that much about the FLOSS community's contributions - they have in house projects to do everything (even a kernel or two!) just because they have so many engineers. Pretty sure the main reason they don't just ban the use of open source software internally is because it would cause their developers to riot, and the cost savings are a secondary factor.
If anything, Google probably would like to see more software released under AGPL just to screw with Amazon.
Google doesn't really use any of the "standard stack". They use open source libraries for things like SSL but when it comes to the things that matter for quickly ramping up - source control, build/test infra, release management, linters, etc - basically the only thing that isn't in-house is the languages themselves, unless you're using Go or Dart, and the text editor, unless you're using their internal web-based ide.
> All these contracts are "unchallenged in court", by definition, because they are entirely custom.
They do, however, very often use existing language, and custom language is minimized.
> Another type of custom and complex contract is employment.
Where contracts are often almost entirely standard per-company, and often standard between companies. And very rarely is the company in danger from the non-boilerplate clauses.
If you want an example of such a clause, consider Google's own IP clause in its contracts, which contend that Google owns basically all of your IP while you work at Google, unless you take steps to declare ownership of it in advance (and Google approves).
Will this clause entirely hold up in court? Probably not. Do you want to be the one to test it with your multi-billion dollar startup on the line?
The risk of using AGPL software is significantly higher than not, and the benefits are relatively small.
> They do, however, very often use existing language, and custom language is minimized.
Guess what, AGPL does that too. Its only 1 paragraph different than GPL.
> Where contracts are often almost entirely standard per-company
"standard per-company", means custom and used used throughout the company. That doesn't make it less risky, and its not like these things don't constantly change and are hugely complicated, just look at privacy policies. AGPL is standard for all companies.
> And very rarely is the company in danger from the non-boilerplate clauses.
The point people keep talking about here as risky are: what is a derivative work, and what constitutes complete and complete corresponding source definition. Both of those things HAVE been tested. complete corresponding source definition is the same in gplv3, almost exactly the same in gplv2. Derivative work is a general copyright thing tested in many cases. The extra paragraph doesn't have anything to do with them. To recap: 99% of the license is tested, and the "risk" everyone is discussing are about the parts that have already been tested. Basically, what Drew wrote is true.
Derivative work and complete corresponding source has not been tested w.r.t. Google's monorepo (or similar situations), because under the terms of the gplv2/3, Google doesn't distribute any software.
There's an entire class of tooling to make sure that GPL-tainted software isn't distributed (https://opensource.google/docs/thirdparty/licenses/#restrict...), but because the class of software that Google distributes under the GPL is limited (can you think of any?), this is workable, and such things can be isolated.
That doesn't work if the definition of "distribution" is broadened significantly. Then the derivative work questions (which aren't as cut and dry as you claim) do suddenly matter a lot more.
> There's an entire class of tooling to make sure that GPL-tainted software isn't distributed
Amazing the lengths people go to in order to avoid sharing and treating others well! Imagine if they did the opposite: imagine if they just freely shared their source code.
I mean, there's some amount of code Google really doesn't want to share (it's not shared with me and I and I work there) for various reasons including security. So I imagine there would be downsides ( and not a whole lot of up, much of the useful stuff is already shared)
> After a couple of months with lawyers, it's now a major AGPL supporter
I had a similar experience. I took exams on patent and copyright law with IP lawyers as teachers during my degree.
Then I worked in well known tech companies and had the opportunity to attend meetings with lawyers, business people, read contracts, etc. and oh boy!
Misconceptions abound terribly. The average techie overestimates his/her understanding of law and business.
"permissive" licenses are stupidly lenient. Companies never sign similar contracts between each other when exchanging goods or services. Contracts have hundreds of defensive clauses to mitigate risks or ensure fairness.
> I was hoping that he would be able to just double click the .deb file and install with no hassle, but he couldn't. I don't know if was the package manager fault or google's
And yet people praise Android for "inventing" the app store and preventing people from [inadvertently] installing stuff from random website.
DD here. The main "barrier" is the level of quality required.
Simply throwing a bunch of files into a package or a container is very quick.
Making an official Debian package is not supposed to be quick. DDs thoroughly review and test the software they are packaging.
While packaging I often chase missing licensing information, find plenty of bugs, write systemd unit/init files and sandboxing, write manpages, functional tests, and sometimes find serious vulnerabilities.
I worked on various packaging and deploying systems, and most other distributions don't come anywhere close to this level of scrutiny.
I should also add that becoming a DD requires years of commitment and proven track record of work.
The next time someone complains that making a container is very easy in comparison they should ask themselves: how much can I trust a software source with a very low entry bar?
I think the point they’re trying to make is that having a high barrier to entry should be accomplished through means other than having a hard or confusing barrier to entry.
The process itself seems to be very similar if not exactly the same.
The problem is not that, but the way to get there, and how the information is structured and presented, especially if you start from having no idea, or if you want to build your debian/ files from a blank slate and being able to read in a centralized resource about definitions of every line you add (which I think should be possible to do, for any system in general).
