Re: [License-discuss] I've been asked to license my open source project CC0

[Christopher Sean Morrison]

On Nov 07, 2017, at 02:27 PM, Shahar Or  wrote:


Nigel, in case there's a misunderstanding—I'm not contributing to a CC0 
licensed project. A maintainer of a CC0 licensed project has requested me to 
re-license my ISC licensed project to CC0.


What do you mean by "Modifying the stock CC0"? Did they?


I presume he was referring to my reply which suggested that if you use CC0, to address 
patents in some manner.  CC0 is in prevalent use so you're probably fine either way, but 
just be aware that there is uncertainty (or at least disagreement) as to whether CC0's 
fallback license is consistent with the Open Source Definition (OSD) as defined by OSI.  
The reason is that it essentially says "no patent grant for you!" which none of 
the permissives (e.g., ISC) say.


To the contrary, licenses like ISC arguably imply a patent license, but this is fully 
untested.  For an artwork asset, it doesn't really matter.  For code and contributors, it 
"could" matter if someone has a patent.


My overarching suggestion remains to address CC0's patent clause in *some* 
manner whether by a contributor agreement, dual-licensing, or amendment and 
probably in that order of decreasing favor.



And what do you mean by "they won’t use your code anyway"? They intend to use 
it as a dependency, via package management (Node.js/NPM) and specifically include it in 
their web frontend via bundling (Webpack, probably).


To me, their request makes absolutely no sense unless they distribute that 
frontend code independently of npm.  They're basically asking to not have to 
acknowledge your contribution as having come from you.  They're certainly able 
to do that and not an uncommon desire, but it seems very lame to me to ask that 
of an ISC code.




It appears to me that the maintainers want all the code and art assets under 
one license and they are using CC0.  That’s not too uncommon in general and in 
this case, it makes even more sense given that shields appears to 
programmatically makes badges in svg.



Except they are extending their desire to non-bundled *dependencies*, which is 
just bizarre.  It's like wanting GPL virality sans copyright ... copyfarleft?

 
The patent provision is meaningless if you don’t own any patents used by your 
code.


It's not necessarily meaningless to contributors and forks and future you.



Cheers!

Sean


___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] I've been asked to license my open source project CC0

[Christopher Sean Morrison]

> On Nov 7, 2017, at 12:09 PM, Shahar Or  wrote:
> 
> I have been asked to change the license of an open source project of mine to 
> CC0. I'm reluctant to do so, as it is not OSI approved.

That’s a reasonable concern, imho.

> https://github.com/mightyiam/shields-badge-data/issues/28
> 
> Is there good reason for this request, at all?

There’s no technical reason.  Not permitting incorporation of permissively 
licensed code (eg MIT) predominantly means throwing away attribution.

> I mean, can they not otherwise depend on my software, if their software is 
> CC0 licensed?

If your code used a license that applied to combined works (eg GPL), there’d be 
an issue.

> When I conveyed my reluctance it was suggested that I dual-license.

With CC0, I would suggest striking the patent provision or incorporating a 
patent grant from contributors in some manner.  Dual licensing with a 
permissive is an option too.

Cheers!
Sean

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] resolving ambiguities in OSD (was [License-review])

[Christopher Sean Morrison]

> Date: Tue, 24 Oct 2017 18:13:23 -0700
> From: Bruce Perens 
> To: License submissions for OSI review 
> Subject: Re: [License-review] resolving ambiguities in OSD [was Re:
>   For Approval: License Zero Reciprocal Public License]
> 
> Most of this is implicit within the OSD but they are useful to keep in mind:
> 
> With regard to *simple users,* those who make use of the Open Source
> software and do not modify or redistribute it, there should be as close to *no
> legal load* as possible. We need to be cognizant that many of these users
> are individuals and very small businesses that can't reasonably assume any
> legal load at all. We can't protect them from patent issues brought by
> others than the licensor of the software, but to the extent that we can
> protect them, we should. In particular, *simple users should not ever have
> to read the license.*
> 
> We should also endeavor to keep the legal load upon *Open Source developers* 
> as
> low as possible. These are also individuals, small businesses, etc. We
> expect them to understand the license somewhat, but they are not legal
> experts and do not necessarily have easy access to legal experts or even
> the inclination to use them.

Bruce,

This is fascinating and refreshing.  It’s great to be reminded of some of the 
implicit founding principles that sometimes get diluted over time.

This also reminds me of the discussions from a couple months ago where the 
issue at hand was licenses that explicitly deny a patent grant and thus violate 
the OSD (by my analysis) IF the licensor/contributor holds patent rights and 
asserts them via any royalty basis or discriminatory manner.

This issue is rather pressing now with so many federal agencies moving into 
open source, commensurately searching the legal landscape for something close 
to public domain yet still addressing indemnification and contributor patent 
grants.  Some landed on CC0 (oops), others on preambles and DCOs, others trying 
to craft new licenses to fill the perceived void.  All leading to proliferation 
and...

> So, we can think about some things that would increase the load on those
> communities.

… increased load.  How can OSI decrease this load?  Patent rights as they 
pertain to our source code is an undeniable burden on communities and 
developers alike currently.

One possible solution could be to amend the OSD replacing instances of 
"license” with “license and all contributors”.   Thus, for example, OSD#1 is 
clearly violated if there is not a patent grant mechanism in place: “The 
license and all contributors shall not restrict any party from selling or 
giving away the software …” and it would likely mean licenses like CC0 fail 
without an accompanying grant.

I can think of a few other possibilities, but that seems like the most direct 
approach that instills that it’s not just the license that determines whether 
code is “Open".  People do.

> License proliferation: We don't want them to have to do more license
> combinatorial analysis than should be necessary. Thus, we should not in
> general accept new licenses, unless they in some way present a benefit to
> the community in a way that presently-accepted licenses do not.

Assuming software patents don’t go anywhere anytime soon, logically one can 
predict an approximate 2x proliferation given only a handful (5?) address 
patent rights.  BSD+Patent is exemplary.

> there are a few
> unfortunately-OSI-accepted time bombs waiting for new victims.

How about creating a deprecation policy?  This community could (should?) define 
formal revocation criteria for delisting, timeframes, appeal process.  They 
dilute and … increase load.

Cheers!
Sean

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and the US Government

[Christopher Sean Morrison]

> On Aug 28, 2017, at 12:34 PM, Stephen Michael Kellat  
> wrote:
> 
> As bad as it sounds, would a brief statutory clarification be useful in this 
> instance? We can write around Congress all we want but getting them to fix 
> this to be public domain globally is best done by amending the law. A small 
> rider proposed through channels per the Recommendations Clause in Article II, 
> Section 3 of the federal constitution would work nicely.

It would likely take a handful of folks just to figure out exactly what clause 
is unclear or what position is being changed.

Given the USG currently asserts copyright internationally, such an amendment 
would probably receive considerable resistance, but let’s assume it passes.  If 
Title 17 were changed to say no copyright protection internationally, that 
could clear up the issue in Article 18 of the Berne Convention — there would be 
expiry internationally in the country of origin, thus public domain 
internationally.  On the other end of the spectrum, Title 17 could be changed 
to remove the exemption of USG works, the implications there would be utterly 
HUGE, but would allow the USG to use any license.  Somewhere in the middle, 
Title 17 could explain the effect of putting “Copyright US Government” on a 
pure work of the USG, whether that constitutes fraud or invalidate protections 
or that it always only applies internationally.

There was discussion last year about having (official) public discourse on the 
Federal Register regarding the new Federal Open Source Policy and these exact 
issues.  That would probably be a better starting point.  The Open Source 
community could strategize for months, only to be shot down by a single 
influential DoD contractor citing market interference or harm by the USG.

Cheers!
Sean


___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] NOSA 2.0, Copyfraud and the US Government

[Christopher Sean Morrison]

