81–90 of 111 posts
Earlier quoted context omitted.
If you work in a startup, it will bite you during due diligence when a potential acquirer is evaluating your intellectual property. I would give the AGPL a wide berth.
This is why I avoid AGPL projects for potential ideas / side projects that could potentially turn useful.
The latter makes sense. The former does not, as you can relicense any time you want.
My questions are: - if I allow users to use an AGPL product on my server and that AGPL licensed product connect to a commercially licensed application server or database on my intranet, will that be a problem? - will it be a problem if the commercial application server connects to the AGPL licensed product to fetch data? Except for these two points I now feel I'm starting to understand the AGPL, kind of.
Generally, no. The AGPL work is a distinct work and not a derivative of the commercial work. You can redistribute code copies of this AGPL work even if such copies are useless to others because they don't have access to your other application which it communicates with. Nobody can prevent you from licensing your own works however you wish.
This question is more about the proprietary work rather than the AGPL work. Does the proprietary license allow you to make it available to others over the network? If the proprietary work is your own, there are no problems, at least on your part.
The problems may arise for users of your AGPL work though. They face uncertainty as to whether the proprietary work being accessed is covered by patents, or whether its API is covered by copyright - and thus, are unlikely to use your AGPL work without completely replacing the parts which communicate with your own service.
> Will it be a problem if the commercial application server connects to the AGPL licensed product to fetch data?
If the commercial application is internal to you or your business, there is no issue connecting to AGPL works.
If the commercial application is made available over the network, then the question comes down to whether it can be considered a derivative work of the AGPL work or not.
I have some questions about AGPL if anyone has answers: 1. If you have code, let's say FooProject, that's AGPL. In which of these scenarios is someone in the wrong for using it? 1a. Google uses FooProject in delivering one GoogleApi, but does not opensource GoogleApi with AGPL. 1b. Facebook uses FooProject in an internal project, FacebookInternal, that's not exposed to the internet, but does not open source FacebookI…
1) What would a judge/jury perceive as the full copyrighted work, in contrast to individual parts.
2) In all copyright cases there is a author who can enforce copyright. People who want permission to do something which copyright would make illegal need to prove that they are in compliance to the conditions, and its on them to raise the fact that they have a legit license.
So to give some quick answers, if judges would see googleapi as the "complete work" then the author of the AGPL could sue Google for not having a license to use FooProject in GoogleAPI.
AGPL do have some exceptions which allow internal use, so facebook could raise the AGPL in court and say that the license do give them permission to use FooProject in facebookInternal. It would also depend on the question if the judge/jury perceive FacebookInternal as an individual work or as a part of facebook itself.
The AGPL is an additional condition over GPL that restrict work that has an interface that get accessed over a network. The condition would unliekly apply for microsoft BlueRay, through the GPL part would.
If Fooproject is a part of AlienNetflixViewer then AlienNetflixViewer need to be under AGPL.
When the FooProject is distributed the AGPL license also apply to the MIT licensed parts. If people use the MIT licensed parts exclusively then they only need to follow the MIT license.
If a person does not follow the conditions under the AGPL then they do not have the permission for which the license grants. A person who do not have a permission to distributed a copyrighted work and still do it commits the crime of copyright infringement and depending on where, why and what get fined or risk imprisonment. If it is so incorporated into its project its effectively impossible to remove then you either get permission from the author or stop distributing the copyrighted work.
Enforcement of copyright depend on local law. It could be as simple as going to the police and file a police report, but usually it involves getting lawyers involved.
If a user suspect that someone is infringing copyright then they could inform the author. Knowingly accessing copyrighted material from an illegal source could also be illegal, depending on local law.
Earlier quoted context omitted.
Why would charities and academic institutions be writing anything but free software?
I never understand this. I get not wanting to build a community around a project, handling contributions, etc. But why not just dump the source code somewhere?
Earlier quoted context omitted.
A potential pitfall is that only AGPLv3 and GPLv3 are directly compatible (in the sense of producing programs created from both AGPLv3 and GPLv3 code without violating either license). That's not possible with GPLv2 or AGPLv1 in any combination, and there's still some code-bases that will be GPLv2 forever. But if that's not a concern then I would agree that AGPL is exactly how the GPL should look like in the age of S…
That's not entirely true. GPLv3 and AGPLv3 have explicit clauses that allow the linking of GPLv3 and AGPLv3 code into a single work without violating either license: https://en.wikipedia.org/wiki/Affero_General_Public_License#... You're right about GPLv2 though.
Earlier quoted context omitted.
If you work in a startup, it will bite you during due diligence when a potential acquirer is evaluating your intellectual property. I would give the AGPL a wide berth.
You can always change the license.
Earlier quoted context omitted.
> In either case, being open source increases security risk. This is blatantly false. Any claim that closed source is provides any form of security is entirely a claim in security by obscurity. If open sourcing your code presents any risk to sensitive personal information, then that means that you are already grossly mishandling this information. Whether or not your open source your code at this point doesn't matter—…
> If open sourcing your code presents any risk to sensitive personal information, then that means that you are already grossly mishandling this information This is also clearly false. For example, take this scenario: - You use web framework Omega, but minimise indicators of this (suppress HTTP headers, etc). - At 2am, a critical security vulnerability is discovered for Omega and a patch is released shortly after. - M…
Attackers either flood you with every attack under the sun, or tear your site apart and will know exactly how it works.
Imagining that you can hide the function of your site is again security by obscurity.
The key idea here (I forgot the name of the law, but others' mentioned it in the tread) is that regardless of what you do, the adversary will end with complete understanding of how your system works.
Therefore, any security based entirely on the adversary not learning about implementation details is entirely defective.
Furthermore, an attack exists for days, months or even years before fixed, it takes time to fix and release, and it takes time for you to discover the advisory and deploy.
You were not vulnerable for 7 hours. You were vulnerable for weeks, months or years.
Earlier quoted context omitted.
You can always change the license.
except you cannot, once its AGPL youre stuck with it
https://www.zerotier.com/on-the-gpl-to-bsl-transition/
Lots of open source people don't like it as it is not technically an OSI open source license. I'm not in love with it either, but it was the best solution available for now. We are exploring other alternatives.
The problem with the AGPL is unfortunately that it has the letters G, P, and L in it.
You'd be shocked to learn just how many potential customers have no-GPL policies or are otherwise just allergic to the GPL. There is a lot of FUD and misconceptions out there. Lots of companies won't allow anything GPL to be used internally in connection with any code or product. (Linux seems to get grandfathered in, but they don't like GPL for anything new.)
Most of this is fallout from Microsoft's 1990s - early 2000s anti-GPL FUD campaign, and the memes from that are still circulating. Lots of people think GPL code is "viral" in the sense that if it touches your code in any way whatsoever it somehow magically GPLs it. MS spent millions to muddy the waters around the GPL.
Yes it's FUD and it's typically rooted in misconceptions, but it's very common and from a sales point of view it's a waste of time to try to fight it. It's hard enough to educate customers about your product without also having to educate them about the license.
If it weren't for this issue we'd consider AGPL, but it's really not perfect.
What we really need is a modern license that addresses the "SaaSification" phenomenon, which AGPL does partly but not fully, while at the same time being simple to understand and compatible with as much of the rest of the OSS ecosystem as possible. AGPL is more complicated than I would prefer while also not being quite the right thing.
I'm starting to think we'll have to make one. If we do we will open source it for others to use.
I've always wondered about whether the AGPL is a good fit for software that isn't accessed over the network. At first glance this would appear to offer the exact same rights as the GPL in this scenario, however you then have the protection of the AGPL if the software was ever incorporated into a networked program. Does anyone have any experience with this? Are there pitfalls to using the AGPL for a regular program th…
To me, the biggest problem with the AGPL is that nobody really knows what the implications are. A lot of people say a lot of things, but that's all we have. I find it to be a greater burden to figure out what the license actually means than to just pick another software system that uses a permissive license. Large companies like Google seem to agree with me.