tomberek
commented
7 years ago We have been discussing exactly this approach. Can you comment on what you think the reception would be for it? Potential pitfalls?
Closed eshellman closed 7 years ago
tomberek
commented
7 years ago We have been discussing exactly this approach. Can you comment on what you think the reception would be for it? Potential pitfalls?
jsha
commented
7 years ago Speaking as a contributor to open source projects, and as a maintainer, what @eshellman describes is closer to what I would expect from a project. I think the reception would be fine, and most contributors would not consider it at all unusual.
shawoods
commented
7 years ago @eshellman @jsha This is really helpful feedback! Like @tomberek said we are considering this exact approach. We would definitely be interested in hearing from others about how they would receive such an approach.
SeanCarrick
commented
7 years ago Most of what is being discussed is irrelevant under OpenSource licenses such as the GPL v.2.0 or greater.
The reason I say this is that the GPL only protects copyrights where copyrights exist. If no copyright exists, then the code or text is, by default, in the Public Domain. The most important aspect of OpenSource licenses, IMO, is that they protect the author from liability via the cancellation of explicit or implied warranties (i.e., fitness for a particular use, merchantibility, etc.).
"Copyleft" was a term coined by GNU due to the distinction between proprietary and OpenSource licenses. Keeping "copyleft" in mind, copyrights are protected, but only when they actually exist.
Another issue that should be considered is the fact that government employees cannot copyright work while they are on the clock, but can copyright their work if they are contributing on their own time, with their own systems and resources.
I believe that the best way to handle the licensing for DoD OpenSource software is to establish coding and commenting standards such that:
// author: jdough.gvt
but, if contributing on their own time and using their own resources, they would comment as any non-government employee:
// author: jdough jdough@domain.comThese are just my opinions, but I believe that they would alleviate some of the misunderstandings and complexities involved in the licensing of OSS that is "sponsored" by the U.S. government.
irl
commented
7 years ago Following on from my analysis from #39 and applying to this, there are really two important things that I think need to be addressed:
As a disclaimer, I am a Debian developer, but I think that the DFSG sets a good basis for what people expect from free software.
I believe that as software is used internationally, the best license grant is going to be simple, unambiguous and well-known. I think the current "contract" should actually turn into a contributors guidelines, the license grant text should be the typical text for an well-known license.
can just see the License badge and carry on as if its the same thing they usually do
I touched on this in #39, once you have a baseline that covers pretty much every use case that a developer will need, I don't think people are going to care if it's public domain or not as they can be happy in the knowledge that even if copyright applies, they've been granted the rights required.
As covered in #39, license+DoD is going to be badly received. Not only does the interaction between this and the plain version of the license need analysis, but then also between that license and other licenses and then that analysis needs to be done in every jurisdiction that it is used in.
Some have talked about CC0, but I would double check with your lawyers about the mention of patents in CC0. The simplest licenses are the easiest understood and MIT/BSD licenses are my preferred option. They grant rights beyond the requirements of the DFSG and don't impose restrictions on redistribution as the GPL does (cannot distribute binaries without source), which I believe is in keeping with the spirit of the original work in the public domain.
eshellman
commented
7 years ago @tomberek I think the reaction to the approach, positive or negative, would focus on the contributor license chosen, no different from any OS project.
On further reflection, I thought about how horrible it would look if some agency of the government tried to enforce a TOS wrapper scheme. You perhaps know about Aaron Swartz about RECAP. https://www.eff.org/deeplinks/2013/09/federal-courts-still-scaremongering-about-recap-and-spooky-open-source-software
o0101
commented
7 years ago I think that even tho the approach suggested works for contributors from this point forward under an open source license but I don't know how it works to minimize fallout from any interaction between previous ( government, non-copyright protected, and so on ) contributions and code ( and their authors ) and open source contributions from this point?
My concern is there is some legal bug in not considering the interaction that will cause some legal issue later.
Not limited to this example, but:
It may sound far fetched but consider some IP that goes into GPS, or some other high-value technology, if there is any gap in this scheme that opens up legal vulnerabilities, then people who can exercise those rights for their benefit likely will.
I don't know if it this agreement is meant to provide protection against these things, and if it is not, then this point is irrelevant. But if it is meant to offer protections, I think it works to make it as bug free and clearly understood as much as possible, so that future projects progress unhampered by legal holdups.
I'm not addressing contributor reception in this, I'm just not sure that putting an open source license on a whole lot of legacy contributions and saying there is a point in time where, before that time, one license applies, and after that time, another scheme applies, and not considering interactions between those two zones, is going to be bulletproof.
BrandonBouier
commented
7 years ago We've pivoted based on user feedback. Take a look at the current CONTRIBUTING.md
EricRohlfs
commented
7 years ago Responding to the comment above about on or off the clock work.
It may not be necessary to have developers tag commits to determine if they are on or off the clock. Government employees and contractors keep detailed timesheets as per federal law. If it ever came down to a copyright claim, comparing timesheets to timestamps would be a form of evidence. In addition, I think self reporting or tagging via commits would be difficult to enforce.
// author: jdough.gvt // author: jdough jdough@domain.com
eshellman
commented
7 years ago Great! closing the issue to avoid confusion on continuing issues, such as the suggestion by @EricRohlfs that deserves its own issue
This is an interesting approach to the problem- I understand why you're trying to do this.
However, I'm the type of developer who is also a copyright geek. I'm afraid that most developers have a shallow understanding of copyright and the public domain, and most of them will look at this a see the evil government trying to lock up what should be public. The result may be poor license adherence. The licensing scheme may be too clever to do what it is trying to do.
A more effective approach in my opinion, would be to simply say that the original contribution by authors A, B, and C, as of tag X is in the public domain, and that to retain the open character of the software, it is the expectation of the authors that any contributions not covered by US Government employment are to licensed by the contributor under (included) XXXX standard license. Also that any use of this repo normally covered by copyright must either include the notice and license or remove contributions past tag X.
This way, new contributors don't have to understand the public domain. The can just see the License badge and carry on as if its the same thing they usually do.