>> Hi all, as you know I've been pushing the position that the US Government 
>> may 
>> have problems using copyright-based licenses on works that do not have 
>> copyright attached.  One of the lawyers I've been working on this with has 
> 
> How is their position if the works are in the Public Domain only
> in the USA? Their own copyright FAQ says that even US government
> work may be copyright-protected e.g. in Germany.

That’s why the language is specifically “works that do not have copyright 
attached”.  Just because there’s no copyright protection does not mean the USG 
can’t sell/share/trade to some other country (think US selling a tank to 
Germany) under some agreement/contract/convention/treaty.  What the copyright 
act makes clear is that there simply is no default copyright protection, but it 
doesn’t preclude holding copyright or restricting rights through other means.  
The interesting question (to me) is what happens when an agency uses contract 
law to restrict a right the copyright act specifically covers.  For example, 
attribution.  To date, the answer has been “nothing".

The FAQ does imply that some license is needed because of the international 
context.  To limit license proliferation, it would be desirable to leverage 
what’s already in place.  This is what the code.gov  guys are 
trying with a simple INTENT declaration.  Previously, the main players were 
(and are still) relying on contract law (e.g., NASA) or acquiring copyright 
through assignment.

> So, in the end, “we” need a copyright licence “period”.

Government Services Administration folks have started testing the theory, but 
not all departments agree.  Without case precedence, it has kept unanswered 
questions of fraud and license validity (and implications therein like 
severability) from the folks in the “you need a contract” camp.

Cheers!
Sean

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] notes on a systematic approach to "popular" licenses

[Christopher Sean Morrison]

> On Apr 7, 2017, at 2:14 PM, Smith, McCoy  wrote:
> 
> But I think that at some point it would be helpful for there to be a resource 
> for people to sift through all the licenses on the list to understand what 
> they do and don’t do.

Isn’t that exactly what https://tldrlegal.com  does?  
They even have the OSI-approved ones marked and sorted by popularity (as 
determined by eyeballs on their site):  
https://tldrlegal.com/licenses/tags/OSI-Approved 


Cheers!
Sean

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [Non-DoD Source] Re: patent rights and the OSD

[Christopher Sean Morrison]

> I say this over and over but while it is laudable for you to give away 
> something you create to the world it is unethical for you to give away 
> something someone else created to the world.

And therein is one of the major problems with software patents.  Given enough 
separation or time, we can both entirely independently create the same thing.  
One wants to give it to humanity for public good.  Someone else wants to make 
money or restrict distribution.  You can argue “well who was first” but that 
goes out the window with first-to-file — one player has absolutely no interest 
in filing.

Perhaps not legal, but I don’t think it's unethical to give away something 
someone else created if your work was created entirely independently without 
knowledge of them or their patent status.

Cheers!
Sean

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [Non-DoD Source] code.mil update

[Christopher Sean Morrison]

> On Mar 8, 2017, at 9:32 AM, Karan, Cem F CIV USARMY RDECOM ARL (US) 
>  wrote:
> 
> You might want to re-read what they posted; the license applies only to those 
> portions of the code that have copyright attached, otherwise it's public 
> domain.  The trick is that while US Government (USG) works are ineligible for 
> copyright within the US, they may be eligible for copyright outside the US, 
> and in those areas the USG works are licensed under the OSI-approved license. 
> I'm not sure what it would mean for code that was moved across jurisdictions, 
> but I do understand and appreciate the intent of their approach.

They’ve slapped a copyright-based license file on the collective work with an 
INTENT file clarifying that it only applies to code that has copyright 
attached.  I read what they wrote very carefully.  We’re saying exactly the 
same thing.

It’s an interesting approach that is not new, just untested and a point of 
dispute in the past as to what might happen.

Sean

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

[License-discuss] code.mil update

[Christopher Sean Morrison]

On a rather unrelated note (apologies for the deluge of e-mails today!), the 
folks behind code.mil have responded to public feedback and are proposing 
significant changes to their approach.


Instead of wrapping an OSI license as before, they now propose to directly 
utilize an existing copyright-based open source license.  That is, they may 
actually attempt to test the theory postulated by Richard Fontana et al., 
namely that horrible things might not actually happen if the USG slaps a 
copyright-based license on their works.  Instead of wrapping the license, they 
use it straight up with an INTENT.md file to explain that what's public domain 
obviously remains as such, and what's not falls under the license.  Details 
here:



https://github.com/deptofdefense/code.mil#welcome-to-codemil---an-experiment-in-open-source-at-the-department-of-defense

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [Non-DoD Source] Re: patent rights and the OSD

[Christopher Sean Morrison]

On Mar 07, 2017, at 07:15 PM, "Tzeng, Nigel H."  wrote:


I dislike this approach. If CC0 passes OSD then it should get approved as is. 
If a patent grant is now a requirement to pass the OSD it should be added as a 
criteria and a license passes or fails based on the license text itself.


There already is criteria -- the problem, as you noted, is that there may be a 
third party with patent rights on a method used by the code, thus making any 
recipients of the code unable to exercise (some) assurances expressed in the 
OSD.



Is a library that implements, e.g., the GIF patent open source if I can't sell 
or export that code?  I can certainly see reasonable arguments both ways.



What sparked this discussion is a license that explicitly says "you don't have a 
patent grant from me or, effectively, anyone that has ever contributed to this 
code."  I don't know if it's a small subset as suggested as I have only ever 
(knowingly) encountered patented code from the original authors (CAD domain), but if one 
of them put a license on their code and said contact me for a patent license, that feels 
entirely in violation of the current OSD as written because of what it knowingly 
prohibits.



If Creative Commons feels strongly that CC0 should only be used with some sort 
of patent grant the easiest course is simply to remove the disclaimer of patent 
grant and call it CC0-software or something. Then it would have the same 
implicit grant as BSD and there is no issue with approval and no new composite 
license structure that will just confuse people even more.


This certainly sounds like an interesting approach that I can raise with them, 
but obviously lacks the explicit rigor favored by the Gov't lawyers.  
Otherwise, a different license like the Free Public License would be a 
competing option (at least in terms of non-proliferation), no?


The niche area seems to be specifically public-domain without explicitly 
disavowing patents and without knowingly permitting patentee contributors to 
create a situation.



Cheers!

Sean


___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] patent rights and the OSD

[Christopher Sean Morrison]

On Mar 07, 2017, at 06:58 PM, Lawrence Rosen  wrote:



Christopher Sean Morrison wrote:


Software patents are terrible in part because they pertain to the source code 
itself, thus affecting the distribution terms on that code.


 

Patents don't pertain to source code or to code distribution, at least not in legal terms 
of direct patent infringement. Patent rights pertain to the "use" of the 
software, not its written description.



I didn't meant to imply that the code itself infringes on the patent, but rather that the 
"it pertains" in the practical sense that one can test whether OSD #1 or #7 are 
permitted by looking at the code.


Is it not true that if the code satisfies a patent's claims, any recipient 
could not engage in free redistribution without a patent grant?  That is what 
makes this an OSI matter in my view.



Cheers!
Sean

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] patent rights and the OSD

[Christopher Sean Morrison]

On Mar 07, 2017, at 04:45 PM, Ben Tilly  wrote:


When we talk about whether a software license is OSD compliant, we are only 
addressing the question of whether this license restricts software under 
copyright law in a way that violates the OSD.


I hear you, but I don't see where the OSD says that.  It does not mention copyright law.  
The OSD annotated or otherwise doesn't even mention the word 'copy'.  It (specifically?) 
says "the distribution terms".



While I certainly can understand the perspective that there are other laws, 
regulations, and factors, not all of them affect distribution terms of the 
software -- they are restrictions on me, my assets, my situation, not the 
software.  Software patents are terrible in part because they pertain to the 
source code itself, thus affecting the distribution terms on that code.



In a way, it's convenient that the OSD does not specifically call out copyright 
and speaks generically.  It's a testament of forethought (or luck) of the 
original authors.



