irl commented 7 years ago

IANAL.

Debian Free Software Guidelines

Free Redistribution
Source Code
Derived Works
Integrity of The Author's Source Code
No Discrimination Against Persons or Groups
No Discrimination Against Fields of Endeavor
Distribution of License
License Must Not Be Specific to Debian
License Must Not Contaminate Other Software

As far as I can tell, depending on the companion license used, these should all be satisfied.

Thought Experiments

The Desert Island test

Imagine a castaway on a desert island with a solar-powered computer. This would make it impossible to fulfill any requirement to make changes publicly available or to send patches to some particular place. This holds even if such requirements are only upon request, as the castaway might be able to receive messages but be unable to send them. To be free, software must be modifiable by this unfortunate castaway, who must also be able to legally share modifications with friends on the island.

This looks satsified. There is no requirement to submit contributions back to DoD and the restrictions on DoD accepting contributions in the Your Contributions section would not apply when sharing modifications with your friends on the island.

It may be that DoD intended to say "modify" as opposed to "contribute to" which would fail this test, as you may not have had a copy of git with you on the island, and this essentially would require the use of git commit messages in order to distribute patches.

The Dissident test

Consider a dissident in a totalitarian state who wishes to share a modified bit of software with fellow dissidents, but does not wish to reveal the identity of the modifier, or directly reveal the modifications themselves, or even possession of the program, to the government. Any requirement for sending source modifications to anyone other than the recipient of the modified binary---in fact any forced distribution at all, beyond giving source to those who receive a copy of the binary---would put the dissident in danger. For Debian to consider software free it must not require any such "excess" distribution.

There does not appear to be any requirement for excess distribution, nor restrictions on distribution of the source or compiled binaries.

The Tentacles of Evil test

Imagine that the author is hired by a large evil corporation and, now in their thrall, attempts to do the worst to the users of the program: to make their lives miserable, to make them stop using the program, to expose them to legal liability, to make the program non-free, to discover their secrets, etc. The same can happen to a corporation bought out by a larger corporation bent on destroying free software in order to maintain its monopoly and extend its evil empire. The license cannot allow even the author to take away the required freedoms!

There does not appear to be a mechanism by which the granted rights can be revoked. The entire agreement is ignorable anyway in the case that we're looking at a country that sees US DoD work as public domain. To be entirely honest, I feel this is a waste of time.

Edit: The agreement, on further reading, appears to attempt to solve a problem where some contributions may have copyright where contributed by those that are not US government employees. I still do not believe this is necessary however as individual commits could be marked as public domain with a BSD, MIT, GPL, etc. license applying to the whole project. If it was necessary that part of the project would be used where it could only be used if public domain then you could work out which bits that was, but a license that is well-known and can be followed whether or not copyright applies makes everyone's life easier. This would not prevent DoD using contributions either, as long as they also agree to follow the license. You establish a baseline set of rights for everybody in this way that is clear and transparent.

Following these tests, the license as it currently stands will pass, however...

I understand your lawyers may be suffering from not invented here syndrome, but when your code needs to interact with other code, there is a threshold you need to be under for the amount of work that is required for open source developers to check if your license is compatible with the other licenses compared to how much work it would be to just replace your project with something with a well known license.

The DoD is not a special snowflake. The license document should state something along the lines of "there is no copyright on this work, where copyright does apply because you're in a country where you can't have no copyright, use BSD-2-clause".

If you must continue with this addition to the already too complex pool of open source licenses, please consult the Debian Free Software Guidelines FAQ as this will give you an idea of whether or not people will be able to actually use your code integrated as part of a larger system that you are showing resistance to really integrating into, using GitHub only as a token gesture afaict.

Edit: Despite the fact that you would be using BSD, MIT, GPL, etc. along with this agreement, you are still creating new variants of licenses by including the agreement along with the license, BSD+DoD, MIT+DoD, etc. and so these are new licenses.

