Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Posted Oct 15, 2015 4:53 UTC (Thu) by wolftune (guest, #100179)In reply to: Permissive licenses, community, and copyleft by Cyberax
Parent article: Permissive licenses, community, and copyleft
The only *danger* you are facing, the *only* issue for your safety is releasing your source code — something many people argue should be done for *published* software anyway, and you yourself were even suggesting was inevitable… so, are you saying that it's horribly unsafe to risk the possibility of having to do something that was inevitable anyway??
Posted Oct 15, 2015 5:00 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
It's entirely possible for AGPL to cascade down to pretty much everything. That's why it's so toxic that pretty much no enterprise company deploys it.
Posted Oct 15, 2015 14:49 UTC (Thu)
by k3ninho (subscriber, #50375)
[Link] (6 responses)
>>> The only *danger* you are facing, the *only* issue for your safety is releasing your source code
Hard-coding implementation detail is technically ugly. I'll go so far as to say that your skilled minions are doing it wrong (what's your company called so I can blacklist? :-P lol).
AGPL says that you have to give people the ability to run their own version of the service you're running. Either that's available from your source upstream or you have contributed value to the system and you owe it to upstream to make that available. Your passwords, internal system layout and firewall rules aren't part of anyone else's service within an AGPL ecosystem -- and obviously you would pay your legal team to argue that fact against the charge you were failing to meet your obligations under the the AGPL -- so this line about it being 'toxic' is steaming shenanigans.
Either you're part of the community and ecosystem around GPL and/or AGPL projects or you're not. There are differing requirements for your org with each, but your reasons for reimplementing work other people have done rather than integrating existing solved-problem tools aren't technical or legal, they're cultural and habitual and you can elect to change that.
K3n.
Posted Oct 15, 2015 18:20 UTC (Thu)
by bronson (subscriber, #4806)
[Link]
Back in the late oughts a company I worked for wanted to use some AGPL'd software internally (gitorious?), and of course they wanted it to use the corporate single sign-on (F5 maybe?). No problem, a few days effort max. Then came weeks of email with expensive lawyers, and the eventual conclusion that it's probably impossible without AGPLing the entire SSO product. We thought of a number of workarounds (as I'm sure you can) but the language in the license is pretty flimsy... It seems like armchair lawyers have no problem staking their reputations on the AGPL, but reputable ones, who are fine with GPLv2, are just not happy to go there.
So, yes, I came out of that experience feeling like the AGPL is pretty darned toxic. I'd be curious to hear if anyone else has successfully navigated these waters.
Posted Oct 15, 2015 19:59 UTC (Thu)
by ballombe (subscriber, #9523)
[Link] (1 responses)
That what people say it says, but not what it says!
Read the actual license text. What you say is not something a copyright license can enforce because running the software is not a reserved right of the copyright holder.
The AGPL is very vague on crucial points, in particular the meaning of 'modifying the software' and
'all users'.
It it the only purportedly free software license that create liability for merely modifying the software,
even if you do not run it.
"modify" is defined in the beginning as
which is still quite ambiguous.
Your best defense to the AGPL is to refuse to accept the license which is explicitly allowed,
pay a third party that will never run it on a public network to do any modification to it,
and then run it behind a transparent proxy that remove any offer of source from the HTML pages
that are served, to cover the third party.
Trust me I am as concerned as anybody about the software as service hijack of the GPL, but the AGPL is
not the solution, it just distracts us from searching for a working solution.
If you are concerned, only write GPL client-side javascript. This way anybody interacting with your code has already received a copy!
Posted Oct 15, 2015 21:41 UTC (Thu)
by bronson (subscriber, #4806)
[Link]
Haha, maybe... Even then, no way you're going to get any reputable lawyer to sign off on that!
Posted Oct 15, 2015 20:09 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Oct 15, 2015 20:58 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Yet it's the reality we have to deal with right now.
Posted Oct 16, 2015 0:37 UTC (Fri)
by cortana (subscriber, #24596)
[Link]
As if this stops people doing boneheaded things. In the last place I worked, I gave up trying to persuade people that embedding the credentials required to access our internal Maven repository into our source code repositories was a bad idea, because I also had real work to do! :(
Posted Oct 16, 2015 7:56 UTC (Fri)
by arnout (subscriber, #94240)
[Link] (1 responses)
I never really understood the issue with this. So you have to release the source code of your internal build and deployment system to your employers. Wouldn't it be a good idea to give them access to it anyway?
What I also don't understand is how lawyers are so paranoid about copyleft licenses, but there never seems to be a problem with binary firmware blobs that don't even have an accompanying license text.
Posted Oct 16, 2015 17:58 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
And the company will have no legal recourse, other than simply firing employees who give this source to anyone outside the company.
> What I also don't understand is how lawyers are so paranoid about copyleft licenses, but there never seems to be a problem with binary firmware blobs that don't even have an accompanying license text.
Posted Oct 15, 2015 15:10 UTC (Thu)
by krake (guest, #55996)
[Link]
He says that internal code is either published or worthless, so having to always publish would be unsafe because then all that worthless code would be out there as well.
Permissive licenses, community, and copyleft
Software for _internal_ systems. That depend on internal build and deployment systems, that in turn depend on other systems. Which often simply can _not_ be opened because of hard-coded sensitive data or metadata.
Permissive licenses, community, and copyleft
>Software for _internal_ systems. That depend on internal build and deployment systems, that in turn depend on other systems. Which often simply can _not_ be opened because of hard-coded sensitive data or metadata.
Permissive licenses, community, and copyleft
AGPL says that you have to give people the ability to run their own version of the service you're running.
Permissive licenses, community, and copyleft
13. Remote Network Interaction; Use with the GNU General Public License.
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.
To "modify" a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a "modified version" of the earlier work or a work "based on" the earlier work.
9. Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or run a copy of the Program.
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Yes, it is ugly. Yes, we know it and we are working on fixing it eventually.
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
> Software for _internal_ systems. That depend on internal build and deployment systems, that in turn depend on other systems. Which often simply can _not_ be opened because of hard-coded sensitive data or metadata.
>
> It's entirely possible for AGPL to cascade down to pretty much everything. That's why it's so toxic that pretty much no enterprise company deploys it.
Permissive licenses, community, and copyleft
No, to _everyone_. Every employee will automatically receive an AGPL license to internal source code and will be able to distribute it at will.
Lawyers rarely have problems with GPLv2. Unlicensed blobs are actually far less scary - often there's an implied license in place and in the worst case the company will have to cease using these blobs.
Permissive licenses, community, and copyleft