Cheers!

Sean




___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [Non-DoD Source] patent rights and the OSD

[Christopher Sean Morrison]

On Mar 07, 2017, at 04:09 PM, Richard Fontana  wrote:


On Tue, Mar 07, 2017 at 03:55:37PM +, Christopher Sean Morrison wrote:


Of particular significance, it calls into question whether there are
any OSI-approved licenses that specifically exclude patent rights in
the current portfolio or whether CC0 would be the first of its
kind.  If there ARE, then CC0 would not create a precedent situation
any worse than currently exists and approval could move forward.

I'm not aware of any.


I guess that's a good thing...  (oof! more work then)

 
There is the 'Clear BSD' license, which the FSF considers not only a
free software license but also GPL-compatible:

https://directory.fsf.org/wiki/License:ClearBSD
https://www.gnu.org/licenses/license-list.en.html#clearbsd

But I am not aware of this license ever having been submitted for OSI
approval.


It's okay if OS != FS.  They're allowed to get it wrong from time to time too. 
;)



I've also seen one or two companies engage in the practice of
licensing code under GPLv2 accompanied by a statement that no patent
licenses are granted.


By my reading, those "distribution terms" violate OSD #1 and #7.  This is 
potentially a problem for any license (e.g., all the permissives) that doesn't 
specifically speak to patent rights.  If the distribution terms specifically deny a 
patent grant, it will no longer be possible to freely redistribute the source code (that 
is, IF any contributor holds patent rights whose claims are implemented by the source 
code...).

 
So in other words, "this license is Open Source to the extent that,
when used, it is accompanied by [a separate appropriate patent license
grant]", for example?


Yes!  It would only be required on any license that explicitly disclaims patent rights.  
However, it'd also be a reasonable statement for any license that grants implicitly as 
well.  For those, the converse might be, "this license is NOT Open Source if it is 
accompanied by an explicit denial of patent rights."  Of course, explicit denial 
arguably makes the distribution terms of any license fail the OSD.



Cheers!

Sean


___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [Non-DoD Source] patent rights and the OSD

[Christopher Sean Morrison]

On Mar 07, 2017, at 09:07 AM, "Karan, Cem F CIV USARMY RDECOM ARL (US)"  wrote:I personally think that software that is distributed without a patent license or a waiver of patent claims is not Open Source (this is my opinion, and not a Government position).It certainly fails a smell test in modern times.  However, this is not something addressed by the OSI board, called out by the OSD, and has only been ad hoc discussed by folks here.Of particular significance, it calls into question whether there are any OSI-approved licenses that specifically exclude patent rights in the current portfolio or whether CC0 would be the first of its kind.  If there ARE, then CC0 would not create a precedent situation any worse than currently exists and approval could move forward.If there AREN'T, that begs under non-proliferation for any new licenses that explicitly disclaim patent rights to be found OSD-inadequate, particularly w.r.t. clauses #1 and #7.  Moreover, any license approval for a new license containing a patent disclaimer (e.g., CC0) would necessarily require modification or accompaniment by a required patent grant mechanism (such as ARL's approach) in order to satisfy the OSD.Of course, the OSI should still weigh in on this.  Either OSD is applied as-is and patents are part of "the distribution terms", they are considered separate for historical reasons, or the OSD requires modification.It prevents people from freely modifying the code.Actually holding a patent does not necessarily prevent modification of code.  Of course, there's doesn't seem to be much value in  modifying the code if one doesn't have the right to use, sell, or export it but it's technically not prohibited.  Even more importantly, such modification could very well make the code no longer satisfy patent claims, thus it becoming usable, sellable, etc. again.Cheers!Sean

smime.p7s
Description: S/MIME cryptographic signature
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] patent rights and the OSD

[Christopher Sean Morrison]

> On Mar 7, 2017, at 4:08 AM, Gervase Markham  wrote:
> 
> On 06/03/17 23:41, Christopher Sean Morrison wrote:
>> From my reading, a patent gives the holder the right to exclude
>> others from (a) making, (b) using, (c) selling, or (d)
>> importing/exporting their invention.  The OSD clauses refer to “the
>> distribution terms” in rather license- and copyright-agnostic terms,
>> so here’s my basic layman analysis:
>> 
>> 1) Exclusion (a) seems not problematic for the OSD as it precludes
>> others outside of licensing. 2) Certainly a problem in the broad
>> sense, but exclusion (b) seems not problematic with the OSD.
> 
>  Are you saying that a prohibition on using the software is not
> an OSD problem?

It left me blinking too.  Which OSD clause requires the distribution terms to 
permit use?

In the generic sense, one might argue that not having usage rights restricts 
(everyone) “from making use of the program in a specific field of endeavor” per 
OSD #6.  However, that seems like a stretch since not having a patent grant 
prevents use indiscriminately in *all* fields of endeavor.  There’s similar 
indiscriminate prohibition in #5 too.

I’ll be happy to be corrected, but it seems to me as though the OSD criteria 
does not speak to using the software.   

Cheers!
Sean

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

[License-discuss] patent rights and the OSD

[Christopher Sean Morrison]

In light of the recent CC0 discussion, I’m refreshing my mind on what rights 
are provided under patent law, each of the OSD criteria, and any connections 
between them.

From my reading, a patent gives the holder the right to exclude others from (a) 
making, (b) using, (c) selling, or (d) importing/exporting their invention.  
The OSD clauses refer to “the distribution terms” in rather license- and 
copyright-agnostic terms, so here’s my basic layman analysis:

1) Exclusion (a) seems not problematic for the OSD as it precludes others 
outside of licensing.
2) Certainly a problem in the broad sense, but exclusion (b) seems not 
problematic with the OSD.
3) Exclusion (c) seems to fail OSD clause #1 (Free Redistribution) and possibly 
#7 (Distribution of license).  
4) Exclusion (d) similarly fails #1 and #7.

So what?  In terms of OSD compliance, there appears to be several issues if a 
patent exists and one does not grant/hold a royalty-free patent license.  If I 
have a software patent and license that software under CC0, for example, 
without any other distribution terms in place, it’s my reading that this would 
technically be distribution terms that violate OSD #1 and #7.

This creates an interesting situation where “the distribution terms” of some 
software will depend on whether the distributor holds a patent, not necessarily 
on the language of their license.  There are, of course, ample examples of 
licenses that convey conforming patent rights, both implicit and explicitly.

Does anyone disagree that holding a patent and not granting a patent license 
violates the OSD, perhaps as an out-of-band perspective?  Should the OSD only 
be measured against a copyright standard, as originally drafted?  Does OSI need 
to clarify “all bets are off” if there’ s a patent or consider them as part of 
the distribution terms equally?  What are other people’s thoughts on this?

Cheers!
Sean

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Possible alternative was: Re: U.S. Army Research Laboratory Open Source License (ARL OSL) Version 0.4.1

[Christopher Sean Morrison]

> On Mar 1, 2017, at 4:17 PM, Rick Moen  wrote:
> 
> Quoting Lawrence Rosen (lro...@rosenlaw.com):
> 
>> The question remains from many years of discussion here: What is wrong
>> with CC0 being approved by OSI as a license for components in other
>> open source software? Including for U.S. government works that may (or
>> may not) be public domain?
> 
> For whatever it's worth, I said at the time it was under review that CC0
> was very clearly open source, and thus approving it makes sense despite
> its unfortunate explicit waiver of patent rights.
> 
>> The absence of an explicit patent provision applies equally to the BSD
>> and MIT licenses. 
> 
> I will quibble that these are not the as an explicit denial of even an
> _implicit_ patent license, which is the situation that applies with CC0.
> I continue to say, CC0 would be made a better permissive licence were
> that clause removed.  But I would not wish the ideal to become the enemy
> of the good.