xacaxulu commented 7 years ago

+1

andrewgdunn commented 7 years ago

It's a precarious pathway to create +DoD and expect anyone to be comfortable with adoption. I keep thinking of the GPL/CDDL challenge between ZFS and the Linux Kernel, how much effort has been spent due to the selection of CDDL.

seanenck commented 7 years ago

+1 and it definitely creates a problem when you start to look at <License 1> + <License 2>. I feel like the MS-PL license (regardless of how anyone feels about it) immediately sees this problem in the wild because you have to start thinking about compatible licensing before you can even do the (hopefully) cool thing you want to with the components :/

tomberek commented 7 years ago

@irl Excellent analysis. I like the framework and thought experiments as the way to distill the essence of the proposal. Would you mind a similar analysis of the proposal in (#33,#34). It is simpler and seems to address your concern about the "BSD+DoD"-style proliferation.

marctjones commented 7 years ago

Evaluating this "agreement" against the DFSG or the FSF's four freedoms or OSI Open source definition might be premature. The first question to ask might be can or should a contract be evaluated by those standards. All of the OSI approved licenses are licenses, not contracts..

As I understand it, the proposal here is not to create a license but to create a contract. They are legally distinct concepts and have significant differences in how they come into being and how they impose obligations, create rights, create liabilities, and create remedies. Should a contract be evaluated at all? Is it relevant? Is it a good idea? Would consideration of them mean that there are other concerns that Debian or FSF or OSI would want to add to the list? Do the illustrative stories capture the full complexity of the stated requirements as applied to licenses? If so do they also capture the complexity associated with evaluating a contract?

I would suggest that the enforceability of a license is assumed in those standards (which may or not be a good assumption); but the enforceability of a contract raises questions distinct from the enforceability of a license.

I should point out that, of course, relying on Wikipedia for a complete and accurate definition of the law of contracts and license is not a good idea. And as always if you are in need of legal advice seek professional assistance from an attorney. I am of course not your lawyer.

irl commented 7 years ago

@marctjones These were thought experiments, to encourage thinking.

the proposal here is not to create a license but to create a contract

The combination of a license+license grant is equivalent to a implicit contract in my mind. While perhaps not technically true, served a basis for the analysis.

do they also capture the complexity associated with evaluating a contract?

Probably not. There will always be lawyers attempting to produce objectional things and sometimes these things will be a surprise. This is why I've pointed out that it would be better to go with solutions that already exist and that have been analysed in many situations and in many jurisdictions.

marctjones commented 7 years ago

@irl to your point; your experiment did get me thinking. I went and reread the DFSG and noticed guideline 7.

The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.

The proposal is an attempt to subject the software to the terms of an existing FOSS license. But this proposed agreement intends to operate in a way that requires you to execute the contract the first time you copy or use the software.

When You copy, contribute to, or use this Work, You are agreeing to the terms and conditions in this Agreement and the License.

I would note that you don't actually need a copyright license to /use/ FOSS software. Or any software for that matter since /use/ is not an exclusive right of copyright. (In contrast /Use/ is an exclusive right of a patent which some FOSS licenses also address). Most FOSS licenses restrict your distribution of the software by placing conditions on distribution. A few also restrict modification, but also generally only when you distribute your modifications. Perhaps some place restrictions on making copies for private use (if you know of one please point it out, I would be curious.)

But in this case if I give you a copy of software covered by this agreement where I made the copy and I distributed it by leaving in on your doorstep, the contract purports that you still need to execute a contract before you can use it. I might be wrong but seems like that would violate guideline 7.

tomberek commented 7 years ago

There's been an update based on some feedback to an alternate approach. Please see CONTRIBUTING.md

irl commented 7 years ago

@tomberek I think this addresses my concerns regarding variant license proliferation. Further discussion should probably happen in other issues, as this is no longer a license problem but a problem of accepting contributions.

Code-dot-mil / code.mil