Unfortunately company policy prohibits me from submitting anything(github.com)
github.com
Unfortunately company policy prohibits me from submitting anything
https://github.com/istio/istio/issues/34002
23 comments
Honestly this is really common. What’s unusual is that the responder is allowed to say he’s prevented. Normally absolutely everything is NDAd. I don’t think maintainers necessarily appreciate how often when they speak to someone about an issue but the person they’re talking to keeps avoiding doing a specific thing they were asked to do to help resolve it that they can’t, and can’t even say that they can’t.
the question is, should those people be using open source software and reporting bugs if they can't be part of the solution to resolve it?
I mean, define “should”. It’s not exactly their decision to not contribute back, and it’s often not their decision to use the software either.
Flagged this because asshats are already ruining a great bug report with awful shit (getting confused about what open source means and demanding to know the employer).
Right? I think it says a lot about the OSS community that they've latched on to that instead of doing the bare minimum completely logical thing that was asked for and then closing the issue: add a note to the documentation.
The value of the Apache and BSD-family of licenses for me is that we have source code that we can improve together and that we may learn from and that we may inspect, at the same time as we are free to use it for any purpose as long as we retain the copyright notice and license text in the distributions of source and binaries.
If someone wants to only take and not give that’s fine too. However, if they don’t want to give, they should not expect help. But they are still free to open issues about it. After all it may be something that someone else wants to do.
But as for the company that the guy works for. I would suggest that if they don’t want to contribute themselves, but they really need the problem solved, hire an external contractor to fix it and have him/her submit the patch. I suggest this because the alternative is for them to maintain a set of patches internally and that will only serve to hold them back because either it will take away time from focusing on their own product, or it will mean that no one ever updates the software they run so they are stuck with an old version that doesn’t get security fixes nor new features. So yeah.
If someone wants to only take and not give that’s fine too. However, if they don’t want to give, they should not expect help. But they are still free to open issues about it. After all it may be something that someone else wants to do.
But as for the company that the guy works for. I would suggest that if they don’t want to contribute themselves, but they really need the problem solved, hire an external contractor to fix it and have him/her submit the patch. I suggest this because the alternative is for them to maintain a set of patches internally and that will only serve to hold them back because either it will take away time from focusing on their own product, or it will mean that no one ever updates the software they run so they are stuck with an old version that doesn’t get security fixes nor new features. So yeah.
> The value of the Apache and BSD-family of licenses for me is that we have source code that we can improve together
Which "we"?!? The thing that differentiates the Apache and BSD-family licenses from the GPL that you can improve the source code for yourself, and not share your improvements. There is no "together".
It's like the old quip about keeping an open mind: "But not so open that your brains fall out". Sure, they're "even more open" than the GPL -- too "open" to preserve everyone's freedom, which is what the whole idea was about. Your definition of "value" serves fundamentally anti-freedom values.
Which "we"?!? The thing that differentiates the Apache and BSD-family licenses from the GPL that you can improve the source code for yourself, and not share your improvements. There is no "together".
It's like the old quip about keeping an open mind: "But not so open that your brains fall out". Sure, they're "even more open" than the GPL -- too "open" to preserve everyone's freedom, which is what the whole idea was about. Your definition of "value" serves fundamentally anti-freedom values.
> Which "we"?!?
Those of us that value contributing where and when it makes sense to us.
For example, I have submitted a trivial patch to one of the tools in FreeBSD. And it is now part of a base install of FreeBSD, which means that when I install FreeBSD from official media, my patch is already included “free of charge” – that is, I don’t have to apply the patch myself on top of the official sources, nor to maintain a separate build of the tool in question. I benefit, and other users benefit.
Likewise I have some software on GitHub that I have released under the terms of the ISC license. Others may submit pull-requests, and if their patch is in line with my goals for the software, or if does not burden me overly much to maintain my software with those changes merged, I will merge the patches. The people that submitted the changes benefit and I benefit.
Meanwhile, sometimes I may want to modify a piece of software and not share the change. Being free to choose whether or not to share my changes benefits me. Likewise, me not forcing others to share their changes to software that I release under the terms of the ISC license has the potential to benefit other people.
Those of us that value contributing where and when it makes sense to us.
For example, I have submitted a trivial patch to one of the tools in FreeBSD. And it is now part of a base install of FreeBSD, which means that when I install FreeBSD from official media, my patch is already included “free of charge” – that is, I don’t have to apply the patch myself on top of the official sources, nor to maintain a separate build of the tool in question. I benefit, and other users benefit.
Likewise I have some software on GitHub that I have released under the terms of the ISC license. Others may submit pull-requests, and if their patch is in line with my goals for the software, or if does not burden me overly much to maintain my software with those changes merged, I will merge the patches. The people that submitted the changes benefit and I benefit.
Meanwhile, sometimes I may want to modify a piece of software and not share the change. Being free to choose whether or not to share my changes benefits me. Likewise, me not forcing others to share their changes to software that I release under the terms of the ISC license has the potential to benefit other people.
Yeah, fair cop to all of those. But OTOH not obliging others to share their changes to something that they got for free has the potential to not benefit even more other people, so on the whole I think it's usually and on the whole a net loss of freedom. (And in practice, I think the over-permissiveness of the ancestor BSD license is what made Linux, not BSD, the dominant open OS. Had BSD been able to use the GPL [I guess that was legally impossible, right?] it might very well, IMO, have been the other way around.)
But I'm just armchair quarterbacking; I haven't contributed anything at all (yet? Hopefully!) besides kvetching like this, so hats off to you!
But I'm just armchair quarterbacking; I haven't contributed anything at all (yet? Hopefully!) besides kvetching like this, so hats off to you!
Such companies will eventually shoot their own foot. What happens is this. The company use a free software. The company want additional feature. The company implement it as an internal fork while the upstream move on. Then internal fork is hopelessly outdated, no way it can be merged to the up to date branch. The company must use a decade old software and it can't compete with the competitors.
In the long term, these companies fails.
In the long term, these companies fails.
I don't think that's the case here. Rather that OSS is not ONE license but many and it's a non trivial task to comply with all licenses.
Big companies spend a lot of resources and money to be license compliant. One way to make sure that the company follow OSS licenses is to have a process for how to contribute. The person posted the issue has not been through that processes for this specific project and hence can not contribute.
Big companies spend a lot of resources and money to be license compliant. One way to make sure that the company follow OSS licenses is to have a process for how to contribute. The person posted the issue has not been through that processes for this specific project and hence can not contribute.
I don’t see that as making much if any sense.
Either the reporter is reporting the issue because of something they’re doing in their own time, in which case there really is no reason for the company to be involved at all (despite widespread american insanity on the subject), or it’s something they’re doing in a company context in which case they “can’t contribute” to something the company is already using which frankly makes no sense either, if the license was an issue the company could not use the software in the first place.
So the only context seems to be the usual (related to §1) “the company owns your entire life 24/7 for the entirety of your employment duration and beyond without compensating you for any of it” nonsense.
Either the reporter is reporting the issue because of something they’re doing in their own time, in which case there really is no reason for the company to be involved at all (despite widespread american insanity on the subject), or it’s something they’re doing in a company context in which case they “can’t contribute” to something the company is already using which frankly makes no sense either, if the license was an issue the company could not use the software in the first place.
So the only context seems to be the usual (related to §1) “the company owns your entire life 24/7 for the entirety of your employment duration and beyond without compensating you for any of it” nonsense.
Licence compliance is irrelevant to submitting your own contributions. Typically when you submit contributions to open source software you retain ownership of the copyright, but grant a licence to the project owners to use it (and therefore to others because OSS licences includes a term about relicencing by definition). This doesn't stop you from granting others a different licence, or using it yourself however you like.
As an example, if I write and publish a complete program or library under GPL (or any other licence), then that doesn't stop me from selling the same thing under a proprietary licence. Qt is a classic example of this. Similarly, if I make a small contribution to a library under GPL, or any other licence, then that doesn't stop me from re-licensing my small chunk of code however I like, or reusing it internally under non-GPL terms - because it's mine!
The exception to this is those few projects that require you to actually assign copyright. Most notably this includes the FSF (except GCC as of a couple of months ago), their reasoning being that this makes it easier for them to litigate against violaters of the GPL, because only the copyright owners can sue.
As an example, if I write and publish a complete program or library under GPL (or any other licence), then that doesn't stop me from selling the same thing under a proprietary licence. Qt is a classic example of this. Similarly, if I make a small contribution to a library under GPL, or any other licence, then that doesn't stop me from re-licensing my small chunk of code however I like, or reusing it internally under non-GPL terms - because it's mine!
The exception to this is those few projects that require you to actually assign copyright. Most notably this includes the FSF (except GCC as of a couple of months ago), their reasoning being that this makes it easier for them to litigate against violaters of the GPL, because only the copyright owners can sue.
I don't see how this is a problem, to be honest. If the company is using the software, its licensed must already be reviewed. Unless they're submitting code that links to company-made one, contributing does not come with additional license obligations.
The issue reporter seems to be suffering from full-blown stockholm syndrome about it too.
> In the long term, these companies fails.
In my experience this feedback loop is too slow to force management to make a policy change.
At some point I the future they will be chest deep in maintenance cost. At that point they are just going to redo their whole existing stack because it’s cheaper and easier than fixing the current stack.
In my experience this feedback loop is too slow to force management to make a policy change.
At some point I the future they will be chest deep in maintenance cost. At that point they are just going to redo their whole existing stack because it’s cheaper and easier than fixing the current stack.
Building off free and open-source software is much safer from a long-term maintenance and support position than building off paid/licensed/commercial software.
This is an interesting topic. I have seen exact same thing happening in my org too. One of the reasons that always comes up is legal. Other reasons I have heard is that contributing to opensource is not core to the business.
I believe to sustain any foundation backed or non profit opensource project, you need a healthy community. A community is formed when the builders are appreciated for their efforts. Appreciation could be healthy donations or other people believing and joining their mission by contributing code.
I believe to sustain any foundation backed or non profit opensource project, you need a healthy community. A community is formed when the builders are appreciated for their efforts. Appreciation could be healthy donations or other people believing and joining their mission by contributing code.
My early memories of Google (right around the IPO) involve very strict rules about who can and cannot contribute to FOSS projects and what data must be scrubbed before submitting bugs externally. I did all my contributions under pseudonyms, so it couldn't be linked back to me or to Google. Paranoid companies are not uncommon.
> One of the reasons that always comes up is legal.
And usually nobody has run that by legal, it’s just a way for managers to go “nope”.
And usually nobody has run that by legal, it’s just a way for managers to go “nope”.
Where real world practicalities, constraints, and risk management meets “the movement” that is OSS. When I’ve been in a similar position, I’ve suggested:
Bug hunting and filing reports (but not code fixes).
Corporate donation to the project specifically or one of the foundations funding OSS.
Contributing documentation, howtos, tutorials.
Lastly, if all that fails or in some particular circumstances, I make a modest personal donation.
I wonder if the commenter asked his company about the specific case.
The contractual blanket bans usually say “cannot [do anything] without prior written permission” or something. It’s a big difference between “hey do you mind if I write some software that our competitors can use too, and maybe include some of our own secret sauce”, and “software we use has a bug, can I fix it for myself at source”.
The contractual blanket bans usually say “cannot [do anything] without prior written permission” or something. It’s a big difference between “hey do you mind if I write some software that our competitors can use too, and maybe include some of our own secret sauce”, and “software we use has a bug, can I fix it for myself at source”.
In my experience what's actually going on is a mix between "no, we don't do that here" and you're technically allowed but unless it breaks production you're not even given time to put a day or two into submitting a bugfix. Much more likely to merge the fix locally or something stupid. No idea about this poster, of course. Phrasing it as "my employer doesn't let me" would be less specific, but maybe also not wrong in this case.