Ditto, I think CC0 would be a far better license if it included an explicit 
patent grant or at least had an author option to include one.  I can raise that 
point with them to see if their perspective is any different now X years later 
or if any development is in the works.

From what Richard said, it sounds like a CC0 submission “should” be the steward 
so I’ll contact them to see if they’re willing to submit it again given recent 
developments.  However, if they decline, I’ll write up and submit the request 
myself as a Gov’t proponent.  If anything, it will let the patent right denial 
discussion be hashed out and a decision can be made here or by the OSI board.

Cheers!
Sean

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Possible alternative was: Re: U.S. Army Research Laboratory Open Source License (ARL OSL) Version 0.4.1

[Christopher Sean Morrison]

> A proposed solution, however, is that the U.S. government will distribute 
> software under CC0. I don't care if that is sensible. I don't care if that is 
> odd. I do care that CC0 be an OSI-approved license, regardless of its flaws.
>  
> That will reaffirm the authority in our community of the OSI-approved open 
> source license list, regardless of the elegance of that solution for DOSA.

I don’t think you’ll find any disagreement, even amongst USG developers and 
lawyers.  OSI is the established authority and many programs (e.g., Google 
Summer of Code) require that projects utilize an OSI-approved license.

If I recall correctly, there were no objections to CC0 when it was submitted 
for OSI approval.  It was withdrawn by the steward after prolonged patent 
clause commentary.  considering what the implications of explicitly denying 
patent rights may have on the liberal licenses.  That commentary was not 
grounds for disapproval and not a fault of CC0, it was primarily a social and 
license impact discussion, but it was withdrawn regardless.  So … 

The only question I have is whether the license steward is the only one 
eligible to formally submit CC0 for reconsideration?  If not, I will formally 
submit it myself as there is ample evidence of prolific use, niche utility that 
differentiates it from other licenses, and no known clauses that conflict with 
the OSD.

That way, we can all get past the distracting “it’s not OSI-approved” rote.

Cheers!
Sean

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) Version 0.4.1

[Christopher Sean Morrison]

> One main exemption to FOIA is that internal pre-decisional work product of 
> lawyers is exempt from disclosure.  Any contribution on this list could be 
> considered privileged communication by those lawyers.  I doubt there would be 
> enough caveats and disclaimers to keep any communication on-list from being 
> considered possible official agency action subject to the Administrative 
> Procedures Act.  A lone non-lawyer might be able to skirt the APA barely but 
> once the lawyers come in then the machinery of government would kick in and 
> things would need publishing in the Federal Register.

Never hurts to file a FOIA.  Some agencies heavily frown on denying requests 
even when they are not obligated to disclose because it’s terrible PR.  Case 
point, numerous filings with NSA.

> For as long as this issue has been running, moving things over to actually 
> having the Army running an inquiry opened up in the Federal Register where 
> the public can comment and attorneys for the Army can respond probably will 
> be worthwhile.  For as much as this list can be reactive, it is time for DoD 
> and Army to put their cards on the table for feedback.

This is essentially what happened with the White House’s Federal Open Source 
Code Policy [1].  The problem is no case law on several key points and there 
probably won’t be much progress until at least one agency is burned or 
vindicated in court.  Until then, agencies are getting immense internal 
pressures to participate in open source without much of any official guidance 
because it’s entirely counter-culture.

If anything, it’s great to see efforts like ARL and White House pushing through 
formal guidance on CC0, and even the recent awkward code.mil effort saying 
“wrap it in a contract” because the devs sitting at desks need something, 
anything, yesterday. 

Cheers!
Sean


 [1] https://sourcecode.cio.gov 

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [Non-DoD Source] Re: OSI equivalent

[Christopher Sean Morrison]

> I was afraid of that... and so is our Legal department :(.  We want to issue 
> good general guidance to everyone in our workforce, but at the moment that 
> appears to be 'go talk with Legal'.  
> 
> As for the image by Dr. Wheeler, it doesn't seem to have come through; can 
> you try resending it?

It was the blue diagram from here:  
https://en.wikipedia.org/wiki/License_compatibility#Compatibility_of_FOSS_licenses

That Wikipedia page in general (and the sources it cites) is probably your best 
overall resource.

As for receiving the image, DoD Outlook is configured to block images, 
attachments, and formatting by default for “Non-DoD Source” mail.  You have to 
right-click a notification at the top of the message to display blocked content:

https://support.office.com/en-us/article/Block-or-unblock-automatic-picture-downloads-in-email-messages-15e08854-6808-49b1-9a0a-50b81f2d617a

Cheers!
Sean

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] OSI equivalent

[Christopher Sean Morrison]

> On Feb 15, 2017, at 11:58 AM, Karan, Cem F CIV USARMY RDECOM ARL (US) 
>  wrote:
> 
> Does OSI have a license compatibility chart for the various approved 
> licenses? 
> Something similar to https://www.gnu.org/licenses/license-list.html ?  Our 
> researchers are pulling in code from all kinds of sources, and we want to 
> keep 
> them out of legal hot water, and a compatibility chart would be helpful for 
> this.


Hi Cem,

There are a variety out on the web but nothing officially sanctioned because 
the devil is in the details when you talk about compatibility.  It depends 
heavily on whether you are integrating, modifying, or simply using (unmodified) 
the 3rd party code.  Creating a combined work is not necessarily the same as 
creating a derivative work is not the same as just linking against something.  
There are different compatibility concerns with each. 

For example, I can create an LGPL program that uses an Apache 2.0 library just 
fine, and distribute it as a combined work without too much concern.  I can 
also create an Apache 2.0 program that links to an LGPL library, but I’d have 
to be more careful with how the LGPL library is linked (assuming there is no 
link exception granted) and used — no muddling of the code waters or my program 
becomes LGPL too.  It’s a fair bit more complex with the strongly protective / 
viral licenses.

The attached image by Dr. David Wheeler (renowned Mil-OSS security researcher) 
is a reasonable starting point that you can find readily around the web in 
various forms.  The flow diagram is basically describing code compatibility in 
the most general terms, about how/where code can migrate and/or be relicensed.  
E.g., I can’t take an MIT code and distribute it as public domain; but I can 
take a public domain code and distribute it as MIT.  Note it’s NOT referring to 
simple usage or linking, otherwise it might falsely lead you to think you can’t 
link against an Apache 2.0 library in a GPLv2 work.

Cheers!
Sean







___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] step by step interpretation of common permissive licenses

[Christopher Sean Morrison]

> On Jan 13, 2017, at 1:05 PM, Massimo Zaniboni 
>  wrote:
> 
> Hi,
> 
> I tried interpreting the terms of common permissive licenses following a 
> "step by step" approach, like if they were instructions in programminng code, 
> and I found with my big surprises that doing so they became non permissive 
> licenses, or permissive licenses only using some "border-line" interpretation.

I would caution that many seemingly ordinary words can take on a different or 
more specific legal meaning in court.  That said... this was not your error.

> http://another-ticket-in-the-wall.blogspot.it/2016/11/oss-licenses-debugging.html
> 
> Probably I'm wrong, but I'm curious to understand where. So if someone has 
> the patience to read the post,  can report here a fault part of my reasoning, 
> so I can understand better and maybe discuss?

You make a mistake assuming C's license must be involved in the compliance of 
B's attribution notice (clause 2) requirement.

More specifically, you ask "Is C respecting the BSD-2 license of B?"

You do not know and do not need to know this by looking at C's license.  B's 
license is very flexible in terms of where the attribution notice maybe placed. 
 As long as C puts it in the documentation or other materials provided with the 
distribution, it will be in compliance.  Many commercial products, for example, 
comply by putting B's license on a credits or legal section accessible to users 
at runtime from within the software itself, and that is fine.


Cheers!
Sean


___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Using opensource in a company not in the software business

[Christopher Sean Morrison]

Etienne,

You may also want to look at https://tldrlegal.com/  as 
it’s a site that tries to simplify license understanding.  Of course, still pay 
attention to the full text of any license you work with and seek legal 
consultation as warranted, but maybe a useful resource for getting a handle on 
the terminology and differences.

I suggest going down the list of “MOST POPULAR” licenses first, as they are 
very well-understood and in prevalent use.  

Cheers!
Sean



> On Dec 1, 2016, at 4:57 AM, FREJAVILLE Etienne 
>  wrote:
> 
> Thank you for the link below that I had searched without success.
> Moreover this discussion helped me better understand the terminology (still 
> lightly ambiguous, but after all it’s the problem with natural language, no ? 
> ;-))
> I see that it can become very tricky with some licences and particular 
> technologies..
> I think the best is to start with licences that are clearly permissive for 
> our situation, and have our legal department keep an eye on that. They’ll 
> decide what to do for other situations more subtle.
>  
> Best regards.
>  
> Etienne
>  
> De : License-discuss [mailto:license-discuss-boun...@opensource.org 
> ] De la part de Radcliffe, Mark
> Envoyé : mardi 29 novembre 2016 19:36
> À : license-discuss@opensource.org 
> Objet : Re: [License-discuss] Using opensource in a company not in the 
> software business
>  
> And being compliant is the right thing to do.
>  
> From: License-discuss [mailto:license-discuss-boun...@opensource.org 
> ] On Behalf Of Ben Tilly
> Sent: Tuesday, November 29, 2016 10:32 AM
> To: License Discuss
> Subject: Re: [License-discuss] Using opensource in a company not in the 
> software business
>  
> If you host the software on a server and they hit that API, this does not 
> count as distribution.  But there are licenses, such as the AGPL, that will 
> still cause you problems there.
>  
> The exact definition of when linking creates a derivative work has not to my 
> non-lawyerly knowledge been litigated.  Many lawyers think that the GPL FAQ 
> is overly optimistic about how much power the license will have if litigated. 
>  On the other hand staying within its suggestions greatly limits the odds of 
> problems down the road.
>  
> In general each open source license aims to allay some fear that the author 
> of the software had.  Some, like the MIT and Apache licenses, protect the 
> authors and otherwise make it easy to use the code as you see fit.  Others, 
> like the GPL, avoid having someone build something cool on your software 
> while refusing to let you see/build on that.
>  
> It is likely easiest for you to start with 
> https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses#FOSS_licenses
>  
> ,
>  decide where your comfort level is, and try to only use software on one side 
> of that.  That's a lot easier than staying careful about exactly how you use 
> each piece of software.
>  
> Alternately you can decide that you are not in the software business after 
> all, give away all distributed software with source, and charge for access to 
> a service that you maintain.  (And avoid the AGPL!)
>  
> On Tue, Nov 29, 2016 at 12:27 AM, FREJAVILLE Etienne 
> mailto:etienne.frejavi...@coface.com>> wrote:
> Hello,
>  
> Thank you for the answers. It seems that we are concerned even though we 
> don't sell the software provided to the customer.
> Apparently, the fact that the customer uses the software from the outside of 
> the company counts as a 'distribution'.
>  
> I may submit that topic to our lawyers, but before I have more precise 
> questions related, concerning particular uses of licences, to be sure I 
> understand them correctly.
> And I agree not to trust 'as is' answers from a mailing list, but it's a good 
> start!
>  
> It seems that Apache, BSD, MIT... licences do not cause particular problems 
> in our context (and in general).
>  
> Concerning GPL, I have found in the GPL's FAQ that:
>  
> "The community expects that all code linked to GPL code will be licensed 
> under the GPL, even if the link is made at runtime using a shared library"
>  
> Does it means that in that case we should release publicly under the GPL 
> licence any of our source code that use the open source libraries ?
> If true, does indirect usages are also concerned ? Libraries that call 
> libraries that call open source libraries will also have to be licenced under 
> the GPL licence ?
>  
> Concernin

Re: [License-discuss] Views on React licensing?

[Christopher Sean Morrison]

Interesting, I hadn’t heard about the React licensing yet.  Thanks.

> The 'Additional Grant' has attracted a fair amount of criticism (as
> did an earlier version which apparently resulted in some revisions by
> Facebook). There was a recent blog post by Robert Pierce of El Camino
> Legal [3] (which among other things argues that the React patent
> license is not open source). Luis Villa wrote an interesting response
> [4].

Mr. Pierce’s first criticism point about the grant itself being unnecessary is 
spot on to me.  One cannot "use the software” without implying a patent 
license; and the BSD-styles have such an incredibly well-established industry 
understanding that (to me) it’s ludicrous to consider it could be interpreted 
any other way.  I would very much like to know what [profanity] company would 
try to pull such a stunt as plaintiff.

The only utility of React’s PATENT file is the rather broad retaliation.

> What do members of the license-discuss community think about the
> licensing of React? I see a few issues here:

Conflicted.

> - does the breadth of the React patent termination criteria raise
>  OSD-conformance issues or otherwise indicate that React should not
>  be considered open source?

At best, it could be argued as some form of implicit discrimination (#5) or 
revocation of right to redistribute (#1).  Retaliating against an “any" 
plaintiff vs only a specific class of plaintiff (e.g., Apache 2.0), though, 
isn’t very compellingly different.  Seems like a stretch to me.

> - is it good practice, and does it affect the open source status of
>  software, to supplement OSI-approved licenses with separate patent
>  license grants or nonasserts? (This has been done by some other
>  companies without significant controversy.)

This is also a direction that has been discussed and is being pushed by some of 
the White House (code.gov ) and other Gov't lawyers.

In cases like “CC0 + patent grant”, it may make sense given CC0 explicitly says 
there’s no patent grant. (Yes, I know CC0 is not (yet) an OSI license.  That 
should change.)  In the case of the implicit permissives, though, I think it’s 
very bad practice.  Creates unfounded FUD and license proliferation motivation, 
counterpart licenses explicitly with/without a patent grant.

Cheers!
Sean

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

[Christopher Sean Morrison]

I pleaded with the OSI board to provide formal feedback on the draft Federal 
Open Source Policy during the request for comment phase, but to my knowledge 
nobody did anything.  Opportunity lost.



Indeed, that promised licensing guidance is coming from Federal Source Code 
Policy [1] which was just established.  It's part of the White House's Second 
Open Government National Action Plan, and was 2 years in the making (7 years if 
you count from Obama creating the Open Government Initiative).



The Federal policy actually mandates 20% of all software development must be 
open source, which is unprecedented, albeit currently without measurement 
criteria or enforcement teeth.  That's why I said the White House is prompting 
discussions; they're most definitely getting a lot of folks riled up from the 
highest level.



One of the biggest issues with the policy timing is that they completely punted 
on licensing, copyright, and legal mechanics, merely saying guidance will be 
provided later on code.gov undoubtedly for all the complex reasons being 
discussed here.


That means the clock is now ticking fast to November.


Tony Scott (U.S. Chief Information Officer) could settle things by issuing clarifying 
guidance on copyright and licensing, but his support apparatus will not necessarily exist 
afterwards.  It's most likely that there will not be legal agreement and guidance 
eventually published will amount to "using OSI licensing is a great idea, talk with 
your agency's lawyers on specifically how."



That said, there are some really smart guys working these issues in OMB and DoD 
pressing for change, so the optimist in me remains hopeful.



Cheers!

Sean



[1] https://sourcecode.cio.gov/




On Aug 18, 2016, at 11:47 AM, "Smith, McCoy"  wrote:


Given that the White House just released a memorandum on encouraging the USG to 
make more use of open source, and specifically said that it will be releasing 
licensing guidance on code.gov, perhaps the issues around 17 USC 105 and 
existing open source licenses will be resolved (or at least, the issues around 
existing open source licenses will be identified clearly) on behalf of all the 
USG:
https://www.whitehouse.gov/sites/default/files/omb/memoranda/2016/m_16_21.pdf


-Original Message-
From: License-discuss [mailto:license-discuss-boun...@opensource.org] On Behalf 
Of Christopher Sean Morrison
Sent: Thursday, August 18, 2016 1:27 AM
To: license-discuss@opensource.org
Subject: Re: [License-discuss] [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. 
Army Research Laboratory Open Source License (ARL OSL) 0.4.0

There is exceptional evidence that the status quo is wholly inadequate. OSI 
fails to recognize challenges faced within the Federal Government, and it hurts 
open source adoption.

Statistically speaking as the largest producer of source code on the planet, the 
U.S. Federal Government *should* be one of the largest participants in open source 
yet there is barely a presence. Some people recognize NASA as one of the largest 
proponents in the Gov’t space, yet they are one of the smaller agencies with one of 
the smallest budgets. Federal R&D, which is predominantly computer science 
work, is more than double the size of NASA’s entire agency! There are more computer 
scientists writing code for the Gov’t than there are for any single company in 
existence, including the likes of Google and Microsoft.

Let that sink in for a minute.

Where is all the code? If it was simply a release issue, there would at least 
be lots of public domain code floating — there’s demonstrably not. [1] If even 
a measurable percentage of Government lawyers felt existing OSI licenses were 
apropos, there would be a ample evidence of agencies using MIT/Apache/LGPL/etc 
— there’s demonstrably not. [2]

There has been presented here a position by at least two major federal agencies 
(DoD and NASA) that copyright-based licensing is specifically viewed as a 
problem by their respective lawyers. There is obvious disagreement and 
uncertainty, but therein lies a fundamental problem. Nobody’s opinion has been 
tested. Nobody can prove that their point is any more or less correct.

Lacking case law evidence, all that remains is overwhelming industry evidence 
that what is currently available is not in any way viewed as adequate in the 
Federal space. At a minimum, there is enough uncertainty that there is zero-% 
penetration.

You have agencies here trying their damnedest to find ways to support open 
source amidst ambiguous regulations, unique legal circumstances (copyright), 
notoriously risk-averse environments, and untested theories. You have specific 
representatives (for huge organizations) here saying “I would use this, it 
would help us”. That to me those make for pretty freaking compelling reasons to 
support any new open source licensing, if it will increase adoption of open 
source in the Federal space.

I ra

Re: [License-discuss] [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

[Christopher Sean Morrison]

There is exceptional evidence that the status quo is wholly inadequate.  OSI 
fails to recognize challenges faced within the Federal Government, and it hurts 
open source adoption.

Statistically speaking as the largest producer of source code on the planet, 
the U.S. Federal Government *should* be one of the largest participants in open 
source yet there is barely a presence.  Some people recognize NASA as one of 
the largest proponents in the Gov’t space, yet they are one of the smaller 
agencies with one of the smallest budgets.  Federal R&D, which is predominantly 
computer science work, is more than double the size of NASA’s entire agency!  
There are more computer scientists writing code for the Gov’t than there are 
for any single company in existence, including the likes of Google and 
Microsoft.

Let that sink in for a minute.

Where is all the code?  If it was simply a release issue, there would at least 
be lots of public domain code floating — there’s demonstrably not. [1]  If even 
a measurable percentage of Government lawyers felt existing OSI licenses were 
apropos, there would be a ample evidence of agencies using MIT/Apache/LGPL/etc 
— there’s demonstrably not. [2]

There has been presented here a position by at least two major federal agencies 
(DoD and NASA) that copyright-based licensing is specifically viewed as a 
problem by their respective lawyers.  There is obvious disagreement and 
uncertainty, but therein lies a fundamental problem.  Nobody’s opinion has been 
tested.  Nobody can prove that their point is any more or less correct.

Lacking case law evidence, all that remains is overwhelming industry evidence 
that what is currently available is not in any way viewed as adequate in the 
Federal space.  At a minimum, there is enough uncertainty that there is zero-% 
penetration.

You have agencies here trying their damnedest to find ways to support open 
source amidst ambiguous regulations, unique legal circumstances (copyright), 
notoriously risk-averse environments, and untested theories.  You have specific 
representatives (for huge organizations) here saying “I would use this, it 
would help us”.  That to me those make for pretty freaking compelling reasons 
to support any new open source licensing, if it will increase adoption of open 
source in the Federal space.

I ran on this platform for the 2016 OSI board election and missed it by fewer 
votes than I have fingers.  This is a problem to a tremendous number of people. 
 OSI licensing isn’t the only problem [3] faced by the Federal Government, but 
it is one of the most significant that has solutions being presented.  NOSA 1.3 
was offered but was then immediately shot down by FSF (for good reason, why is 
it even still on OSI's list??); NOSA 2.0 won’t likely be a solution without 
rework.  ARL OSL aims to be so transparently compatible that it arguably limits 
proliferation (to the extent you can while creating a new agreement) and has 
much greater adoption potential with ASL’s rigor behind it.

Dissenting won’t make agencies suddenly agree to just slap copyright-based 
licensing on their works or even releasing into PD.  It will just continue to 
be lost opportunities for open source until there is congressional mandate, 
DoJ/DoC clarity, or case law clarity.  White house is currently advocating and 
creating discussion, but we’ll see if that survives the election.

Cheers!
Sean

[1] NIST, NASA, and 18F are outliers among hundreds of agencies.
[2] What you can find are works involving contractors where copyright gets 
assigned.
[3] Cultural ignorance is so maligned that DoD CIO actually had to tell 
agencies it’s *illegal* to NOT consider open source. 


> On Aug 17, 2016, at 5:46 PM, Radcliffe, Mark  
> wrote:
> 
> I agree with McCoy.  As outside General Counsel of the OSI for more than 10 
> years, the drafting of a new "open source" license requires strong reasons.  
> The reasons that I have seen in the list don't meet that standard.  I 
> strongly recommend against trying to develop a new "open source" license. 
> 
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Smith, McCoy
> Sent: Wednesday, August 17, 2016 11:54 AM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. 
> Army Research Laboratory Open Source License (ARL OSL) 0.4.0
> 
> Or to put a finer point on it, the other issues you identify appear to be 
> ones that are explicitly addressed in many already-approved OSI licenses, 
> including Apache 2.0, the one you are modeling your license upon.
> 
> I hope you're getting a sense that there are several lawyers on this mailing 
> list -- lawyers who have years of experience looking at, debating, and giving 
> advice on the issues you identify in this submission -- who think that your 
> proposed license is a variant of Apache 2.0 designed to solve a "problem" for 
> USG users wit

Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

[Christopher Sean Morrison]

The point here though is the assumption ARL is apparently making, that
an effective warranty or liability disclaimer must be tied to a
(seemingly) contractual instrument. CC0 is evidence that some lawyers
have thought otherwise.


They have acknowledged as much.  However, lacking precedent evidence to the 
contrary, ARL's lawyer believes recipients can be held to the contractual terms 
and this would give the Gov't (or some downstream contributor) standing to stop 
a bad actor.


It's also been opined that the warranty and liability disclaimer could be lost 
if they use a copyright-based license (presumably that the whole license would 
be found invalid due to no copyright, not just the copyright statement bits).  
I don't agree that would happen as DoJ makes a determination of liability under 
their own tort/negligence criteria, but also not tested except for cases of 
gross negligence.



Can anyone cite precedence for someone trying to put restrictions via 
contract/EULA on a public domain work such it was either upheld or shot down in 
court?  All the various NOSA codes that have been released would be apropos...



Based on this whole thread, I imagine that even if CC0 were
OSI-approved, ARL would find fault with it given that it seems to
assume that the copyright-waiving entity actually does own
copyright. (I have actually found CC0 attractive in some situations
where there is acknowledged uncertainty about copyright ownership.)


No disagreement.  It just goes from being strictly off the table without 
OSI-certification to necessary-but-not-sufficient.



Cheers!

Sean




___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

[Christopher Sean Morrison]

On Aug 16, 2016, at 11:43 AM, "Smith, McCoy"  wrote:


CC0 gives a complete (to the extent permissible by law) waiver of copyright rights, as 
well as a disclaimer of liability for the "Work" (which is that which copyright 
has been waived). I believe that to be an effective waiver of liability, despite the fact 
that there is not copyright rights being conveyed. Does anyone believe that that waiver 
is ineffective?


Gee, if only legal-review had approved CC0 as an open source license, it would 
be a potential option. ;)



As it stands, the board's public position to not recommend using CC0 on 
software [1] due to its patent clause makes it problematic.



Cheers!

Sean



[1] https://opensource.org/faq#cc-zero




___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [Non-DoD Source] Re: US Army Research Laboratory Open Source License proposal

[Christopher Sean Morrison]

> Could you describe what the impact would be to contractors under DFARS
> clauses 252.227-7013/7014 and ARL OSL?  In particular where software was
> developed at private expense or mixed funding and the government has less
> than unlimited rights.

Under 252.227-7014, if the software was not developed exclusively with Gov’t 
funds, the Gov’t has unlimited rights 5 years after the last contract mod and 
could release under ARL OSL.  Before then and devoid of other clauses, the 
contractor would be able to assert copyright and release as OSS.  DFARS 
252.227-7013 pertains to data, specifically not software, but is framed the 
same.

If it was developed exclusively at private expense, the Gov’t has limited 
rights and cannot release.  In that case, it’s up to the contractor.

Cheers!
Sean

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [Non-DoD Source] Re: US Army Research Laboratory Open Source License proposal

[Christopher Sean Morrison]

Very interesting write-up, Maarten.  Thanks for writing and sharing it!

The MET PD image database is pretty awesome work on their part.  I referenced 
some materials from there a couple month myself despite not noticing they put 
an NC clause on it.  Personally, I can’t imagine them having standing if they 
tried to take anyone to court.  I agree that it’s “bad practice” but mostly 
because it creates marketplace confusion and doesn’t conform with the OSD.

The difference here, I think, is that the contract/license is not aiming to 
restrict access or use of the code.  On the contrary, it establishes terms on 
contributors (e.g., similar to a CLA) and explicitly disavows liability.  The 
prior doesn’t require copyright and recursively applies.  The latter is 
arguably unnecessary, but not harmful or restrictive.

The question in my mind is whether any of the other requirements in the 
contract/license are essentially unenforceable because of the lack of rights.  
In ASL2’s terms,  that could be Clause 4 (Redistribution).  The end result of 
being unenforcible would merely wipe attribution but I’d expect the rest to 
remain intact.

Cheers!
Sean
 


> On Aug 3, 2016, at 9:29 AM, Maarten Zeinstra  wrote:
> 
> Hi Kevin and Cem,
> 
> I think the confusion here is indeed about ownership vs, access, As I 
> understand Cem’s project he wants to provide access to third parties to its 
> code and wants to ‘license’ it. However open source license (afaik) deal with 
> the ownership part of the code and does not deal in restricting access to the 
> code.
> 
> I think Cem is indeed on the right track with #3 in his reply. You cannot 
> rely on copyright, you could only focus on any patent aspects of open source 
> license. Coming from the Creative Commons world, I do not know about patents 
> in Open Source licenses.
> 
>  I also think that is near impossible to enforce access limiting contracts in 
> a one-to-all way. I wrote an opinion about a related situation about the New 
> York Metropolitan Museum that provided free downloads of its public domain 
> images but restricted those downloads to non-commercial use: 
> https://www.kl.nl/en/opinion/why-the-met-does-not-open-any-real-doors/ 
>  
> (tl;dr: you cannot enforce general rules about free downloads, and it is a 
> bad practise to try to do so).
> 
> the USG cannot enforce open source license as they have no underlying 
> copyright, any contract drafted that is similar to an open source license 
> without the licensing of copyright and limiting the access or reuse of the 
> work should not be considered a open source license and fall into the 
> category of bad practise. 
> 
> Re: Berne Convention. Sure Page Miller is right. But try and proof me wrong 
> :) but no country in the world has a paragraph in their national copyright 
> act that provides the USG with copyright where they do not hold that 
> nationally. They would rely on the absence of formalities but that means you 
> do need in a rights holder in the country of origine, which does not exist.
> 
> Regards,
> 
> Maarten
> 
> --
> Kennisland | www.kl.nl  | t +31205756720 | m +31643053919 
> | @mzeinstra
> 
>> On 03 Aug 2016, at 15:17, Karan, Cem F CIV USARMY RDECOM ARL (US) 
>> mailto:cem.f.karan@mail.mil>> wrote:
>> 
>> I just got off the phone with Page Miller in the US Copyright office 
>> (http://www.copyright.gov/ ).  She is the person 
>> at the USG that specializes in these types of questions.  She told me that 
>> the Berne convention does not change laws in individual countries, it just 
>> removes certain formalities.  As such, if the foreign government permits the 
>> USG to hold copyright in the foreign country, then the USG is permitted to 
>> do so.  You can contact the copyright office at copyi...@loc.gov 
>> .  If you put in a line like 'Attention: Page 
>> Miller', it will get routed to her to answer.
>> 
>> So, the very latest position of the USG is that it can apply for copyright 
>> protections for USG-produced works that have no copyright within the US.
>> 
>> Thanks,
>> Cem Karan
>> 
>>> -Original Message-
>>> From: License-discuss [mailto:license-discuss-boun...@opensource.org 
>>> ] On Behalf Of Maarten 
>>> Zeinstra
>>> Sent: Monday, August 01, 2016 4:36 AM
>>> To: license-discuss@opensource.org 
>>> Cc: lro...@rosenlaw.com 
>>> Subject: Re: [License-discuss] [Non-DoD Source] Re: US Army Research 
>>> Laboratory Open Source License proposal
>>> 
>>> All active links contained in this email were disabled. Please verify the 
>>> identity of the sender, and confirm the authenticity of all links
>>> contained within the message prior to copying and pasting the address to a 
>>> Web browser.
>>> 
>>> 
>>> __

Re: [License-discuss] US Army Research Laboratory Open Source License proposal

[Christopher Sean Morrison]

> I have personally, on occasion, considered filing a Freedom of Information 
> Act request for useful government code to see if that works to pry free 
> software from government hands. I never did that. The U.S. government has 
> almost always proven to be very generous without demands.

Please do, this issue needs to be pressed!  Doesn’t hurt to file a FOIA.

As far as I know, the answer as to whether software is considered an “agency 
record” subject to FOIA requests depends on the nature of the specific software 
and (unfortunately) the agency involved.  Last survey, approximately 50% of 
agencies felt software did not constitute a record, that most software is 
merely a tool for generating or processing records.  Some agencies have and do 
deliver despite holding a position that they are not required to do so.  Others 
feel that even as records, they fall under FOIA exemption clause 5 U.S.C. § 
552(c)(2) — namely that software solely pertains to the internal practices of 
an agency.

DoD is split.  Air Force holds that most software is a record (save for 
classified, T&E, covered-by-statute, or otherwise clearly exempt codes — DoD 
Reg 5400.7).  Navy vaguely concurs (SECNAV 5720.42F).  Army disagrees saying 
they do not consider most software to be a record (AR 25-55).

Much longer discussion:
https://www.justice.gov/oip/blog/foia-update-department-justice-report-electronic-record-foia-issues-part-ii

Also relevant:
https://www.justice.gov/sites/default/files/oip/legacy/2014/07/23/procedural-requirements_0.pdf

Several cases have gone to court making determinations swinging both ways 
(e.g., Gilmore v DOE: software not a record; Cleary, Gottlieb, Steen & Hamilton 
v DHHS: software is a record).  As such, “it depends."

Cheers!
Sean

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] open source licenses addressing malicious derivatives

[Christopher Sean Morrison]

Hi Henrik,

Thanks for the inputs.  I have been trying to make the case that trademark is 
adequate to address injunctive relief needs, but needed to survey the landscape 
of alternative possibilities (and their downsides).  As it is, the best 
defensive argument is looking to be license compatibility.

As far as I know, there are few OSI licenses not based on copyright (e.g., NOSA 
and the new FPL).  For Gov’t authors lacking US copyright protection, the 
question may end up being whether one of the existing is adequate or whether a 
new one must be drafted for OSI consideration.  For major codes needing 
indemnification protection, that minority could rely on trademark.

Cheers!
Sean


> On Jun 23, 2016, at 2:27 PM, Henrik Ingo  wrote:
> 
> Hi Christopher
> 
> You might want to read up on Mozilla for this topic. They run an unusually 
> thight trademark enforcement regime, precisely for this reason. Basically, 
> the source code is open source, but you cannot leave any user visible traces 
> of their trademark if you add even the smallest change.
> 
> Red Hat Enterprise Linux has a similarly thight trademark policy for 
> commercial reasons. You can copy it, but trademark must be removed. (So for 
> example, even in documentation, CentOS might refer pseudonymously to 
> "upstream vendor".)
> 
> In short, trademark is commonly used for this purpose, while licensing not so 
> much. Since trademark rights are quite independent of copyrights, this is 
> also GPL, etc... compatible, since there are no restrictions on the code, 
> you're just protecting your name and reputation.
> 
> henrik
> 
> On Wed, Jun 22, 2016 at 11:40 PM, Christopher Sean Morrison  <mailto:brl...@mac.com>> wrote:
> Is there any OSI-approved license that provides injunctive relief to an 
> original author in the situation of a bad actor creating a damaging 
> derivative?  To figure this out, I’ve been researching and trying to sort out:
> 
> 1) which existing OSI-approved licenses impose derivative requirements (e.g., 
> such that others must rename, that changes must be itemized, etc) and,
> 
> 2) whether such a requirement makes the license de facto 
> GPL/LGPL-incompatible?
> 
> For #1, I know CDDL has a required notice of authorship of modifications but 
> didn’t see anything else at least amongst the popular licenses.  I know that 
> license+trademark protection is the primary method for several notable open 
> source products (e.g., Firefox), but getting an injunction solely on failing 
> to announce modifications seems weak. 
> 
> I think the answer to #2 is “probably”, as anything that would hold up in 
> court would likely be an additional requirement, forbidden by the GNUs, but 
> would appreciate any insights.
> 
> The backdrop for this is an author reasonably going to court and obtaining 
> injunctive relief should some bad actor distribute a derivative that was 
> specifically designed to cause some surreptitious harm to the original 
> author.  Not just a hypothetical case.
> 
> Consider governmental actors where the outcome is political or newsworthy in 
> nature.  State Agency embraces open source, releases “State Agency's Super 
> Something Yellow”.  Bad actor modifies and gets a bad SASSY into the 
> marketplace.  Is there anything outside of trademark registration that would 
> help State Agency save face and/or get injunctive relief more easily?
> 
> Cheers!
> Sean
> 
> 
> ___
> License-discuss mailing list
> License-discuss@opensource.org <mailto:License-discuss@opensource.org>
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss 
> <https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss>
> 
> 
> 
> 
> -- 
> henrik.i...@avoinelama.fi <mailto:henrik.i...@avoinelama.fi>
> +358-40-5697354skype: henrik.ingoirc: hingo
> www.openlife.cc <http://www.openlife.cc/>
> 
> My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7 
> <http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7>___
> License-discuss mailing list
> License-discuss@opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] open source licenses addressing malicious derivatives

[Christopher Sean Morrison]

Hi Charles,


Thanks for the response and apologies in advance on the html-encoding; 
responding from a web client that doesn't let me recode the message.


Judges are likely to support reasonable contractual terms, but they will 
evaluate the specific circumstances at hand and have no obligation to blindly 
agree that something-or-other causes irreparable harm just because a contract 
says that it does:


The injunction request would stem from someone not adhering to the license / 
agreement terms, regardless of whether it is causing harm (though it's probably 
easy to argue that someone not conforming with reasonable terms is causing de 
facto harm).



1) which existing OSI-approved licenses impose derivative requirements (e.g., 
such that others must rename, that changes must be itemized, etc) and,

The old BSD license and the zlib license also have mandatory attribution 
clauses.


Failing to provide attribution isn't the issue.  It's negative association:  
changes made that the original author does not want to have associated with 
them.

 


Indeed. Beyond that, requiring modified versions to have changes be clearly 
identified is reasonable and compatible with the OSD. Requiring changes to be 
announced or made available to the original authors would violate the OSD.

One of the goals is to allow people to modify software to suit themselves. 
Unless they redistribute the changed versions to external parties, people 
should have the right to make private changes.



Absolutely.  How to enable and preserve that freedom without negatively 
affecting the original author.



Releasing software under an Open Source license means that the original author 
cannot prevent someone from changing that software, even in ways that the 
original author does not like. This is intentional.


Yes, unquestionably.


Now, if a bad actor does something against the law-- anything from harrassment, 
wrongful removal of copyright statements, or explicit violations of the 
Computer Fraud and Abuse Act-- then the author would have valid grounds for 
requesting damages and/or injunctive relief against the wrongful conduct.



Consider a case that is not necessarily against the law but still damaging 
(probably politically) in nature.


Maybe I take your software and change the splash screen to a tabloidesque 
picture of Jesus hugging Muhammad holding a pride flag while sitting on a 
Balrog's lap and I redistribute.  Maybe I even get my version accepted into the 
Google Play Store and it makes news headlines.  OSD says I have that right, I 
do it in a way that I'm not in violation of any terms of service -- but the 
question at hand is what measures can you as an original author put in place to 
not make it seem to others like you made that derivative?



I can trademark the product so you at least have to change the name.  CDDL 
would require me to itemize what I changed.  I believe I've seen bsd-style 
licensing from NIST that essentially says others are forbidden from using their 
name and/or logo in any way.



Are there any methods beyond trademarking that would be LGPL/GPL compatible?



The desired effect is disassociation so that if a bad actor does comply, it's 
clearly not harmful to the original author.  If they do not comply, injunctive 
relief should be trivial.


Cheers!

Sean


___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

[License-discuss] open source licenses addressing malicious derivatives

[Christopher Sean Morrison]

Is there any OSI-approved license that provides injunctive relief to an 
original author in the situation of a bad actor creating a damaging derivative? 
 To figure this out, I’ve been researching and trying to sort out:

1) which existing OSI-approved licenses impose derivative requirements (e.g., 
such that others must rename, that changes must be itemized, etc) and,

2) whether such a requirement makes the license de facto GPL/LGPL-incompatible?

For #1, I know CDDL has a required notice of authorship of modifications but 
didn’t see anything else at least amongst the popular licenses.  I know that 
license+trademark protection is the primary method for several notable open 
source products (e.g., Firefox), but getting an injunction solely on failing to 
announce modifications seems weak. 

I think the answer to #2 is “probably”, as anything that would hold up in court 
would likely be an additional requirement, forbidden by the GNUs, but would 
appreciate any insights.

The backdrop for this is an author reasonably going to court and obtaining 
injunctive relief should some bad actor distribute a derivative that was 
specifically designed to cause some surreptitious harm to the original author.  
Not just a hypothetical case.

Consider governmental actors where the outcome is political or newsworthy in 
nature.  State Agency embraces open source, releases “State Agency's Super 
Something Yellow”.  Bad actor modifies and gets a bad SASSY into the 
marketplace.  Is there anything outside of trademark registration that would 
help State Agency save face and/or get injunctive relief more easily?

Cheers!
Sean

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss