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

2017-11-08 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
Yes, but that's because US Federal Government works generally don't have 
copyright attached within the US, so CC0 was the best option.  That may not be 
the case here.

Thanks,
Cem Karan

---
Other than quoted laws, regulations or officially published policies, the views 
expressed herein are not intended to be used as an authoritative state of the 
law nor do they reflect official positions of the U.S. Army, Department of 
Defense or U.S. Government.


> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Tzeng, Nigel H.
> Sent: Tuesday, November 07, 2017 1:39 PM
> To: license-discuss@opensource.org
> Subject: [Non-DoD Source] Re: [License-discuss] I've been asked to license my 
> open source project CC0
> 
> 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.
> 
> 
> 
> 
> 
> 
> 
> CC0 is accepted as open source by the federal government in the Federal 
> Source Code Policy.
> 
> 
> 
> Caution-https://code.gov/#/policy-guide/docs/overview/introduction
> 
> Caution-https://github.com/GSA/code-gov-web/blob/master/LICENSE.md < 
> Caution-https://github.com/GSA/code-gov-
> web/blob/master/LICENSE.md >
> 
> 
> 
> 
> 
> From:License-discuss  on behalf of 
> Christopher Sean Morrison 
> Reply-To: License Discuss 
> Date: Tuesday, November 7, 2017 at 1:33 PM
> To: License Discuss 
> Subject: Re: [License-discuss] I've been asked to license my open source 
> project CC0
> 
> 
> 
> 
> 
> 
> On Nov 7, 2017, at 12:09 PM, Shahar Or  Caution-mailto:mightyiamprese...@gmail.com > > 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.
> 
> 
> 
> 
> 
>   Caution-https://github.com/mightyiam/shields-badge-data/issues/28 < 
> Caution-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
> 
> 



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] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and the US Government

2017-09-27 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Karan, Cem F CIV USARMY RDECOM ARL (US)
> Sent: Monday, August 28, 2017 12:00 PM
> To: Richard Fontana <font...@sharpeleven.org>
> Cc: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and 
> the US Government
>
> > -Original Message-
> > From: Richard Fontana [Caution-mailto:font...@sharpeleven.org]
> > Sent: Monday, August 28, 2017 11:39 AM
> > To: Karan, Cem F CIV USARMY RDECOM ARL (US) <cem.f.karan@mail.mil>
> > Cc: license-discuss@opensource.org
> > Subject: [Non-DoD Source] Re: NOSA 2.0, Copyfraud and the US
> > Government
> >
> > On Mon, Aug 28, 2017 at 02:18:10PM +, Karan, Cem F CIV USARMY
> > RDECOM ARL
> > (US) wrote:
> > > 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 been kind enough to dig up the exact
> > > statutes and give some clearer legal reasoning on what the issues
> > > are.  It basically boils down to two issues; first, there is
> > > question of severability
> > > (Caution-Caution-https://en.wikipedia.org/wiki/Severability) which
> > > I've touched on before, and the second has to do with copyfraud
> > > (Caution-Caution-https://en.wikipedia.org/wiki/Copyfraud).
> > > Copyfraud is defined within 17 U.S.C. 506, section (c)
> > > (Caution-Caution-https://www.gpo.gov/fdsys/pkg/USCODE-2010-title17/html/USCODE-2010-title17-chap5-sec506.htm).
> > > I've copied out the relevant language below; the commentary within
> > > the brackets is from ARL's lawyer:
> > >
> > > """
> > > (c) Fraudulent Copyright Notice.-
> > > Any person who, with fraudulent intent, places on any article a
> > > notice of copyright or words of the same purport that such person
> > > knows to be false, or who, with fraudulent intent, publicly
> > > distributes or imports for public distribution any article bearing
> > > such notice or words that such person knows to be false, shall be fined 
> > > not more than $2,500.
> > > [Note - Any software pushed out under Open Source would not have a
> > > notice of copyright affixed to the software. However, would software
> > > pushed out under an Open Source license that assumes the existence
> > > of copyright be considered tantamount to a notice of copyright and
> > > therefore an actionable fraud under this section?  Don't know.] """
> > >
> > > I know that there were questions at one time about the need for
> > > special licenses/agreements like NOSA 2.0, but this is one of those
> > > potential problems.  Copyright-based licenses are great for works
> > > that have copyright attached, but they may be problematic for works
> > > that don't have copyright attached.
> >
> > As has been pointed out before, I think, in software (including but
> > not limited to open source) copyright notices are commonly juxtaposed
> > with material that is clearly or likely not subject to copyright.
> >
> > Anyway, the theoretical risk here could be eliminated in lots of ways,
> > it seems to me (even without getting into what would be required to
> > show 'fraudulent intent'). For example, the US government could
> > include a copyright and license notice like the following:
> >
> >   The following material may not be subject to copyright in the United
> >   States under 17 U.S.C. 105. To the extent it is subject to
> >   copyright, it is released under the following open source license:
> > [...]
> >
> > There's also the approach that is seen in
> > Caution-Caution-https://github.com/deptofdefense/code.mil/blob/master/Proposal/INTENT.md.
> >
> > > So, given that we had come up with the idea of using two licenses in
> > > projects
> > > (CC0 for portions of a work that don't have copyright, and an
> > > OSI-approved license for portions of a work that do have copyright
> > > attached), why should OSI care?  The problem is that CC0 is still
> > > not OSI-approved (at least, it isn't on the list at
> > > Caution-Caution-https://opensource.org/licenses/alphabetical).  That
> > > means that the Government could be putting out works that are in
> > > some kind of zombie-like state, half-O

Re: [License-discuss] [Non-DoD Source] Re: (no subject)

2017-09-07 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Tzeng, Nigel H.
> Sent: Thursday, September 07, 2017 12:10 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: (no subject)
> 
> Cem,
> 
> I think I’ve mentioned this in the past but GOSS needs not be bazaar style 
> open development.  Cathedral development that simply open
> sources the resulting product still has tremendous value to the community.
> 
> From that perspective CLAs, and dealing with external contributions are a 
> non-issue because there aren’t any and open sourcing is much
> lower risk.  All contributions are done by USG employees or contractors.  All 
> the project looks at are JIRA issues and determines if any
> warrant any internal action.
> 
> Regards,
> 
> Nigel

I see your point with cathedral-style development, but I think that 
bazaar-style development results in far more progress in a shorter time frame 
and at lower cost.  In addition, the Government has done cathedral-style 
development for a while now, and (in my opinion), it is time for it to move 
forwards towards the bazaar.  We're not yet at the point that we can just let 
go of everything and avoid CLAs altogether, but there may come a point in time 
when we can.  At least, I hope that time will come.

Thanks,
Cem Karan


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] [Non-DoD Source] Re: (no subject)

2017-09-05 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of John Cowan
> Sent: Tuesday, September 05, 2017 11:28 AM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: (no subject)
>
>
> On Tue, Sep 5, 2017 at 9:12 AM, Karan, Cem F CIV USARMY RDECOM ARL (US) 
> <cem.f.karan@mail.mil < Caution-
> mailto:cem.f.karan@mail.mil > > wrote:
>
>
>
>   The issue is that
>   'voluntary' doesn't mean the same thing as 'gratuitous'; I work for the
>   Government on a voluntary, but not gratuitous basis.
>
>
> I certainly hope that nobody in the U.S. works for the Government or anyone 
> else on a non-voluntary basis, "except as a punishment for
> crime whereof the party shall have been duly convicted".
>
>
>
>   If I, as a Government
>   employee, accept work from a volunteer without a well-defined contract 
> in
>   place regarding payment, there is a chance that someone could send 
> Congress 
> a
>   bill for their contributions, and I could be sent to jail for having 
> committed
>   funds I don't have.
>
>
>
> Though nobody has ever been prosecuted, much less sentenced, under the ADA.
> In any case, anyone can send a bill to Congress for any reason: whether it 
> gets paid is another story.  Francis Hopkinson sent a such a bill
> for designing the American flag, asking to be paid a "Quarter Cask of the 
> Public Wine", but Congress denied it on the grounds that
> Hopkinson was already a paid member of Congress at the time.

I agree, but there have been administrative punishments for violating it. 
Moreover, just because no-one has yet been sent to jail for violating the ADA 
doesn't mean that no-one ever will.

> --
> John Cowan  Caution-http://vrici.lojban.org/~cowan < 
> Caution-http://vrici.lojban.org/~cowan > co...@ccil.org < Caution-
> mailto:co...@ccil.org >
> Linguistics is arguably the most hotly contested property in the academic 
> realm. It is soaked with the blood of poets, theologians,
> philosophers, philologists, psychologists, biologists and neurologists, 
> along with whatever blood can be got out of grammarians. - Russ
> Rymer

Thanks,
Cem Karan


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] [Non-DoD Source] Re: (no subject)

2017-09-05 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Ben Hilburn
> Sent: Friday, September 01, 2017 2:06 PM
> To: license-discuss@opensource.org
> Subject: [Non-DoD Source] Re: [License-discuss] (no subject)
>
> Hi all -
>
> I figured I would throw in my thoughts for this discussion. IANAL and all of 
> the usual disclaimers. My expertise, as it pertains to this
> thread, is really in the building & sustainment of F/OSS communities and 
> projects, albeit outside of the government space.
>
>
> On Fri, Sep 1, 2017 at 11:13 AM, Karan, Cem F CIV USARMY RDECOM ARL (US) 
> <cem.f.karan@mail.mil < Caution-
> mailto:cem.f.karan@mail.mil > > wrote:
>
>
>   > I'm now encountering a slightly different situation in government, is 
> there a way to ensure modifications and fixes are made
> available to
>   > the originator in a limited distribution scenario? Something like a 
> limited distribution GPL, but unlike before, there would be no
> non-
>   > government contribution's copyright to piggyback off of.
>
>   If this is government-only, then it is possible to use various contract 
> mechanisms to enforce what you want.  ARL has done this
> kind of thing for a long time now, and can share what we do with you 
> directly (contact me off list).
>
>
>
>
> In my experience, contracts are tremendous burden, both for individuals and 
> organizations, and pose a significant barrier to both adoption
> and upstreaming. As an FSF maintainer of a large GNU project, I can tell you 
> that even the FSF CLA causes significant issue for many
> groups, and outright inhibits growth of the developer community. I can't 
> speak to how burdensome it is to get contracts signed within a
> government agency, but I have to imagine it is still burdensome. And 
> requiring a contract for not just upstreaming, but adoption, in my
> opinion would cripple all but the largest projects.
>
> Related - If you haven't yet, I highly recommend reading these two articles:
> Caution-https://opensource.com/law/11/7/trouble-harmony-part-1 < 
> Caution-https://opensource.com/law/11/7/trouble-harmony-part-1
> > Caution-https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/ < 
> > Caution-https://sfconservancy.org/blog/2014/jun/09/do-not-
> need-cla/ >
>
>
> Have you seen something different at ARL? How have you worked things to be 
> successful with your F/OSS projects and external groups?
> I'm really interested to learn more about your approach and the results 
> you've seen.
>
<>
> Cheers,
> Ben

There are a number issues at work here.  First, since ARL is part of the 
Government, we're governed by the Anti-deficiency Act 
(https://en.wikipedia.org/wiki/Antideficiency_Act).  The issue is that 
'voluntary' doesn't mean the same thing as 'gratuitous'; I work for the 
Government on a voluntary, but not gratuitous basis.  If I, as a Government 
employee, accept work from a volunteer without a well-defined contract in 
place regarding payment, there is a chance that someone could send Congress a 
bill for their contributions, and I could be sent to jail for having committed 
funds I don't have.  ARL has a CLA that covers this particular issue for this 
exact reason.

Second, there is the question of liability and warranty; in theory, the 
Government can hold a contributor liable for their contribution, and demand 
support for it, even if the contribution was gratuitous.  I suspect that most 
contributions are going to be done on an 'as-is' basis, with no offer of 
support.  That is made explicit in ARL's CLA, protecting the contributor from 
the Government.

Third, there are the usual IP rights declarations that need to be fully 
spelled out.

I suspect that in 99.% of the contributions that the Government receives, 
none of this will be a problem.  However, the Government is a very large 
entity, which means that the Law of Truly Large Numbers 
(https://en.wikipedia.org/wiki/Law_of_truly_large_numbers) applies. 
Basically, since the Government is a very large entity, and since under 
Federal Source Code Policy it is dedicated to trying to make 20% of all of its 
custom written code be Open Source 
(https://code.gov/#/policy-guide/docs/overview/introduction), there are going 
to be a very, very large number of external contributions being made to 
Government projects.  Given this, even if there is less than a 0.0001% 
probability that someone will sue over a particular contribution, it is almost 
certain that there will be a lawsuit over something at some point in time.  To 
avoid being sued, the Government needs to take steps to protect itself, and 
CLAs are one part of that.

This is also important for Open Source in genera

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

2017-09-05 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of John Cowan
> Sent: Friday, September 01, 2017 1:22 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and 
> the US Government
> 
> 
> On Fri, Sep 1, 2017 at 10:44 AM, Karan, Cem F CIV USARMY RDECOM ARL (US) 
> <cem.f.karan@mail.mil < Caution-
> mailto:cem.f.karan@mail.mil > > wrote:
> 
> 
>   Wait... what??? You mean the copyright goes on until the next two world 
> wars occur? How do they define a world war?  What if
> we luck out and no world wars occur?
> 
> 
> 
> No, it's that the expiration of copyright was retroactively tolled by 
> specific French legislation (one for WWI, one for WWII) for the time
> that publication in France was under military censorship, preventing French 
> authors from fully exploiting their commercial rights.
> Presumably if France was occupied again, a similar law would be passed when 
> the occupation was lifted.  The status of these increases
> under the current life + 70 years regime is not very clear, since that added 
> 20 years and the maximum extension was only 15 years.
> 
> In addition, authors who are "mort pour la France" (either as soldiers or as 
> civilians killed in war) are granted an additional 30 years of
> copyright (thus life + 100) in compensation for whatever works they did not 
> get to create.  There are only about 35 creators in this
> position officially, but new ones could in principle be recognized at any 
> time.

OK, that makes a lot more sense.  Thanks!

> 
>   Just to double check, droit d’auteur is the equivalent of moral rights, 
> correct?
> 
> 
> 
> Yes, but it generally extends to all types of works.
> 
> --
> John Cowan  Caution-http://vrici.lojban.org/~cowan < 
> Caution-http://vrici.lojban.org/~cowan > co...@ccil.org < Caution-
> mailto:co...@ccil.org >
> Verbogeny is one of the pleasurettes of a creatific thinkerizer.
> --Peter da Silva



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] [Non-DoD Source] Re: (no subject)

2017-09-01 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Tom Bereknyei
> Sent: Friday, September 01, 2017 9:48 AM
> To: license-discuss@opensource.org
> Subject: [Non-DoD Source] Re: [License-discuss] (no subject)
> 
> Cem,
> 
> Yes, only in the case of fully public domain do our approaches differ. Our 
> view was that a project that never had a contribution from a
> non-federal entity would likely not reach a critical mass of adoption anyway. 
> This isn't perfect, but the best we could come up with. I'm
> glad though that at least part of the problem has a clear path forward.

I think I see what you're trying to accomplish, but it could lead to issues 
transporting code across jurisdictions.  If it is possible for DDS to 'level 
the playing field' so that everyone is subject to the same terms for a 
particular piece of code, it may make it easier for downstream users to adopt.

> Anyone,
> 
> I'm now encountering a slightly different situation in government, is there a 
> way to ensure modifications and fixes are made available to
> the originator in a limited distribution scenario? Something like a limited 
> distribution GPL, but unlike before, there would be no non-
> government contribution's copyright to piggyback off of.

If this is government-only, then it is possible to use various contract 
mechanisms to enforce what you want.  ARL has done this kind of thing for a 
long time now, and can share what we do with you directly (contact me off list).

> Maj Tom Bereknyei
> Defense Digital Service
> t...@dds.mil < Caution-mailto:t...@dds.mil >
> (571) 225-1630 < tel:%28571%29%20225-1630 > ‬

Thanks,
Cem Karan


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] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and the US Government

2017-09-01 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Thorsten Glaser
> Sent: Friday, September 01, 2017 8:26 AM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and 
> the US Government
> 
> Karan, Cem F CIV USARMY RDECOM ARL (US) dixit:
> 
> >Does the EU define copyright and other IP rights for all member
> 
> Only guidelines that have to be implemented in national law.
> The various countries still differ, even in the duration of the protection 
> (France, for example, has an extra clause to extend protection of
> some works for the duration of the two world wars), but not much.

Wait... what??? You mean the copyright goes on until the next two world wars 
occur? How do they define a world war?  What if we luck out and no world wars 
occur?

> AIUI the UK copyright law is much closer to US law than to that of other EU 
> member countries which have a French/German- style droit d’auteur law.
> 
> bye,
> //mirabilo

Just to double check, droit d’auteur is the equivalent of moral rights, correct?

Thanks,
Cem Karan


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] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and the US Government

2017-09-01 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Thorsten Glaser
> Sent: Thursday, August 31, 2017 3:50 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and 
> the US Government
> 
> 
> Hi list,
> 
> during this discussion I re-read CC0 and came to the conclusion that it does 
> not license the work itself but the right to act in the stead of
> the author (e.g. issue licences on it). That’s interesting and allows for a 
> _lot_ of possibilities.
>

What possibilities?

> 
> Of course…
> 
> >Making CC0 + a patent release officially OSI-approved would solve a lot
> >of
> 
> … the explicit patent exclusion remains a problem, as there is not only no 
> licence on the work saying one gets permission to use it but also
> an explicit exclusion of patents from the grant.
> 
> But this helps with e.g. the question of sublicensing (both in the EU and USA 
> sense which apparently, another thing I learnt yesternight,
> differ from each other) and the question of what exactly a derivative of a 
> CC0 work needs to be put under.

Does the EU define copyright and other IP rights for all member states?  That 
is, are the IP rights exactly the same between France and Germany simply 
because they are both a part of the EU?  When Brexit happens, what then?

> JFYI, IANAL, etc.
> //mirabilos



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] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and the US Government

2017-08-31 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
nt's funding was dependent on releasing the software
> under a "open source license as defined by the Open Source Initiative or as 
> Free Software as defined by the Free Software Foundation."
> Perhaps if your organization is facing a similar situation and they are 
> looking for a external arbitrator of what counts as FOSS, they should
> consider looking at other lists of FOSS licenses. Creative Commons  is 
> listed as a "free software" license by the Free Software Foundation.
> So in that situation if they wanted to use CCO I would probably argue 1) you 
> can use public domain software in a "Open source" licensed
> under a OSI approved license, as DDS is asserting. And 2) CC0 is considered 
> "free software" by FSF.  (Caution-
> https://www.gnu.org/licenses/license-list.html#CC0 < 
> Caution-https://www.gnu.org/licenses/license-list.html#CC0 > )
>
> Not sure if reframing the issue in those terms is an option for your 
> organization.
>
> -Marc
>
> On Tue, Aug 29, 2017 at 4:45 PM Karan, Cem F CIV USARMY RDECOM ARL (US) 
> <cem.f.karan@mail.mil < Caution-
> mailto:cem.f.karan@mail.mil > > wrote:
>
>
>   > -Original Message-
>   > From: License-discuss 
> [Caution-mailto:license-discuss-boun...@opensource.org < 
> Caution-mailto:license-discuss-
> boun...@opensource.org > ] On
>   > Behalf Of Tzeng, Nigel H.
>   > Sent: Tuesday, August 29, 2017 2:32 PM
>   > To: license-discuss@opensource.org < 
> Caution-mailto:license-discuss@opensource.org >
>   > Subject: Re: [License-discuss] [Non-DoD Source] Re: NOSA 2.0, 
> Copyfraud 
> and
>   > the US Government
>   >
>   > CC has to submit CC0 according to tradition/rules. For them to 
> bother, 
> since
>   > they won't amend CC0 itself, probably there needs to be
>   > some assurance it will at least get a vote at the next board meeting, 
> if 
> not
>   > assurance it would pass.
>   >
>   > Neither seems likely.
>   >
>   > Easier to just to shrug their shoulders and ignore the whole OSI 
> approval
>   > thing.
>
>   Well, that's a pain.  In that case, unless NOSA 2.0 gets approved, I 
> suspect
>   that at least some Government code is going to be zombie code, partly 
> Open
>   Source and partly CC0.
>
>   Thanks,
>   Cem Karan
>   ___
>   License-discuss mailing list
>   License-discuss@opensource.org < 
> Caution-mailto:License-discuss@opensource.org >
> 
> Caution-https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss 
> < Caution-https://lists.opensource.org/cgi-
> bin/mailman/listinfo/license-discuss >
>



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] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and the US Government

2017-08-29 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Tzeng, Nigel H.
> Sent: Tuesday, August 29, 2017 2:32 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and 
> the US Government
>
> CC has to submit CC0 according to tradition/rules. For them to bother, since 
> they won't amend CC0 itself, probably there needs to be
> some assurance it will at least get a vote at the next board meeting, if not 
> assurance it would pass.
>
> Neither seems likely.
>
> Easier to just to shrug their shoulders and ignore the whole OSI approval 
> thing.

Well, that's a pain.  In that case, unless NOSA 2.0 gets approved, I suspect 
that at least some Government code is going to be zombie code, partly Open 
Source and partly CC0.

Thanks,
Cem Karan


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] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and the US Government

2017-08-29 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Tzeng, Nigel H.
> Sent: Tuesday, August 29, 2017 11:03 AM
> To: license-discuss@opensource.org
> Cc: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and 
> the US Government
>
> I think that given that the USG is already saying that CC0 is a valid Open 
> Source license for the purposes of open source release on
> Code.gov the CC0 train has already left the station without OSI approval.
>
> The FSF recommends it for public domain releases and states it is GPL 
> compatible.
>
> CC states it is suitable for software when a public domain software release 
> is desired.
>
> You guys can debate this all you like but it doesn't appear to me to matter 
> much any more.

Thank you Nigel!  Given all that, can we PLEASE have a vote on approving CC0 
as being Open Source, and add it to the approved list?

Thanks,
Cem Karan



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] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and the US Government

2017-08-29 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Chris Travers
> Sent: Tuesday, August 29, 2017 9:14 AM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and 
> the US Government
> 
> On Tue, Aug 29, 2017 at 2:59 PM, Karan, Cem F CIV USARMY RDECOM ARL
> (US) <cem.f.karan@mail.mil> wrote:
> >> -Original Message-
> >> From: License-discuss
> >> [Caution-mailto:license-discuss-boun...@opensource.org] On Behalf Of
> >> Thorsten Glaser
> >> Sent: Monday, August 28, 2017 4:33 PM
> >> To: Stephen Michael Kellat <smkel...@yahoo.com>
> >> Cc: license-discuss@opensource.org
> >> Subject: Re: [License-discuss] [Non-DoD Source] Re: NOSA 2.0,
> >> Copyfraud and the US Government
> >>
> >> Stephen Michael Kellat dixit:
> >>
> >> >them to fix this to be public domain globally is best done by
> >> >amending
> >>
> >> There’s no such thing as voluntarily releasing a work into the Public
> >> Domain in several countries of the world, so this is futile at best, worse 
> >> hamful.
> >>
> >>
> >> Karan, Cem F CIV USARMY RDECOM ARL (US) dixit:
> >>
> >> >> So, in the end, “we” need a copyright licence “period”.
> >> >
> >> >Not exactly.  This is where CC0 comes into play, at least here at
> >> >the
> >>
> >> Yes, that’d be a way to express the same thing *if* CC0 were
> >> sublicenseable. It currently sorta works, but…
> >>
> >> >even if the work could have copyright attached in Germany, people
> >> >there know that the work is under CC0. This covers the really hard
> >> >question of a US Government work being exported to Germany,
> >> >modified, and then re-exported back to the US. The goal (at least at
> >> >ARL) is to
> >>
> >> … this could be tricky.
> >>
> >> If it were sublicenseable, the thing exported back to the USA could
> >> be fully under a proper copyright licence as the work of the person who 
> >> created the modified work (assuming it passes threshold of
> originality, of course).
> >>
> >> But I’m assuming it’d also work with just CC0, except CC themselves
> >> asked for it to not be certified as Open Source due to problems with it (I 
> >> don’t know which ones exactly).
> >>
> >> >make sure that everyone world-wide knows what the terms are, and
> >> >that they are the same regardless of where you live, and where you
> >> >are
> >>
> >> This is never true.
> >>
> >> Under the Berne Convention, a work from country A is, in country B,
> >> subject to the same protection as a work from country B. That means for a 
> >> work originating in the USA, in Germany, only(!) German
> copy‐ right law applies. In France, only French law, etc.
> >>
> >> I kinda like Richard Fontana’s approach to state a proper Open Source 
> >> licence for where copyright law applies.
> >
> > I see your point, but CC0 is an attempt to even out the use cases as far 
> > possible.  Basically, a person in Germany should not have to
> wonder if they'll be sued for using a US Government work that is in the 
> public domain in the US.  CC0 answers that question as far as it is
> possible given the various jurisdictions around the world.
> 
> What about jurisdictions where moral rights cannot be legally waived?

Not really a concern; the issue is whether or not others can feel safe using 
some code that is under CC0.  Even if you have moral rights to the code, if you 
put it under CC0, then I know I have the right to use it.

Thanks,
Cem Karan



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] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and the US Government

2017-08-29 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Thorsten Glaser
> Sent: Monday, August 28, 2017 4:33 PM
> To: Stephen Michael Kellat <smkel...@yahoo.com>
> Cc: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and 
> the US Government
> 
> Stephen Michael Kellat dixit:
> 
> >them to fix this to be public domain globally is best done by amending
> 
> There’s no such thing as voluntarily releasing a work into the Public Domain 
> in several countries of the world, so this is futile at best,
> worse hamful.
> 
> 
> Karan, Cem F CIV USARMY RDECOM ARL (US) dixit:
> 
> >> So, in the end, “we” need a copyright licence “period”.
> >
> >Not exactly.  This is where CC0 comes into play, at least here at the
> 
> Yes, that’d be a way to express the same thing *if* CC0 were sublicenseable. 
> It currently sorta works, but…
> 
> >even if the work could have copyright attached in Germany, people there
> >know that the work is under CC0. This covers the really hard question
> >of a US Government work being exported to Germany, modified, and then
> >re-exported back to the US. The goal (at least at ARL) is to
> 
> … this could be tricky.
> 
> If it were sublicenseable, the thing exported back to the USA could be fully 
> under a proper copyright licence as the work of the person
> who created the modified work (assuming it passes threshold of originality, 
> of course).
> 
> But I’m assuming it’d also work with just CC0, except CC themselves asked for 
> it to not be certified as Open Source due to problems with
> it (I don’t know which ones exactly).
> 
> >make sure that everyone world-wide knows what the terms are, and that
> >they are the same regardless of where you live, and where you are
> 
> This is never true.
> 
> Under the Berne Convention, a work from country A is, in country B, subject 
> to the same protection as a work from country B. That means
> for a work originating in the USA, in Germany, only(!) German copy‐ right law 
> applies. In France, only French law, etc.
> 
> I kinda like Richard Fontana’s approach to state a proper Open Source licence 
> for where copyright law applies.

I see your point, but CC0 is an attempt to even out the use cases as far 
possible.  Basically, a person in Germany should not have to wonder if they'll 
be sued for using a US Government work that is in the public domain in the US.  
CC0 answers that question as far as it is possible given the various 
jurisdictions around the world.

Thanks,
Cem Karan



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] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and the US Government

2017-08-29 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
Since I'm a Federal employee, and since putting together an Open Source policy 
for the Army Research Laboratory is part of my job, I'm barred from directly 
lobbying Congress on this matter [1-3].  ARL's legal counsel have also told me 
that I'm not allowed to encourage or discourage anyone to lobby Congress on 
behalf of ARL.  As an outside group, OSI can do what it feels like.

Thanks,
Cem Karan

[1] https://ethics.od.nih.gov/topics/lobbying.htm
[2] https://www.ethics.usda.gov/rules/guides/lobbying.htm
[3] https://www.law.cornell.edu/uscode/text/18/1913

> -Original Message-
> From: Stephen Michael Kellat [mailto:smkel...@yahoo.com]
> Sent: Monday, August 28, 2017 12:35 PM
> To: license-discuss@opensource.org; Karan, Cem F CIV USARMY RDECOM ARL (US)
> <cem.f.karan@mail.mil>; Richard Fontana
> <font...@sharpeleven.org>
> Cc: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: NOSA 2.0, Copyfraud and
> the US Government
>
> 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.
>
> Stephen Michael Kellat
>
>
>
> On August 28, 2017 11:59:44 AM EDT, "Karan, Cem F CIV USARMY RDECOM ARL
> (US)" <cem.f.karan@mail.mil> wrote:
>
>
>
>-Original Message-
>From: Richard Fontana [Caution-mailto:font...@sharpeleven.org]
>Sent: Monday, August 28, 2017 11:39 AM
>To: Karan, Cem F CIV USARMY RDECOM ARL (US) 
> <cem.f.karan@mail.mil>
>Cc: license-discuss@opensource.org
>Subject: [Non-DoD Source] Re: NOSA 2.0, Copyfraud and the US 
> Government
>
>On Mon, Aug 28, 2017 at 02:18:10PM +, Karan, Cem F CIV 
> USARMY RDECOM
> ARL
>(US) wrote:
>
>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 been kind enough to dig up 
> the exact statutes
>and give some clearer legal reasoning on what the 
> issues are.  It
>basically boils down to two issues; first, there is 
> question of
>severability
>
> (Caution-Caution-https://en.wikipedia.org/wiki/Severability <
> Caution-https://en.wikipedia.org/wiki/Severability
> > ) which I've
>touched on before, and the second has to do with 
> copyfraud
>
> (Caution-Caution-https://en.wikipedia.org/wiki/Copyfraud <
> Caution-https://en.wikipedia.org/wiki/Copyfraud >
> ).
>Copyfraud is defined within 17 U.S.C. 506, section (c)
>
> (Caution-Caution-https://www.gpo.gov/fdsys/pkg/USCODE-2010-title17/html/USCODE-2010-title17-chap5-
> sec506.htm <
> Caution-https://www.gpo.gov/fdsys/pkg/USCODE-2010-title17/html/USCODE-2010-title17-chap5-sec506.htm
>  > ).
>I've copied out the relevant language below; the 
> commentary within the
>brackets is from ARL's lawyer:
>
>"""
>(c) Fraudulent Copyright Notice.-
>Any person who, with fraudulent intent, places on any 
> article a notice
>of copyright or words of the same purport that such 
> person knows to be
>false, or who, with fraudulent intent, publicly 
> distributes or imports
>for public distribution any article bearing such 
> notice or words that
>such person knows to be false, shall be fined not more 
> than $2,500.
>[Note - Any software pushed out under Open Source 
> would not have a
>notice of copyright affixed to the software. However, 
> would software
>pushed out under an Open Source license that assumes 
> the existence of
>copyright be considered tantamount to a notice of 
> copyright and
>therefore an actionable fraud under this section?  
> Don't know.] """
>
>I know that there we

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

2017-08-28 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: Richard Fontana [mailto:font...@sharpeleven.org]
> Sent: Monday, August 28, 2017 11:39 AM
> To: Karan, Cem F CIV USARMY RDECOM ARL (US) <cem.f.karan@mail.mil>
> Cc: license-discuss@opensource.org
> Subject: [Non-DoD Source] Re: NOSA 2.0, Copyfraud and the US Government
>
> On Mon, Aug 28, 2017 at 02:18:10PM +, Karan, Cem F CIV USARMY RDECOM ARL 
> (US) wrote:
> > 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 been kind enough to dig up the exact statutes
> > and give some clearer legal reasoning on what the issues are.  It
> > basically boils down to two issues; first, there is question of
> > severability
> > (Caution-https://en.wikipedia.org/wiki/Severability) which I've
> > touched on before, and the second has to do with copyfraud 
> > (Caution-https://en.wikipedia.org/wiki/Copyfraud).
> > Copyfraud is defined within 17 U.S.C. 506, section (c)
> > (Caution-https://www.gpo.gov/fdsys/pkg/USCODE-2010-title17/html/USCODE-2010-title17-chap5-sec506.htm).
> > I've copied out the relevant language below; the commentary within the
> > brackets is from ARL's lawyer:
> >
> > """
> > (c) Fraudulent Copyright Notice.-
> > Any person who, with fraudulent intent, places on any article a notice
> > of copyright or words of the same purport that such person knows to be
> > false, or who, with fraudulent intent, publicly distributes or imports
> > for public distribution any article bearing such notice or words that
> > such person knows to be false, shall be fined not more than $2,500.
> > [Note - Any software pushed out under Open Source would not have a
> > notice of copyright affixed to the software. However, would software
> > pushed out under an Open Source license that assumes the existence of
> > copyright be considered tantamount to a notice of copyright and
> > therefore an actionable fraud under this section?  Don't know.] """
> >
> > I know that there were questions at one time about the need for
> > special licenses/agreements like NOSA 2.0, but this is one of those
> > potential problems.  Copyright-based licenses are great for works that
> > have copyright attached, but they may be problematic for works that
> > don't have copyright attached.
>
> As has been pointed out before, I think, in software (including but not 
> limited to open source) copyright notices are commonly juxtaposed
> with material that is clearly or likely not subject to copyright.
>
> Anyway, the theoretical risk here could be eliminated in lots of ways, it 
> seems to me (even without getting into what would be required to
> show 'fraudulent intent'). For example, the US government could include a 
> copyright and license notice like the following:
>
>   The following material may not be subject to copyright in the United
>   States under 17 U.S.C. 105. To the extent it is subject to
>   copyright, it is released under the following open source license: [...]
>
> There's also the approach that is seen in 
> Caution-https://github.com/deptofdefense/code.mil/blob/master/Proposal/INTENT.md.
>
> > So, given that we had come up with the idea of using two licenses in
> > projects
> > (CC0 for portions of a work that don't have copyright, and an
> > OSI-approved license for portions of a work that do have copyright
> > attached), why should OSI care?  The problem is that CC0 is still not
> > OSI-approved (at least, it isn't on the list at
> > Caution-https://opensource.org/licenses/alphabetical).  That means
> > that the Government could be putting out works that are in some kind
> > of zombie-like state, half-Open Source, and half not.  If OSI approved
> > CC0 as being an Open Source license, or if NOSA 2.0 was approved, then the 
> > problems could be fixed.  So, where are we in either case?
>
> As I've pointed out before, CC0 itself does not eliminate the problem your 
> colleagues say they are concerned about, because CC0 assumes
> copyright ownership. If they sincerely think it's dangerous to use the MIT 
> license then they should be consistent and say it's dangerous to
> use CC0 too.
>
> I think the use you are suggesting for use of CC0 is not actually how
> CC0 is meant to be used. CC0 is designed for the case where copyright 
> ownership is likely or plausibly present but the owner wishes to get
> as close as possible to waiving all of their rights. I think you are saying 
> you want CC

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

2017-08-28 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Thorsten Glaser
> Sent: Monday, August 28, 2017 10:32 AM
> To: license-discuss@opensource.org
> Subject: [Non-DoD Source] Re: [License-discuss] NOSA 2.0, Copyfraud and the 
> US Government
> 
> Karan, Cem F CIV USARMY RDECOM ARL (US) dixit:
> 
> >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.
> 
> So, in the end, “we” need a copyright licence “period”.

Not exactly.  This is where CC0 comes into play, at least here at the US Army 
Research Laboratory (ARL), and I hope in other parts of the US Government too.  
If the work doesn't have copyright attached within the US, it is licensed under 
CC0, which is a **world-wide** license.  Thus, even if the work could have 
copyright attached in Germany, people there know that the work is under CC0.  
This covers the really hard question of a US Government work being exported to 
Germany, modified, and then re-exported back to the US.  The goal (at least at 
ARL) is to make sure that everyone world-wide knows what the terms are, and 
that they are the same regardless of where you live, and where you are 
exporting your modifications to.

Does that make sense?

Thanks,
Cem Karan


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


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

2017-08-28 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
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 
been kind enough to dig up the exact statutes and give some clearer legal 
reasoning on what the issues are.  It basically boils down to two issues; 
first, there is question of severability 
(https://en.wikipedia.org/wiki/Severability) which I've touched on before, and 
the second has to do with copyfraud (https://en.wikipedia.org/wiki/Copyfraud). 
Copyfraud is defined within 17 U.S.C. 506, section (c) 
(https://www.gpo.gov/fdsys/pkg/USCODE-2010-title17/html/USCODE-2010-title17-chap5-sec506.htm).
 
I've copied out the relevant language below; the commentary within the 
brackets is from ARL's lawyer:

"""
(c) Fraudulent Copyright Notice.-
Any person who, with fraudulent intent, places on any article a notice of 
copyright or words of the same purport that such person knows to be false, or 
who, with fraudulent intent, publicly distributes or imports for public 
distribution any article bearing such notice or words that such person knows 
to be false, shall be fined not more than $2,500. [Note - Any software pushed 
out under Open Source would not have a notice of copyright affixed to the 
software. However, would software pushed out under an Open Source license that 
assumes the existence of copyright be considered tantamount to a notice of 
copyright and therefore an actionable fraud under this section?  Don't know.]
"""

I know that there were questions at one time about the need for special 
licenses/agreements like NOSA 2.0, but this is one of those potential 
problems.  Copyright-based licenses are great for works that have copyright 
attached, but they may be problematic for works that don't have copyright 
attached.

So, given that we had come up with the idea of using two licenses in projects 
(CC0 for portions of a work that don't have copyright, and an OSI-approved 
license for portions of a work that do have copyright attached), why should 
OSI care?  The problem is that CC0 is still not OSI-approved (at least, it 
isn't on the list at https://opensource.org/licenses/alphabetical).  That 
means that the Government could be putting out works that are in some kind of 
zombie-like state, half-Open Source, and half not.  If OSI approved CC0 as 
being an Open Source license, or if NOSA 2.0 was approved, then the problems 
could be fixed.  So, where are we in either case?

Thanks,
Cem Karan


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


[License-discuss] NOSA 2.0?

2017-08-11 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
ping

And to Richard Fontana... **PING**

Thanks,
Cem Karan


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


[License-discuss] NOSA 2.0?

2017-07-27 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
What is the current progress on the NOSA 2.0 license?  I just got out of a 
meeting with some NASA lawyers, and they want to know where it's going, and if 
it's stuck, why it's stuck.

Thanks,
Cem Karan


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] [Non-DoD Source] patents & interoperability

2017-05-16 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
International law is a difficult problem to solve, but one that, in my 
personal opinion, needs to be solved as far as we can reasonably do.  It would 
be embarrassing to have a project Open Sourced, only to have people in one 
jurisdiction unable to exercise their rights because of a mistake concerning 
patent rights.

Thanks,
Cem Karan

> -Original Message-
> From: Rajneesh N. Shetty [mailto:shettyrajne...@aol.com]
> Sent: Tuesday, May 16, 2017 9:46 AM
> To: Karan, Cem F CIV USARMY RDECOM ARL (US) <cem.f.karan@mail.mil>
> Cc: lro...@rosenlaw.com; Tzeng, Nigel H CTR (US) <nigel.tz...@jhuapl.edu>; 
> license-discuss@opensource.org
> Subject: [Non-DoD Source] patents & interoperability
>
> 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.
>
>
> 
>
>
>
> I found your email exchanges @ license-disc...@opensourc.org quite 
> interesting..& well-researched as well
>
> historical grants of most patents especially as it relates to vital 
> infrastructure, has always been dependent on "national interests" & rarely
> based on international interests..
>
> when a coupla' of my friends & myself wrote PC Paint sometime between 
> 1989-95, we hardly expected it to be as big as it is today. We
> guys led separate lives since Uni & now it's always about checking 
> interoperabilities & scope of projects & innovation, more than anything
> else
>
> Caution-www.getpaint.net
> Caution-www.distrowatch.com
>
>
>
> Rajneesh N. Shetty
> Weblogs :
> Caution-www.bolluru.blogspot.com
> Caution-www.rns-thoughts.blogspot.com
>
> Tel : (+61)4750-32-666
>
> Note : Please always reply to my email from this ID to : icpain...@gmail.com 
> < Caution-mailto:icpain...@gmail.com >
>
>  


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] [Non-DoD Source] Re: patent rights and the OSD

2017-03-28 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
e 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.
> 
> 
> 
> 
> 
> 
> Cem,
> 
> Larry's advice (tongue in cheek or not) isn't the issue for FedGov or ARL 
> policy. That I randomly picked an ARL patent that happens to
> illustrate the potential issue is simply lucky.
> 
> The issue is that someone in some other part of the government could have 
> released an open source implementation with a patent grant
> of Dr Chen's patent and deprived him (and ARL) of financial reward for his 
> work.
> 
> I'm sure there are some here who would simply shrug and say who cares...rent 
> seeking is evil anyway...but the FedGov policies regarding
> rewarding innovation is one aspect of attracting and keeping inventors in the 
> government as opposed to going to private industry.
> 
> ARL and the DoD has an even harder time than research universities when it 
> comes to the left hand not knowing what the right hand is
> doing. IMHO explicit patent grants provided by ARL in open source releases 
> should be limited to those generated by ARL itself unless ARL
> intends to insure it isn't giving away a patent created by an inventor in 
> another branch of the federal government.
> 
> 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.
> 
> Broad patent grant language in FOSS licenses/policies risks exactly that for 
> very large organizations and the cost to prevent that means it
> is far easier (and cheaper) to simply not open source.
> 
> I really implore you to revisit the ECL V2 patent language and the reasons 
> they didn't feel that vanilla Apache 2.0 was suitable for them
> when you (and the ARL lawyers and your OTT) are helping evolve the ARL open 
> source policy.
> 
> Nigel
> 
> Obligatory Disclaimer: speaking as an individual, the opinions expressed here 
> are my own and no one else's, etc.
> 
> From: Karan, Cem F CIV USARMY RDECOM ARL (US) <cem.f.karan@mail.mil < 
> Caution-mailto:cem.f.karan@mail.mil > >
> Date: Sunday, Mar 19, 2017, 6:42 AM
> To: lro...@rosenlaw.com <lro...@rosenlaw.com < 
> Caution-mailto:lro...@rosenlaw.com > >, license-discuss@opensource.org 
>  disc...@opensource.org < Caution-mailto:license-discuss@opensource.org > >
> Subject: Re: [License-discuss] [Non-DoD Source] Re: patent rights and the OSD
> 
> I was out Thursday and Friday, but... see attached Federal Register notice 
> regarding this particular patent.  I know that Larry was (mostly)
> pulling everyone's leg, but before anyone gets themselves into trouble, I 
> figured I should put the warning out there.
> 
> I'm not a lawyer, as far as I know this doesn't count as an official warning, 
> I'm not representing the US Government (or any other
> government) in this matter, etc., etc., etc.  I just personally don't want to 
> see anyone spend time on something and then get burned in the
> end.  Please don't shoot (or flame) the messenger.
> 
> Thanks,
> Cem Karan
> 
> > -Original Message-
> > From: License-discuss
> > [Caution-mailto:license-discuss-boun...@opensource.org <
> > Caution-mailto:license-discuss-boun...@opensource.org > ] On Behalf Of
> > Lawrence Rosen
> > Sent: Wednesday, March 08, 2017 3:07 PM
> > To: license-discuss@opensource.org
> > Cc: Lawrence Rosen <lro...@rosenlaw.com>
> > Subject: Re: [License-discuss] [Non-DoD Source] Re: patent rights and
> > the OSD
> >
> > 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.
> >
> >
> > 
> >
> >
> >
> >
> > Nigel Tzeng wrote:
> >
> > > Using US7460689B1 System and method of detecting, recognizing, and
> > > tracking moving targets as an example it could be useful to have
> > an open source copyright license to any USG developed MTI
> > implementation of US7460689B1 because the libraries and functions used to 
> > implement the patent could be reusable.
> >
> >
> >
> > Nigel, I am avoiding reading that patent because I have no time, but since 
> > you did read it I can ask you some questions:
> >
> >
> >
> > Is the patent already "reusable" for things other than "detectin

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

2017-03-20 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
Hi Nigel, you actually brought up a really good point, one that I didn't have a 
ready answer to.  I took it to ARL's lawyers, and we're putting together an 
answer, which I hope will be done by tomorrow.  If you haven't heard from me by 
Wednesday, ping me.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Tzeng, Nigel H.
> Sent: Sunday, March 19, 2017 7:43 AM
> To: license-discuss@opensource.org; lro...@rosenlaw.com
> Subject: Re: [License-discuss] [Non-DoD Source] Re: patent rights and the OSD
> 
> 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.
> 
> 
> 
> 
> 
> 
> Cem,
> 
> Larry's advice (tongue in cheek or not) isn't the issue for FedGov or ARL 
> policy. That I randomly picked an ARL patent that happens to
> illustrate the potential issue is simply lucky.
> 
> The issue is that someone in some other part of the government could have 
> released an open source implementation with a patent grant
> of Dr Chen's patent and deprived him (and ARL) of financial reward for his 
> work.
> 
> I'm sure there are some here who would simply shrug and say who cares...rent 
> seeking is evil anyway...but the FedGov policies regarding
> rewarding innovation is one aspect of attracting and keeping inventors in the 
> government as opposed to going to private industry.
> 
> ARL and the DoD has an even harder time than research universities when it 
> comes to the left hand not knowing what the right hand is
> doing. IMHO explicit patent grants provided by ARL in open source releases 
> should be limited to those generated by ARL itself unless ARL
> intends to insure it isn't giving away a patent created by an inventor in 
> another branch of the federal government.
> 
> 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.
> 
> Broad patent grant language in FOSS licenses/policies risks exactly that for 
> very large organizations and the cost to prevent that means it
> is far easier (and cheaper) to simply not open source.
> 
> I really implore you to revisit the ECL V2 patent language and the reasons 
> they didn't feel that vanilla Apache 2.0 was suitable for them
> when you (and the ARL lawyers and your OTT) are helping evolve the ARL open 
> source policy.
> 
> Nigel
> 
> Obligatory Disclaimer: speaking as an individual, the opinions expressed here 
> are my own and no one else's, etc.
> 
> From: Karan, Cem F CIV USARMY RDECOM ARL (US) <cem.f.karan@mail.mil < 
> Caution-mailto:cem.f.karan@mail.mil > >
> Date: Sunday, Mar 19, 2017, 6:42 AM
> To: lro...@rosenlaw.com <lro...@rosenlaw.com < 
> Caution-mailto:lro...@rosenlaw.com > >, license-discuss@opensource.org 
>  disc...@opensource.org < Caution-mailto:license-discuss@opensource.org > >
> Subject: Re: [License-discuss] [Non-DoD Source] Re: patent rights and the OSD
> 
> I was out Thursday and Friday, but... see attached Federal Register notice 
> regarding this particular patent.  I know that Larry was (mostly)
> pulling everyone's leg, but before anyone gets themselves into trouble, I 
> figured I should put the warning out there.
> 
> I'm not a lawyer, as far as I know this doesn't count as an official warning, 
> I'm not representing the US Government (or any other
> government) in this matter, etc., etc., etc.  I just personally don't want to 
> see anyone spend time on something and then get burned in the
> end.  Please don't shoot (or flame) the messenger.
> 
> Thanks,
> Cem Karan
> 
> > -Original Message-
> > From: License-discuss
> > [Caution-mailto:license-discuss-boun...@opensource.org <
> > Caution-mailto:license-discuss-boun...@opensource.org > ] On Behalf Of
> > Lawrence Rosen
> > Sent: Wednesday, March 08, 2017 3:07 PM
> > To: license-discuss@opensource.org
> > Cc: Lawrence Rosen <lro...@rosenlaw.com>
> > Subject: Re: [License-discuss] [Non-DoD Source] Re: patent rights and
> > the OSD
> >
> > 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] [Non-DoD Source] Re: Possible alternative was: Re: U.S. Army Research Laboratory Open Source License (ARL OSL) Version 0.4.1

2017-03-20 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of John Cowan
> Sent: Monday, March 20, 2017 10:05 AM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible alternative 
> was: Re: U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
>
> On Mon, Mar 20, 2017 at 8:39 AM, Karan, Cem F CIV USARMY RDECOM ARL (US) 
> <cem.f.karan@mail.mil < Caution-
> mailto:cem.f.karan@mail.mil > > wrote:
>
>
>   OK, thank you, I'll contact them and see what they think.
>
>
> Note that the DFSG #1-#9 are verbatim the same as OSD #1-#9, but the 
> interpretations may differ.  (#10 is separate and unrelated in the
> two definitions.)  Note also that debian-legal does not control what 
> actually gets into Debian; that decision is in the hands of the trusted
> committers.
>
> --
> John Cowan  Caution-http://vrici.lojban.org/~cowan < 
> Caution-http://vrici.lojban.org/~cowan > co...@ccil.org < Caution-
> mailto:co...@ccil.org >

I understand, and appreciate the concern.  I'm not worried about Debian 
including ARL code; I'm concerned about Debian being precluded from including 
code because of actions on ARL's part.  Basically, I want to make sure they 
have the option of using ARL code; we have to earn the privilege to be 
included in there. :)

Thanks,
Cem Karan



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] [Non-DoD Source] Re: Possible alternative was: Re: U.S. Army Research Laboratory Open Source License (ARL OSL) Version 0.4.1

2017-03-20 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
OK, thank you, I'll contact them and see what they think.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Marc Jones
> Sent: Thursday, March 16, 2017 4:31 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible alternative was: 
> Re: U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
> 
> 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.
> 
> 
> 
> 
> 
> 
> I also can't speak for Debian. But it is my understanding that Debian does 
> not rely on OSI for determining if a license is free. They use their
> own Debian Free Software Guidelines. (Although they are very similar.) 
> Someone at Debian maintains a FAQ on the DFSG [1]
> 
> Debian also has a Licensing page that is not exactly on point but suggests 
> that you might want to contact the Debian Legal Mailing list. [2]
> 
> Warm regards,
> 
> -Marc
> 
> [1] Caution-https://people.debian.org/~bap/dfsg-faq < 
> Caution-https://people.debian.org/~bap/dfsg-faq > [2] Caution-
> https://www.debian.org/legal/licenses/ < 
> Caution-https://www.debian.org/legal/licenses/ >
> 
> On Thu, Mar 16, 2017 at 3:32 PM Tom Callaway <tcall...@redhat.com < 
> Caution-mailto:tcall...@redhat.com > > wrote:
> 
> 
>       Can't speak for Debian, but Fedora will happily take software licensed 
> as you describe.
> 
>   On Mar 16, 2017 3:09 PM, "Karan, Cem F CIV USARMY RDECOM ARL (US)" 
> <cem.f.karan@mail.mil < Caution-
> mailto:cem.f.karan@mail.mil > > wrote:
> 
> 
>   I agree that the Government can release it as open source, but 
> as I understand it, not as Open Source.  The difference is
> whether or not the code will be accepted into various journals (Journal of 
> Open Source Software is one).  It also affects whether or not
> various distributions will accept the work (would Debian?  I honestly don't 
> know).
> 
>   And I'm not after plain vanilla CC0 code to be called Open 
> Source, I'm after the method I outlined earlier.  This side-steps
> the need to have CC0 put forth by the license steward (I hope!).  I know that 
> is splitting hairs, but at this point I'm tearing my hair out over
> this, and would like to put it to rest before I have to buy a wig.
> 
>   Thanks,
>   Cem Karan
> 
>   > -Original Message-
>   > From: License-discuss 
> [Caution-mailto:license-discuss-boun...@opensource.org < 
> Caution-mailto:license-discuss-
> boun...@opensource.org > ] On Behalf Of Tzeng, Nigel H.
>   > Sent: Thursday, March 16, 2017 2:48 PM
>   > To: license-discuss@opensource.org < 
> Caution-mailto:license-discuss@opensource.org >
>   > Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible 
> alternative was: Re: U.S. Army Research Laboratory Open
> Source License (ARL
>   > OSL) Version 0.4.1
>   >
>   > 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.
>   >
>   >
>   >
>   >
>   > 
>   >
>   > Cem,
>   >
>   > The USG does not need OSI’s approval to release code as open 
> source under CC0.  It has done so already on code.gov <
> Caution-http://code.gov > .  This includes the
>   > OPM, NASA, GSA, DOT, DOL, DOC and others. CC0 is compliant 
> with the Federal Source Code Policy for open source
> release.
>   >
>   > It is unlikely that you can push CC0 through license review 
> as you aren’t the license steward.  It is up to CC to resubmit
> CC0 for approval.
>   >
>   > Regards,
>   >
>   > Nigel
>   >
>   > On 3/16/17, 8:56 AM, "License-discuss on behalf of Karan, Cem 
> F CIV USARMY RDECOM ARL (US)"> boun...@opensource.org < 
> Caution-mailto:boun...@opensource.org >  on behalf of 
> cem.f

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

2017-03-17 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
I'd love to, but ARL's lawyers disagree with code.mil's interpretation, and 
neither the upper levels of the DoD nor the White House have given us an all 
clear to use copyright-based licenses on code that is in the public domain.  
(code.mil is not in ARL's chain of command, so we can't just salute and obey.  
And until someone we CAN salute and obey gives us the OK, we have to follow the 
more conservative approach).

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Richard Fontana
> Sent: Friday, March 17, 2017 4:56 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible alternative was: 
> Re: U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
> 
> 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.
> 
> 
> 
> 
> 
> 
> I would just encourage you to consider instead recommending the enlightened 
> approach being taken by your colleagues at
> github.com/deptofdefense/code.mil, which would be more consistent with the 
> ARL lawyers' apparent belief that some horrible disaster
> will occur if they put US published code under a copyright license. :)
> 
> 
> On Fri, Mar 17, 2017, at 04:47 PM, Karan, Cem F CIV USARMY RDECOM ARL
> (US) wrote:
> > That was what I was afraid of.  OK, in that case I'll make the
> > recommendation that ARL does what I was outlining before, and hope
> > that
> > CC0 will one day be considered Open Source as well.
> >
> > Thanks,
> > Cem Karan
> >
> > > -Original Message-
> > > From: License-discuss
> > > [Caution-mailto:license-discuss-boun...@opensource.org] On Behalf Of
> > > Richard Fontana
> > > Sent: Friday, March 17, 2017 11:18 AM
> > > To: license-discuss@opensource.org
> > > Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible
> > > alternative was: Re: U.S. Army Research Laboratory Open Source
> > > License (ARL
> > > OSL) Version 0.4.1
> > >
> > > 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.
> > >
> > >
> > >
> > >
> > > 
> > >
> > > I don't see how you could convince OSI of this in any way that would not 
> > > involve submission and approval of CC0.
> > >
> > >
> > > On Fri, Mar 17, 2017 at 12:32:26PM +, Karan, Cem F CIV USARMY RDECOM 
> > > ARL (US) wrote:
> > > > OK, so different groups have different opinions.  I'm glad Fedora
> > > > views CC0 as meeting the OSD definitions though.  I'd still like
> > > > to
> > > convince OSI that the route I outlined earlier should be considered
> > > to be Open Source; I think it'll make things easier for a lot of the 
> > > Government.
> > > >
> > > > Thanks,
> > > > Cem Karan
> > > >
> > > > > -Original Message-
> > > > > From: License-discuss
> > > > > [Caution-Caution-mailto:license-discuss-boun...@opensource.org]
> > > > > On Behalf Of Tom Callaway
> > > > > Sent: Thursday, March 16, 2017 8:46 PM
> > > > > To: license-discuss@opensource.org
> > > > > Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible
> > > > > alternative was: Re: U.S. Army Research Laboratory Open Source
> > > > > License (ARL
> > > > > OSL) Version 0.4.1
> > > > >
> > > > > 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.
> > > > >
> > > > >
> > > > > 
> > > > >
> > > > >
> > > > >
> > > > > I'd think the only ones who get to apply the "Open Source" label
> > > > > to licenses would be the OSI. Fedora's opinion is that CC-0 meets the 
> > > > > OSD.
> > > > >
> > > >

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

2017-03-17 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
You're probably right.  I don't **think** that there are any other journals 
that will turn down code if it doesn't come with an OSI-approved license; can 
anyone think of one?

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Tzeng, Nigel H.
> Sent: Friday, March 17, 2017 1:16 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible alternative was: 
> Re: U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
> 
> 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.
> 
> 
> 
> 
> 
> 
> Other than JOSS I still don’t see how it makes a big difference for the 
> Government.  And the ability to publish in JOSS seems like a rather
> secondary consideration…and I say that as a software developer in an academic 
> environment…
> 
> On 3/17/17, 8:32 AM, "License-discuss on behalf of Karan, Cem F CIV USARMY 
> RDECOM ARL (US)"  boun...@opensource.org on behalf of cem.f.karan@mail.mil> wrote:
> 
> OK, so different groups have different opinions.  I'm glad Fedora views 
> CC0 as meeting the OSD definitions though.  I'd still like to
> convince OSI that the route I outlined earlier should be considered to be 
> Open Source; I think it'll make things easier for a lot of the
> Government.
> 
> Thanks,
> Cem Karan
> 
> > -Original Message-
> > From: License-discuss 
> [Caution-mailto:license-discuss-boun...@opensource.org] On Behalf Of Tom 
> Callaway
> > Sent: Thursday, March 16, 2017 8:46 PM
> > To: license-discuss@opensource.org
> > Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible 
> alternative was: Re: U.S. Army Research Laboratory Open Source License
> (ARL
> > OSL) Version 0.4.1
> >
> > 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.
> >
> >
> > 
> >
>     >
> >
>     > I'd think the only ones who get to apply the "Open Source" label to 
> licenses would be the OSI. Fedora's opinion is that CC-0 meets the
> > OSD.
> >
> > On Mar 16, 2017 4:31 PM, "Karan, Cem F CIV USARMY RDECOM ARL (US)" 
> <cem.f.karan@mail.mil < Caution-
> > Caution-mailto:cem.f.karan@mail.mil > > wrote:
> >
> >
> > Cool!  Would Fedora/Red Hat consider it to be Open Source?
> >
> > Thanks,
> > Cem Karan
> >
> > > -Original Message-
> > > From: License-discuss 
> [Caution-Caution-mailto:license-discuss-boun...@opensource.org < 
> Caution-Caution-mailto:license-
> discuss-
> > boun...@opensource.org > ] On Behalf Of Tom Callaway
> > > Sent: Thursday, March 16, 2017 3:31 PM
> > > To: license-discuss@opensource.org < 
> Caution-Caution-mailto:license-discuss@opensource.org >
> > > Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible 
> alternative was: Re: U.S. Army Research Laboratory Open Source
> > License (ARL
> > > OSL) Version 0.4.1
> > >
> > > 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.
> > >
> > >
> > > 
> > >
> > >
> > >
> > > Can't speak for Debian, but Fedora will happily take software 
> licensed as you describe.
> > >
> > > On Mar 16, 2017 3:09 PM, "Karan, Cem F CIV USARMY RDECOM ARL 
> (US)" <cem.f.karan@mail.mil < Caution-
> > Caution-mailto:cem.f.karan@mail.mil >  < Caution-
> > > Caution-Caution-mailto:cem.f.karan@mail.mil < 
> Caution-Caution-mailto:cem.f.karan@mail.mil >  > > wrote:
> > 

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

2017-03-17 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
That was what I was afraid of.  OK, in that case I'll make the recommendation 
that ARL does what I was outlining before, and hope that CC0 will one day be 
considered Open Source as well.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Richard Fontana
> Sent: Friday, March 17, 2017 11:18 AM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible alternative was: 
> Re: U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
> 
> 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.
> 
> 
> 
> 
> 
> 
> I don't see how you could convince OSI of this in any way that would not 
> involve submission and approval of CC0.
> 
> 
> On Fri, Mar 17, 2017 at 12:32:26PM +, Karan, Cem F CIV USARMY RDECOM ARL 
> (US) wrote:
> > OK, so different groups have different opinions.  I'm glad Fedora views CC0 
> > as meeting the OSD definitions though.  I'd still like to
> convince OSI that the route I outlined earlier should be considered to be 
> Open Source; I think it'll make things easier for a lot of the
> Government.
> >
> > Thanks,
> > Cem Karan
> >
> > > -Original Message-
> > > From: License-discuss
> > > [Caution-mailto:license-discuss-boun...@opensource.org] On Behalf Of
> > > Tom Callaway
> > > Sent: Thursday, March 16, 2017 8:46 PM
> > > To: license-discuss@opensource.org
> > > Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible
> > > alternative was: Re: U.S. Army Research Laboratory Open Source
> > > License (ARL
> > > OSL) Version 0.4.1
> > >
> > > 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.
> > >
> > >
> > > ____
> > >
> > >
> > >
> > > I'd think the only ones who get to apply the "Open Source" label to
> > > licenses would be the OSI. Fedora's opinion is that CC-0 meets the OSD.
> > >
> > > On Mar 16, 2017 4:31 PM, "Karan, Cem F CIV USARMY RDECOM ARL (US)"
> > > <cem.f.karan@mail.mil < Caution- 
> > > Caution-mailto:cem.f.karan@mail.mil > > wrote:
> > >
> > >
> > >   Cool!  Would Fedora/Red Hat consider it to be Open Source?
> > >
> > >   Thanks,
> > >   Cem Karan
> > >
> > >   > -Original Message-
> > >   > From: License-discuss
> > > [Caution-Caution-mailto:license-discuss-boun...@opensource.org <
> > > Caution-Caution-mailto:license-discuss-
> > > boun...@opensource.org > ] On Behalf Of Tom Callaway
> > >   > Sent: Thursday, March 16, 2017 3:31 PM
> > >   > To: license-discuss@opensource.org < 
> > > Caution-Caution-mailto:license-discuss@opensource.org >
> > >   > Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible
> > > alternative was: Re: U.S. Army Research Laboratory Open Source License 
> > > (ARL
> > >   > OSL) Version 0.4.1
> > >   >
> > >   > 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.
> > >   >
> > >   >
> > >   > 
> > >   >
> > >   >
> > >   >
> > >   > Can't speak for Debian, but Fedora will happily take software 
> > > licensed as you describe.
> > >   >
> > >   > On Mar 16, 2017 3:09 PM, "Karan, Cem F CIV USARMY RDECOM ARL
> > > (US)" <cem.f.karan@mail.mil < Caution- 
> > > Caution-mailto:cem.f.karan@mail.mil >  < Caution-
> > >   > Caution-Caution-mailto:cem.f.karan@mail.mil < 
> > > Caution-Caution-mailto:cem.f.karan@mail.mil >  > > wrote:
> > >   >
> > >   >
> > >   >   I agree that the Government can release it as open source, but 
> > > as I unde

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

2017-03-17 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
OK, so different groups have different opinions.  I'm glad Fedora views CC0 as 
meeting the OSD definitions though.  I'd still like to convince OSI that the 
route I outlined earlier should be considered to be Open Source; I think it'll 
make things easier for a lot of the Government.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Tom Callaway
> Sent: Thursday, March 16, 2017 8:46 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible alternative was: 
> Re: U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
> 
> 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.
> 
> 
> 
> 
> 
> 
> I'd think the only ones who get to apply the "Open Source" label to licenses 
> would be the OSI. Fedora's opinion is that CC-0 meets the
> OSD.
> 
> On Mar 16, 2017 4:31 PM, "Karan, Cem F CIV USARMY RDECOM ARL (US)" 
> <cem.f.karan@mail.mil < Caution-
> mailto:cem.f.karan@mail.mil > > wrote:
> 
> 
>   Cool!  Would Fedora/Red Hat consider it to be Open Source?
> 
>   Thanks,
>   Cem Karan
> 
>   > -Original Message-
>   > From: License-discuss 
> [Caution-mailto:license-discuss-boun...@opensource.org < 
> Caution-mailto:license-discuss-
> boun...@opensource.org > ] On Behalf Of Tom Callaway
>   > Sent: Thursday, March 16, 2017 3:31 PM
>   > To: license-discuss@opensource.org < 
> Caution-mailto:license-discuss@opensource.org >
>   > Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible 
> alternative was: Re: U.S. Army Research Laboratory Open Source
> License (ARL
>   > OSL) Version 0.4.1
>   >
>   > 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.
>   >
>       >
>       > ________
>   >
>   >
>   >
>   > Can't speak for Debian, but Fedora will happily take software 
> licensed as you describe.
>   >
>   > On Mar 16, 2017 3:09 PM, "Karan, Cem F CIV USARMY RDECOM ARL (US)" 
> <cem.f.karan@mail.mil < Caution-
> mailto:cem.f.karan@mail.mil >  < Caution-
>   > Caution-mailto:cem.f.karan@mail.mil < 
> Caution-mailto:cem.f.karan@mail.mil >  > > wrote:
>   >
>   >
>   >   I agree that the Government can release it as open source, but 
> as I understand it, not as Open Source.  The difference is
> whether
>   > or not the code will be accepted into various journals (Journal of 
> Open Source Software is one).  It also affects whether or not
> various
>   > distributions will accept the work (would Debian?  I honestly don't 
> know).
>   >
>   >   And I'm not after plain vanilla CC0 code to be called Open 
> Source, I'm after the method I outlined earlier.  This side-steps the
> need
>   > to have CC0 put forth by the license steward (I hope!).  I know that 
> is splitting hairs, but at this point I'm tearing my hair out
> over this, and
>   > would like to put it to rest before I have to buy a wig.
>   >
>   >   Thanks,
>   >   Cem Karan
>   >
>   >   > -Original Message-
>   >   > From: License-discuss 
> [Caution-Caution-mailto:license-discuss-boun...@opensource.org < 
> Caution-mailto:license-discuss-
> boun...@opensource.org >  < Caution-Caution-mailto:license-discuss- < 
> Caution-mailto:license-discuss- >
>   > boun...@opensource.org < Caution-mailto:boun...@opensource.org >  > ] 
> On Behalf Of Tzeng, Nigel H.
>   >   > Sent: Thursday, March 16, 2017 2:48 PM
>   >   > To: license-discuss@opensource.org < 
> Caution-mailto:license-discuss@opensource.org >  < 
> Caution-Caution-mailto:license-
> disc...@opensource.org < Caution-mailto:license-discuss@opensource.org >  >
>   >   > Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible 
> alternative was: Re: U.S. Army Research Laboratory Open
> Source
>   > License (ARL
>   >   >

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

2017-03-16 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
Cool!  Would Fedora/Red Hat consider it to be Open Source?  

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Tom Callaway
> Sent: Thursday, March 16, 2017 3:31 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible alternative was: 
> Re: U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
> 
> 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.
> 
> 
> 
> 
> 
> 
> Can't speak for Debian, but Fedora will happily take software licensed as you 
> describe.
> 
> On Mar 16, 2017 3:09 PM, "Karan, Cem F CIV USARMY RDECOM ARL (US)" 
> <cem.f.karan@mail.mil < Caution-
> mailto:cem.f.karan@mail.mil > > wrote:
> 
> 
>   I agree that the Government can release it as open source, but as I 
> understand it, not as Open Source.  The difference is whether
> or not the code will be accepted into various journals (Journal of Open 
> Source Software is one).  It also affects whether or not various
> distributions will accept the work (would Debian?  I honestly don't know).
> 
>   And I'm not after plain vanilla CC0 code to be called Open Source, I'm 
> after the method I outlined earlier.  This side-steps the need
> to have CC0 put forth by the license steward (I hope!).  I know that is 
> splitting hairs, but at this point I'm tearing my hair out over this, and
> would like to put it to rest before I have to buy a wig.
> 
>   Thanks,
>   Cem Karan
> 
>   > -Original Message-
>   > From: License-discuss 
> [Caution-mailto:license-discuss-boun...@opensource.org < 
> Caution-mailto:license-discuss-
> boun...@opensource.org > ] On Behalf Of Tzeng, Nigel H.
>   > Sent: Thursday, March 16, 2017 2:48 PM
>   > To: license-discuss@opensource.org < 
> Caution-mailto:license-discuss@opensource.org >
>   > Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible 
> alternative was: Re: U.S. Army Research Laboratory Open Source
> License (ARL
>   > OSL) Version 0.4.1
>   >
>   > 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.
>   >
>   >
>   >
>   >
>   > 
>   >
>   > Cem,
>   >
>   > The USG does not need OSI’s approval to release code as open source 
> under CC0.  It has done so already on code.gov < Caution-
> http://code.gov > .  This includes the
>   > OPM, NASA, GSA, DOT, DOL, DOC and others. CC0 is compliant with the 
> Federal Source Code Policy for open source release.
>   >
>   > It is unlikely that you can push CC0 through license review as you 
> aren’t the license steward.  It is up to CC to resubmit CC0 for
> approval.
>   >
>   > Regards,
>   >
>   > Nigel
>   >
>   > On 3/16/17, 8:56 AM, "License-discuss on behalf of Karan, Cem F CIV 
> USARMY RDECOM ARL (US)"> boun...@opensource.org < Caution-mailto:boun...@opensource.org >  on 
> behalf of cem.f.karan@mail.mil < Caution-
> mailto:cem.f.karan@mail.mil > > wrote:
>   >
>   > All, I want to keep this alive as I haven't seen a conclusion 
> yet.  Earlier I
>   > asked if OSI would accept the US Government (USG) putting its 
> non-copyrighted
>   > works out under CC0 as Open Source **provided** that the USG 
> accepts and
>   > redistributes copyrighted contributions under an OSI-approved 
> license.  Is
>   > this acceptable to OSI?  Should I move this discussion to the 
> license-review
>   > list?
>   >
>   > To recap:
>   >
>   > 1) This would only cover USG works that do not have copyright.  
> Works that
>   > have copyright would be eligible to use copyright-based licenses, 
> and to be
>   > OSI-approved as Open Source would need to use an OSI-approved 
> license.
>   >
>   > 2) The USG work/project would select an OSI-approved license that 
> it accepted
>   > contributions under.  The USG would redis

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

2017-03-16 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
I agree that the Government can release it as open source, but as I understand 
it, not as Open Source.  The difference is whether or not the code will be 
accepted into various journals (Journal of Open Source Software is one).  It 
also affects whether or not various distributions will accept the work (would 
Debian?  I honestly don't know).

And I'm not after plain vanilla CC0 code to be called Open Source, I'm after 
the method I outlined earlier.  This side-steps the need to have CC0 put forth 
by the license steward (I hope!).  I know that is splitting hairs, but at this 
point I'm tearing my hair out over this, and would like to put it to rest 
before I have to buy a wig.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Tzeng, Nigel H.
> Sent: Thursday, March 16, 2017 2:48 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible alternative was: 
> Re: U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
> 
> 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.
> 
> 
> 
> 
> 
> 
> Cem,
> 
> The USG does not need OSI’s approval to release code as open source under 
> CC0.  It has done so already on code.gov.  This includes the
> OPM, NASA, GSA, DOT, DOL, DOC and others. CC0 is compliant with the Federal 
> Source Code Policy for open source release.
> 
> It is unlikely that you can push CC0 through license review as you aren’t the 
> license steward.  It is up to CC to resubmit CC0 for approval.
> 
> Regards,
> 
> Nigel
> 
> On 3/16/17, 8:56 AM, "License-discuss on behalf of Karan, Cem F CIV USARMY 
> RDECOM ARL (US)"  boun...@opensource.org on behalf of cem.f.karan@mail.mil> wrote:
> 
> All, I want to keep this alive as I haven't seen a conclusion yet.  
> Earlier I
> asked if OSI would accept the US Government (USG) putting its 
> non-copyrighted
> works out under CC0 as Open Source **provided** that the USG accepts and
> redistributes copyrighted contributions under an OSI-approved license.  Is
> this acceptable to OSI?  Should I move this discussion to the 
> license-review
> list?
> 
> To recap:
> 
> 1) This would only cover USG works that do not have copyright.  Works that
> have copyright would be eligible to use copyright-based licenses, and to 
> be
> OSI-approved as Open Source would need to use an OSI-approved license.
> 
> 2) The USG work/project would select an OSI-approved license that it 
> accepted
> contributions under.  The USG would redistribute the contributions under 
> that
> license, but the portions of the work that are not under copyright would 
> be
> redistributed under CC0.  That means that for some projects (ones that 
> have no
> copyrighted material at all initially), the only license that the works 
> would
> have would be CC0.
> 
> I can't speak to patents or other IP rights that the USG has, I can only
> comment on what the Army Research Laboratory (ARL) has done
> 
> (Caution-https://github.com/USArmyResearchLab/ARL-Open-Source-Guidance-and-Instructions),
> which includes a step to affirmatively waive any patent rights that ARL 
> might
> have in the project before distributing it.  I am hoping that other 
> agencies
> will do something similar, but have no power or authority to say that they
> will.
> 
> Given all this, is it time to move this to license-review, or otherwise 
> get a
> vote?  I'd like this solved ASAP.
> 
> Thanks,
> Cem Karan
> 
> 
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> Caution-https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss


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] [Non-DoD Source] Re: Possible alternative was: Re: U.S. Army Research Laboratory Open Source License (ARL OSL) Version 0.4.1

2017-03-16 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
All, I want to keep this alive as I haven't seen a conclusion yet.  Earlier I 
asked if OSI would accept the US Government (USG) putting its non-copyrighted 
works out under CC0 as Open Source **provided** that the USG accepts and 
redistributes copyrighted contributions under an OSI-approved license.  Is 
this acceptable to OSI?  Should I move this discussion to the license-review 
list?

To recap:

1) This would only cover USG works that do not have copyright.  Works that 
have copyright would be eligible to use copyright-based licenses, and to be 
OSI-approved as Open Source would need to use an OSI-approved license.

2) The USG work/project would select an OSI-approved license that it accepted 
contributions under.  The USG would redistribute the contributions under that 
license, but the portions of the work that are not under copyright would be 
redistributed under CC0.  That means that for some projects (ones that have no 
copyrighted material at all initially), the only license that the works would 
have would be CC0.

I can't speak to patents or other IP rights that the USG has, I can only 
comment on what the Army Research Laboratory (ARL) has done 
(https://github.com/USArmyResearchLab/ARL-Open-Source-Guidance-and-Instructions),
 
which includes a step to affirmatively waive any patent rights that ARL might 
have in the project before distributing it.  I am hoping that other agencies 
will do something similar, but have no power or authority to say that they 
will.

Given all this, is it time to move this to license-review, or otherwise get a 
vote?  I'd like this solved ASAP.

Thanks,
Cem Karan


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] [Non-DoD Source] code.mil update

2017-03-08 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Luis Villa
> Sent: Wednesday, March 08, 2017 2:51 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] code.mil update
> 
> On Wed, Mar 8, 2017 at 7:03 AM Christopher Sean Morrison <brl...@mac.com < 
> Caution-mailto:brl...@mac.com > > wrote:
> 
>       > On Mar 8, 2017, at 9:32 AM, Karan, Cem F CIV USARMY RDECOM ARL (US) 
> <cem.f.karan@mail.mil < Caution-
> mailto:cem.f.karan@mail.mil > > 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.
> 
> 
> 
> For what little it is worth, having just read intent.md < 
> Caution-http://intent.md > , I think it's an eminently reasonable policy. It 
> gives
> some baseline certainty for non-.gov contributors, non-US entities, and US 
> entities that are satisfied with a baseline set of FOSS rights. For
> those who for some reason need the additional flexibility of US-only PD, they 
> can do the research to figure out what is available in that
> way.
> 
> 
> Luis

I agree; my only concern with it was that the law might be slightly different 
with regards to the USG-furnished code as it is public domain within the US, 
but may have copyright outside of it.  Just so everyone is on a level playing 
field I'd prefer it if the USG works that don't have copyright were released 
under CC0, but that is my personal preference.  

That said, it might be a question to put on the Federal Register, and get some 
comments.  I mean, would it be beneficial if the USG had a consistent policy on 
this (public domain or CC0 for works that don't have copyright)?

Thanks,
Cem Karan



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] [Non-DoD Source] code.mil update

2017-03-08 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Christopher Sean Morrison
> Sent: Wednesday, March 08, 2017 10:03 AM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] code.mil update 
> 
> > On Mar 8, 2017, at 9:32 AM, Karan, Cem F CIV USARMY RDECOM ARL (US) 
> > <cem.f.karan@mail.mil> 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

Got it, I misunderstood what you were saying.

Thanks,
Cem Karan



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] [Non-DoD Source] Re: patent rights and the OSD

2017-03-08 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
I can pass it through ARL's lawyers, as well as pass it to the code.gov 
people.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Stephen Kellat
> Sent: Tuesday, March 07, 2017 10:41 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: patent rights and the 
> OSD
>
> 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.
>
>
>
>
> 
>
>
> On Mar 7, 2017, at 10:08 PM, Tzeng, Nigel H.  wrote:
> >
> > You know the more I think about this, the disclaimer of patent rights in 
> > CC0 is probably best for GOSS because it avoids the attempt for
> a one size fit all patent grant language among different agencies with 
> different policies and the complexity under which patent rights are
> awarded to whom under the Bayh-Dole Act and Executive Order 10096.
> >
> > Employees of federal agencies, especially research oriented ones, have 
> > some financial interest and rights under 10096.
> >
> > Likewise non-profits and small businesses under Bayh-Dole.
> >
> > IMHO patent grant language in FOSS licenses provide a false sense of 
> > security.
> >
> > I would rather the government open source as much as possible regardless 
> > of patent rights as long as any known patents are disclosed.
> As seen in Ximpleware v Versata the patents typically only cover a small 
> portion of the overall system (VTD-XML). While it is relevant from
> the perspective of being able to use the system as built it is less relevant 
> from a code reuse perspective.
> >
> > For large government systems significant software components could often 
> > be reused without the specific portions covered under
> patent.
> >
> > So just having a copyright license to the entire project would provide 
> > significant value to the community. There is code I wrote 30 years
> ago I'd love to get access to again even if I couldn't use the rest of the 
> system.
> >
> >
> > ___
> > License-discuss mailing list
> > License-discuss@opensource.org
> > Caution-https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
>
> After a less than fabulous day at work for IRS dealing with my tiny corner 
> of tax law as well as my accounts work, I am tempted after
> reading this.  Perhaps this could be used as well as the rest of this thread 
> as pre-decisional input to open a tight Inquiry in the Federal
> Register.  That's the first step we can take to move into building a formal 
> record for a body of law.  Alternatively getting something
> chartered under the Federal Advisory Committees Act might help move this 
> forward.
>
> I think the debate has dragged on a bit for more than a few months.  Moving 
> to where desirable federal policy/policies are adopted is
> probably doable.  Could we narrow this down to 3 or fewer courses of action 
> that might be explored by ARL counsel in an inquiry notice?
> Even if list participants are the only people that respond to a notice in 
> the Federal Register we're still building a useful record for later use
> such as Federal Acquisition Rules changes, for example.
>
> Depending upon what shows up in the President's budget set to drop Monday, I 
> either will have a lot of time on my hands coming up or
> an ICTAP certificate plus lots of time on my hands.  I want to see Federal 
> OSS policy evolve.  We have laid the groundwork here but need
> to get it in the official record soon.
>
> Stephen Michael Kellat
> GS-0962-07/1
> These views are solely my own and not those of the US Government.  Rank, 
> position, grade, and bureau are cited for identification
> purposes only.
>
>
>
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> Caution-https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss


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] [Non-DoD Source] code.mil update

2017-03-08 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
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.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Christopher Sean Morrison
> Sent: Tuesday, March 07, 2017 9:13 PM
> To: License Discussion Mailing List 
> Subject: [Non-DoD Source] [License-discuss] code.mil update
>
> 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.
>
>
> 
>
>
>
>
> 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:
>
>
> Caution-https://github.com/deptofdefense/code.mil#welcome-to-codemil---an-experiment-in-open-source-at-the-department-of-defense
> < 
> Caution-https://github.com/deptofdefense/code.mil#welcome-to-codemil---an-experiment-in-open-source-at-the-department-of-
> defense >



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] [Non-DoD Source] Re: patent rights and the OSD

2017-03-08 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
I see your point.  OK, so I'm going throw out a strawman here, just to see what 
happens.  Assume for the sake of argument that OSI decides to add a patent 
grant/license/whatever as part of the requirements of the OSD.  Will OSI then 
re-evaluate all currently approved licenses using the new criteria (potentially 
rejecting some that were previously accepted), or will it 'grandfather in' the 
currently approved licenses, and reject any new ones that don't have some kind 
of patent clause?  I can see arguments both for and against either approach.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Tzeng, Nigel H.
> Sent: Tuesday, March 07, 2017 7:14 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: patent rights and the OSD
> 
> 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.
> 
> 
> 
> 
> 
> 
> 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.
> 
> Not CC0 and some patent agreement that has not been written.
> 
> 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.
> From: Karan, Cem F CIV USARMY RDECOM ARL (US) <cem.f.karan@mail.mil < 
> Caution-mailto:cem.f.karan@mail.mil > >
> Date: Tuesday, Mar 07, 2017, 4:56 PM
> To: license-discuss@opensource.org <license-discuss@opensource.org < 
> Caution-mailto:license-discuss@opensource.org > >
> Subject: Re: [License-discuss] [Non-DoD Source] Re: patent rights and the OSD
> 
> That is true, but OSI can make it clear that when software is licensed, then 
> the licensor is expected to license any necessary patents that
> the licensor owns along with licensing the copyright.  If there are patents 
> that the licensor is unaware of, then the licensor can't do
> anything about that either.
> 
> And like you, I'm not a lawyer, and this is not legal advice.
> 
> Thanks,
> Cem Karan
> 
> > -Original Message-
> > From: License-discuss
> > [Caution-mailto:license-discuss-boun...@opensource.org <
> > Caution-mailto:license-discuss-boun...@opensource.org > ] On Behalf Of
> > Ben Tilly
> > Sent: Tuesday, March 07, 2017 4:45 PM
> > To: License Discuss <license-discuss@opensource.org>
> > Subject: [Non-DoD Source] Re: [License-discuss] patent rights and the
> > OSD
> >
> > 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.
> >
> >
> > 
> >
> >
> >
> > My legal rights to software on the computer in front of me may be
> > restricted by many things.  A short and incomplete list includes
> > copyright law, patents, contracts, who owns the computer and my employment 
> > status.  Any and all of these can impact whether I
> actually enjoy the freedoms that the OSD describes.  I may be unaware of or 
> misinformed about any or all these potential encumbrances.
> >
> > 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.  In principle 
> > it is generally impossible to decide whether I *actually* have
> the rights described by the OSD to the software in front of me.
> >
> > (I am not a lawyer and this is not legal advice.)
> >
> > On Mon, Mar 6, 2017 at 3:41 PM, Christopher Sean Morrison <brl...@mac.com < 
> > Caution-Caution-mailto:brl...@mac.com > > wrote:
> >
> >
> >
> >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 

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

2017-03-08 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
Just to be clear, if you're talking about the US Army Research Laboratory 
(ARL) policy 
(https://github.com/USArmyResearchLab/ARL-Open-Source-Guidance-and-Instructions),
 
that policy only applies to personnel at the US Army Research Laboratory. 
Other agencies are free to adopt and adapt that policy; I'm encouraging anyone 
I run in to do so, but other agencies in theory could adopt very different 
policies.  Caveat emptor (or whatever the equivalent is in this case).

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Lawrence Rosen
> Sent: Tuesday, March 07, 2017 4:57 PM
> To: license-discuss@opensource.org
> Cc: Lawrence Rosen 
> Subject: Re: [License-discuss] [Non-DoD Source] patent rights and the OSD
>
> 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.
>
>
> 
>
>
>
>
> Richard Fontana suggested:
>
> > 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?
>
>
>
> Richard, that sounds like a great compromise that the government agencies 
> might be able to live with. :-)  If I understand correctly, there
> is already an existing government policy that patent rights are granted to 
> all users of the software, albeit separately by policy rather than
> by license.
>
>
>
> And if I understand correctly, that is already the implied promise in 
> Europe?
>
>
>
> /Larry
>
>
>
> -Original Message-
> From: License-discuss 
> [Caution-mailto:license-discuss-boun...@opensource.org] On Behalf Of Richard 
> Fontana
> Sent: Tuesday, March 7, 2017 1:09 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] patent rights and the OSD
>
>
>
> 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.
>
>
>
> There is the 'Clear BSD' license, which the FSF considers not only a free 
> software license but also GPL-compatible:
>
>
>
> Caution-https://directory.fsf.org/wiki/License:ClearBSD < 
> Caution-https://directory.fsf.org/wiki/License:ClearBSD >
>
> Caution-https://www.gnu.org/licenses/license-list.en.html#clearbsd < 
> Caution-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.
>
>
>
> 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.
>
>
>
> > 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.
>
>
>
> 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?
>
>
>
> Richard
>
> ___
>
> License-discuss mailing list
>
> License-discuss@opensource.org < 
> Caution-mailto:License-discuss@opensource.org >
>
> Caution-https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss 
> < Caution-https://lists.opensource.org/cgi-
> bin/mailman/listinfo/license-discuss >



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] [Non-DoD Source] Re: patent rights and the OSD

2017-03-07 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
That is true, but OSI can make it clear that when software is licensed, then 
the licensor is expected to license any necessary patents that the licensor 
owns along with licensing the copyright.  If there are patents that the 
licensor is unaware of, then the licensor can't do anything about that either.

And like you, I'm not a lawyer, and this is not legal advice.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Ben Tilly
> Sent: Tuesday, March 07, 2017 4:45 PM
> To: License Discuss 
> Subject: [Non-DoD Source] Re: [License-discuss] patent rights and the OSD
> 
> 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.
> 
> 
> 
> 
> 
> 
> My legal rights to software on the computer in front of me may be restricted 
> by many things.  A short and incomplete list includes
> copyright law, patents, contracts, who owns the computer and my employment 
> status.  Any and all of these can impact whether I actually
> enjoy the freedoms that the OSD describes.  I may be unaware of or 
> misinformed about any or all these potential encumbrances.
> 
> 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.  In principle it 
> is generally impossible to decide whether I *actually* have the
> rights described by the OSD to the software in front of me.
> 
> (I am not a lawyer and this is not legal advice.)
> 
> On Mon, Mar 6, 2017 at 3:41 PM, Christopher Sean Morrison  Caution-mailto:brl...@mac.com > > wrote:
> 
> 
> 
>   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 < 
> Caution-mailto:License-discuss@opensource.org >
>   
> Caution-https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss 
> < Caution-https://lists.opensource.org/cgi-
> bin/mailman/listinfo/license-discuss >
> 
> 



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] [Non-DoD Source] patent rights and the OSD

2017-03-07 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Christopher Sean Morrison
> Sent: Tuesday, March 07, 2017 10:56 AM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] patent rights and the OSD
>
>
> On Mar 07, 2017, at 09:07 AM, "Karan, Cem F CIV USARMY RDECOM ARL (US)" 
> <cem.f.karan@mail.mil> 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.

You're right of course.  My bad.

Thanks,
Cem Karan



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] [Non-DoD Source] patent rights and the OSD

2017-03-07 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
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 prevents people from freely modifying the code.  That 
said, I don't have a problem with someone holding a software patent; in some 
cases, it may actually be beneficial because it prevents someone else from 
holding the same patent, so it may actually clarify what is being licensed[1].

Thanks,
Cem Karan

[1] I'm not a lawyer, this is not legal advice, find someone that really knows 
the law to make sure this is correct.

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Christopher Sean Morrison
> Sent: Monday, March 06, 2017 6:41 PM
> To: License Discussion Mailing List 
> Subject: [Non-DoD Source] [License-discuss] patent rights and the OSD
> 
> 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.
> 
> 
> 
> 
> 
> 
> 
> 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
> Caution-https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss


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] [Non-DoD Source] Re: Possible alternative was: Re: U.S. Army Research Laboratory Open Source License (ARL OSL) Version 0.4.1

2017-03-03 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
ARL's policy is to waive its own potential patent rights before releasing the 
software.  If there are extra rights that we can't license/release for this 
purpose, then our legal team will refuse to allow the software's release, so 
anything ARL releases under our policy should be clean from an IP standpoint.

That said, I see the point of a patent pledge of some kind; I'll ask our legal 
team if we can put something in, but then we'll have a situation of (OSI 
approved license) + CC0 + (patent pledge), which feels fairly cumbersome.  I'd 
prefer that we have something more streamlined in place that satisfy Government 
needs and OSI needs.  The best approach I know of **right now** is simply (OSI 
approved license) + CC0.

I'll bring this point up on the Federal Open Source Policy Group's list though, 
so they have a better idea of what the issues are.

Thanks,
Cem Karan

> -Original Message-
> From: Jim Wright [mailto:jim.wri...@oracle.com]
> Sent: Wednesday, March 01, 2017 7:19 PM
> To: license-discuss@opensource.org
> Cc: Larry Rosen <lro...@rosenlaw.com>; Karan, Cem F CIV USARMY RDECOM ARL 
> (US) <cem.f.karan@mail.mil>
> Subject: [Non-DoD Source] Re: [License-discuss] Possible alternative was: Re: 
> U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
> 
> 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.
> 
> 
> 
> 
> 
> 
> We do agree for the most part, but not entirely here.  I was more looking 
> back to Cem’s original question about whether CC0 would
> ensure their projects are Open Source today, which it would not, in the 
> absence of action on CC0 that would not be unanimously
> supported to say the least.  My take is that they could better attend to this 
> problem right now by choosing any existing OSI license,
> preferably one with a clear patent license, and if Cem is looking to ensure 
> that their projects are Open Source in the immediate term, this
> is a path that requires nothing of the rest of us and little to nothing of 
> them either IMHO.
> 
> Of course my view is obviously colored by my take that CC0 is *not* a good 
> model for open source and that it would have been a bad
> thing for it to have been approved - a license that specifically reserves 
> rights of the author to pursue infringement claims against users is
> not a license we want to encourage the use of, by the government or anyone 
> else...
> 
>  Best,
>   Jim
> 
> 
> 
> 
>   On Mar 1, 2017, at 3:34 PM, Lawrence Rosen <lro...@rosenlaw.com < 
> Caution-mailto:lro...@rosenlaw.com > > wrote:
> 
> 
>   Jim Wright wrote:
> 
>   > Something is certainly better than nothing, I agree, but ...
> 
> 
>   Jim, I'm on your side on this. :-)  I'm hoping that a U.S. government 
> open source policy, someday published in the Federal Register
> and bearing the force of law, will also include an express patent pledge that 
> we can all rely on. Copyright isn't enough. Maybe even UPL?
> 
>   Such a pledge could become a model for other large patent-holding 
> institutions, such as universities, to give open source users
> reassurance that they are not patent infringers.
> 
>   That's a bigger topic than for here. It is largely up to that public 
> Federal Register process that eventually may ensue. It has nothing
> to do with OSI's approval of CC0. This WE can do now on our own on behalf of 
> government open source.
> 
>   /Larry
> 
> 
> 
> 
>   From: Jim Wright [Caution-mailto:jim.wri...@oracle.com < 
> Caution-mailto:jim.wri...@oracle.com > ]
>   Sent: Wednesday, March 1, 2017 2:59 PM
>   To: lro...@rosenlaw.com < Caution-mailto:lro...@rosenlaw.com > ; 
> license-discuss@opensource.org < Caution-mailto:license-
> disc...@opensource.org >
>   Subject: Re: [License-discuss] Possible alternative was: Re: U.S. Army 
> Research Laboratory Open Source License (ARL OSL) Version
> 0.4.1
> 
> 
> 
>   Something is certainly better than nothing, I agree, but I think many 
> of us would rather have an express and broad license from all
> participants in a project, including the government, than to have to rely on 
> less than well understood public domain dedications and
> waivers of patent rights that do not apply to all participants.  Something 
> closer to symmetry and broad coverage should be achievable
> here IMHO - the perfect may sometimes be the enemy of the good, but in this 
> case, we can, I think, do better than CC0. 

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

2017-03-01 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] 
> On Behalf Of Lawrence Rosen
> Sent: Wednesday, March 01, 2017 5:01 PM
> To: license-discuss@opensource.org
> Cc: Lawrence Rosen 
> Subject: [Non-DoD Source] Re: [License-discuss] Possible alternative 
> was: Re: U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
> 
> Jim Wright wrote:
> 
> > it seems odd to me to require a dedication to the public domain in 
> > any event - stuff is either in the public domain by law or isn’t, 
> > and to
> whatever extent it isn’t, we should have a copyright license, full 
> stop.  Similarly as to patents, I don’t want to have to look at some 
> ostensible policy on waiving patent rights, we should all have a clearly 
> scoped patent license for the project, government and private contributors 
> alike, and there is an easy vehicle to achieve this, use an OSI approved 
> license.
> 
> 
> 
> Jim, regardless of which OSI-approved license(s) the U.S. government chooses 
> for its distributed software, neither the "public domain"
> question nor the "patent license" question will EVER be fully answered 
> for any particular software simply by reading those licenses. You have to 
> look at the software itself. Of course, we could all sue each other and let 
> the courts decide
> 
> 
> 
> I'll be grateful for a published government policy – perhaps posted in 
> the Federal Register someday – that reassures us of a commitment by 
> government agencies to open source using any OSI-approved license.
> 
> 
> 
> Including CC0.

What would you want to see in such a policy that is different from what is on 
code.gov, or different from ARL's published policy?  I can bring this up at the 
Federal Source Code Policy meetings.  Note that if the Government takes that 
route, it will likely have to take the full Federal Register route, including 
comments, etc.  That means that any suggestions you make right now are only for 
me to gather preliminary information; nothing more.

Thanks,
Cem Karan
 



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] [Non-DoD Source] Re: Possible alternative was: Re: U.S. Army Research Laboratory Open Source License (ARL OSL) Version 0.4.1

2017-03-01 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
THANK YOU!

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Christopher Sean Morrison
> Sent: Wednesday, March 01, 2017 1:51 PM
> To: License Discussion Mailing List 
> Subject: [Non-DoD Source] Re: [License-discuss] Possible alternative was: Re: 
> U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
> 
> 
>   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



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] [Non-DoD Source] Re: Possible alternative was: Re: U.S. Army Research Laboratory Open Source License (ARL OSL) Version 0.4.1

2017-03-01 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
I understand; ARL's policy is LONG, and skimming is just about the only way to 
not have your brain fry. :)  That said, does it address your concerns about the 
patent issues?

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Tzeng, Nigel H.
> Sent: Wednesday, March 01, 2017 1:28 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible alternative was: 
> Re: U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
> 
> 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.
> 
> 
> 
> 
> 
> 
> Cem,
> 
> Thanks. I missed that when skimming before. :). I think your materials are 
> ahead of what I've seen in the DOSA repo.
> 
> One of the concerns I have (not speaking for my organization) are the same 
> ones that prompted the patent changes to Apache for ECL
> V2.0.
> 
> Copyright is easy, I and my team wrote our code. Patent are harder because we 
> as developers or even program managers are not always
> aware of all patents owned or in progress by the far flung parts of a large 
> research organization. As I've stated before, I don't mind giving
> away my work. I don't want to accidentally give away someone else's work 
> (patent).
> 
> ECL is my natural conservative inclination over Apache. Most of what you see 
> under my name approved for open sourcerelease is actually
> under NOSA.
> 
> Nigel
> 
> From: Karan, Cem F CIV USARMY RDECOM ARL (US) <cem.f.karan@mail.mil < 
> Caution-mailto:cem.f.karan@mail.mil > >
> Date: Wednesday, Mar 01, 2017, 12:40 PM
> To: license-discuss@opensource.org <license-discuss@opensource.org < 
> Caution-mailto:license-discuss@opensource.org > >
> Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible alternative was: 
> Re: U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
> 
> That is actually a part of ARL's policy.  If you haven't looked at the policy 
> yet, go toCaution-https://github.com/USArmyResearchLab/ARL-
> Open-Source-Guidance-and-Instructions < 
> Caution-https://github.com/USArmyResearchLab/ARL-Open-Source-Guidance-and-Instructions
>  >
> and take a look.
> 
> Thanks,
> Cem Karan
> 
> > -Original Message-
> > From: License-discuss 
> > [Caution-mailto:license-discuss-boun...@opensource.org < 
> > Caution-mailto:license-discuss-
> boun...@opensource.org > ] On Behalf Of Tzeng, Nigel H.
> > Sent: Wednesday, March 01, 2017 12:23 PM
> > To: license-discuss@opensource.org
> > Subject: [Non-DoD Source] Re: [License-discuss] Possible alternative
> > was: Re: U.S. Army Research Laboratory Open Source License (ARL
> > OSL) Version 0.4.1
> >
> > 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.
> >
> >
> > 
> >
> >
> >
> > OSI approval is not explicitly required under DOSA. It just says open 
> > source license.
> >
> > If DOSA explicitly defines the licensing authority I would prefer it be 
> > stated as any DOD approved open source license.
> >
> > That would insure that any projects we develop for sponsors and
> > released as open source will be under a license that has been reviewed and 
> > accepted by DOD legal from both from a security as well as
> compliance standpoint.
> > From: Jim Wright <jwri...@commsoft.com <
> > Caution-Caution-mailto:jwri...@commsoft.com > >
> > Date: Wednesday, Mar 01, 2017, 11:53 AM
> > To: license-discuss@opensource.org <license-discuss@opensource.org <
> > Caution-Caution-mailto:license-discuss@opensource.org > >
> > Subject: Re: [License-discuss] Possible alternative was: Re: U.S. Army
> > Research Laboratory Open Source License (ARL OSL) Version 0.4.1
> >
> > Certainly the approach code.mil spells out to contributions seems ok
> > without having to address the license issue at all, but these
> > questions seem orthogonal to me.  Cem seems to be trying to ensure
> > that all open source projects operating using this process are under
> > an OSI approved license, which appears to require them to pick one (or
> > seve

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

2017-03-01 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
Part of the internal process is that there is a scrub by legal to ensure that 
the ARL has the necessary rights to do the release.  If we can't procure the 
rights, then it isn't released.  My expectation is that other agencies would do 
something similar.  Note that I can't speak for other agencies, I'm only 
stating my personal opinion on this.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Tzeng, Nigel H.
> Sent: Wednesday, March 01, 2017 12:37 PM
> To: license-discuss@opensource.org; Jim Wright <jwri...@commsoft.com>
> Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible alternative was: 
> Re: U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
> 
> 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.
> 
> 
> 
> 
> 
> 
> For government owned patents and software that would be fine but research 
> organizations often bring existing IP to the table funded
> through internal research and development funding. Some of which has limited 
> government use rights rather than full rights.
> 
> A blanket waiver of patent right by ARL may work for ARL because of the way 
> ARL contracts are negotiated but may not work for all DoD
> stakeholders working under DFARS.
> 
> 
> From: Karan, Cem F CIV USARMY RDECOM ARL (US) <cem.f.karan@mail.mil < 
> Caution-mailto:cem.f.karan@mail.mil > >
> Date: Wednesday, Mar 01, 2017, 12:21 PM
> To: Jim Wright <jwri...@commsoft.com < Caution-mailto:jwri...@commsoft.com > 
> >, license-discuss@opensource.org  disc...@opensource.org < Caution-mailto:license-discuss@opensource.org > >
> Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible alternative was: 
> Re: U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
> 
> You've hit the nail on the head!  I personally want Government works to be 
> Open Source, not open source.  That was the whole point of
> the ARL OSL being put forwards.  There are statutory and regulatory limits on 
> what the Government can and cannot do; the lawyers I've
> talked with say that this is something we can do, which also protects 
> Government interests (IP licensing, not getting sued for
> warranty/liability, etc.).
> 
> Is the concern that the **Government** is not licensing its patent rights?  
> ARL's internal process includes waiving any potential IP rights
> (including patent rights) in the software that is being released, so that 
> should cover anyone downstream.
> 
> Thanks,
> Cem Karan
> 
> > -Original Message-
> > From: Jim Wright [Caution-mailto:jwri...@commsoft.com <
> > Caution-mailto:jwri...@commsoft.com > ]
> > Sent: Wednesday, March 01, 2017 11:53 AM
> > To: license-discuss@opensource.org
> > Cc: Richard Fontana <font...@sharpeleven.org>; Karan, Cem F CIV USARMY
> > RDECOM ARL (US) <cem.f.karan@mail.mil>
> > Subject: [Non-DoD Source] Re: [License-discuss] Possible alternative
> > was: Re: U.S. Army Research Laboratory Open Source License (ARL
> > OSL) Version 0.4.1
> >
> > Certainly the approach code.mil spells out to contributions seems ok
> > without having to address the license issue at all, but these
> > questions seem orthogonal to me.  Cem seems to be trying to ensure
> > that all open source projects operating using this process are under
> > an OSI approved license, which appears to require them to pick one (or
> > several) FOSS licenses to actually apply.  CC0 doesn’t work for that
> > purpose because it’s not OSI approved anyway and also doesn’t have a
> > patent license, but observing this doesn’t solve Cem’s problem of how
> > to license this stuff in a way that *is* OSI approved, which I think
> > is what he’s getting at.  (Feel free to correct me…)
> >
> >
> > > On Mar 1, 2017, at 8:29 AM, Richard Fontana <font...@sharpeleven.org> 
> > > wrote:
> > >
> > > Well the complication is mainly a response to Cem wanting the OSI to
> > > bless his proposed approach. I think however that code.mil has
> > > already rejected this sort of idea.
> > >
> > > I think the code.mil approach is much more elegant without
> > > introducing the use of CC0.
> > >
> > >
> 



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] [Non-DoD Source] Re: Possible alternative was: Re: U.S. Army Research Laboratory Open Source License (ARL OSL) Version 0.4.1

2017-03-01 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
That is actually a part of ARL's policy.  If you haven't looked at the policy 
yet, go to 
https://github.com/USArmyResearchLab/ARL-Open-Source-Guidance-and-Instructions 
and take a look.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Tzeng, Nigel H.
> Sent: Wednesday, March 01, 2017 12:23 PM
> To: license-discuss@opensource.org
> Subject: [Non-DoD Source] Re: [License-discuss] Possible alternative was: Re: 
> U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
> 
> 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.
> 
> 
> 
> 
> 
> 
> OSI approval is not explicitly required under DOSA. It just says open source 
> license.
> 
> If DOSA explicitly defines the licensing authority I would prefer it be 
> stated as any DOD approved open source license.
> 
> That would insure that any projects we develop for sponsors and released as 
> open source will be under a license that has been reviewed
> and accepted by DOD legal from both from a security as well as compliance 
> standpoint.
> From: Jim Wright  > >
> Date: Wednesday, Mar 01, 2017, 11:53 AM
> To: license-discuss@opensource.org  Caution-mailto:license-discuss@opensource.org > >
> Subject: Re: [License-discuss] Possible alternative was: Re: U.S. Army 
> Research Laboratory Open Source License (ARL OSL) Version 0.4.1
> 
> Certainly the approach code.mil spells out to contributions seems ok without 
> having to address the license issue at all, but these questions
> seem orthogonal to me.  Cem seems to be trying to ensure that all open source 
> projects operating using this process are under an OSI
> approved license, which appears to require them to pick one (or several) FOSS 
> licenses to actually apply.  CC0 doesn’t work for that
> purpose because it’s not OSI approved anyway and also doesn’t have a patent 
> license, but observing this doesn’t solve Cem’s problem of
> how to license this stuff in a way that *is* OSI approved, which I think is 
> what he’s getting at.  (Feel free to correct me…)
> 
> 
> > On Mar 1, 2017, at 8:29 AM, Richard Fontana  wrote:
> >
> > Well the complication is mainly a response to Cem wanting the OSI to
> > bless his proposed approach. I think however that code.mil has already
> > rejected this sort of idea.
> >
> > I think the code.mil approach is much more elegant without introducing
> > the use of CC0.
> >
> >
> 
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> Caution-https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss 
> < Caution-https://lists.opensource.org/cgi-
> bin/mailman/listinfo/license-discuss >



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] [Non-DoD Source] Re: Possible alternative was: Re: U.S. Army Research Laboratory Open Source License (ARL OSL) Version 0.4.1

2017-03-01 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
I've forwarded the link to our lawyers, I'll ping them on Friday when I get 
back in the office to see what they say.

Thanks,
Cem Karan

> -Original Message-
> From: Jim Wright [mailto:jim.wri...@oracle.com]
> Sent: Wednesday, March 01, 2017 11:27 AM
> To: license-discuss@opensource.org
> Cc: Karan, Cem F CIV USARMY RDECOM ARL (US) <cem.f.karan@mail.mil>; 
> Richard Fontana <font...@sharpeleven.org>
> Subject: [Non-DoD Source] Re: [License-discuss] Possible alternative was: Re: 
> U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
> 
> 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.
> 
> 
> 
> 
> 
> 
> Of course, as Richard pointed out earlier, this would also be true as to the 
> ASL, etc., except to the extent that the government choosing to
> effectively “waive" patent rights as Cem has said is not the same thing as a 
> terminable patent license in the ASL - the UPL thus arguably
> putting the government on the most equal footing possible with everyone else 
> given the expressed intent re: license scope… maybe the
> grant of “any and all copyright rights” would make them feel better about the 
> copyright grant by virtue of not suggesting there necessarily
> are any?  Obviously tooting the horn here but it seems odd to me to require a 
> dedication to the public domain in any event - stuff is either
> in the public domain by law or isn’t, and to whatever extent it isn’t, we 
> should have a copyright license, full stop.  Similarly as to patents, I
> don’t want to have to look at some ostensible policy on waiving patent 
> rights, we should all have a clearly scoped patent license for the
> project, government and private contributors alike, and there is an easy 
> vehicle to achieve this, use an OSI approved license.
> 
> 
> > On Mar 1, 2017, at 7:49 AM, Jim Wright <jim.wri...@oracle.com> wrote:
> >
> > Indeed, if there’s no copyright in the US, there may be no need of a 
> > copyright license from the government here, but in any event there
> *is* an OSI approved permissive license that licenses both any applicable 
> copyright rights (without actually requiring that the government
> have any) and patent rights applicable to the project - the UPL.
> >
> > If the government releases code under the UPL, and accepts contributions 
> > under the UPL, they are using an OSI approved license, full
> stop, no need of extra terms or to treat other contributors any differently 
> than the government itself, no need of an express public domain
> dedication which is any different than what is already true by law, everyone 
> is simply licensing whatever copyright rights they possess as
> well as whatever patent rights they possess covering the project as they 
> contributed to or provided it, and it seems to me at first glance
> like nothing else need be done…?
> >
> > Regards,
> >  Jim
> >
> >
> >> On Mar 1, 2017, at 6:49 AM, Richard Fontana <font...@sharpeleven.org> 
> >> wrote:
> >>
> >> On Wed, Mar 01, 2017 at 09:37:13AM -0500, Richard Fontana wrote:
> >>> Strictly speaking, the use of
> >>> CC0 assumes that you have copyright ownership.
> >>
> >> I guess that's a bit of an overstatement, but still given the nature
> >> of the angst I've heard from US government people over the years
> >> concerning the use of nominal copyright licenses, I'd find it
> >> surprising if CC0 was treated differently.
> >>
> >>
> >> ___
> >> License-discuss mailing list
> >> License-discuss@opensource.org
> >> Caution-https://lists.opensource.org/cgi-bin/mailman/listinfo/license
> >> -discuss
> >



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] [Non-DoD Source] Re: Possible alternative was: Re: U.S. Army Research Laboratory Open Source License (ARL OSL) Version 0.4.1

2017-03-01 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
No.  The material can always be separated into two piles; stuff that has 
copyright attached, and stuff that does not have copyright attached.  The 
stuff that has copyright attached is always released under the chosen 
OSI-approved license; everything else is released under CC0.  Within the US, 
that means that material that has no copyright attached is in the public 
domain.  CC0 makes this the same for jurisdictions outside of the US.

In general, if a contribution has copyright attached, then the contributor 
will retain copyright (unless they choose to assign it to the US Government 
for some reason).  To contribute, the contributor must agree to license the 
contribution to the USG under that project's chosen OSI-approved license (e.g. 
Apache 2.0).  From then on, when the USG redistributes **that particular 
contribution**, it will be under that license (e.g. Apache 2.0).  However, 
material that does not have copyright will be redistributed under CC0.  This 
will result in a mosaic of material in each project, where some portions are 
under CC0, and others are under the OSI-approved license.  You will need to 
use the version control system to determine which is which.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Richard Fontana
> Sent: Wednesday, March 01, 2017 12:10 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible alternative 
> was: Re: U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
>
> 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.
>
>
>
>
> ----
>
> On Wed, Mar 01, 2017 at 04:39:01PM +, Karan, Cem F CIV USARMY RDECOM ARL 
> (US) wrote:
> > I see your points about the Apache license vs. CC0, but the reason CC0
> > is more palatable is because we're not trying to make any restrictions
> > based on copyright.  We're trying to meet the spirit of US law, and
> > our lawyers believe that CC0 has the best chance of doing that.
> >
> > As to your second point, that is PRECISELY what I'm proposing.  The
> > material that has copyright attached will be accepted under the
> > OSI-approved license that the project controllers wish to use, and all
> > other material will be distributed under CC0.  This way the US
> > Government is not claiming copyright where none exists.
>
> So your proposal is: US government releases simultaneously under CC0 (for 
> the US case) and some designated open source license (for the
> non-US case)?
>
> I like the code.mil approach better. (This doesn't have much to do with the 
> fact that CC0 is not OSI-approved - I would have a similar
> reaction to, say, use of the Free Public License (aka Zero Clause
> BSD).)
>
> BTW, CC0 does not have a limitation of liability provision as far as I can 
> tell (not counting the prefatory one that applies only to Creative
> Commons Corp.).
>
>
>
>
>
>
>
> > > The approach I understand code.mil to be taking is that a given
> > > project will have an open source license and that license will cover
> > > anything that isn't statutory public domain, including both
> > > contributions coming in through the DCO and code released by the US
> > > government that may be public domain in the US but not elsewhere.
> > >
> > > See:
> > > Caution-Caution-https://github.com/deptofdefense/code.mil/blob/maste
> > > r/Proposal/CONTRIBUTING.md#1-license
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > >
> > > > Note that I am not a lawyer, and none of this should be construed
> > > > as legal advice.
> > > >
> > > > Thanks,
> > > > Cem Karan
> > > >
> > > > > -Original Message-
> > > > > From: License-discuss
> > > > > [Caution-Caution-mailto:license-discuss-boun...@opensource.org]
> > > > > On Behalf Of Richard Fontana
> > > > > Sent: Wednesday, March 01, 2017 9:37 AM
> > > > > To: license-discuss@opensource.org
> > > > > Subject: [Non-DoD Source] Re: [License-discuss] Possible
> > > > > alternative
> > > > > was:
> > > > > Re: U.S. Army Research Laboratory Open Source License (ARL
> > > > > OSL) Version 0.4.1
> > > > >
> > > > > All active links conta

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

2017-03-01 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
You've hit the nail on the head!  I personally want Government works to be Open 
Source, not open source.  That was the whole point of the ARL OSL being put 
forwards.  There are statutory and regulatory limits on what the Government can 
and cannot do; the lawyers I've talked with say that this is something we can 
do, which also protects Government interests (IP licensing, not getting sued 
for warranty/liability, etc.).

Is the concern that the **Government** is not licensing its patent rights?  
ARL's internal process includes waiving any potential IP rights (including 
patent rights) in the software that is being released, so that should cover 
anyone downstream.

Thanks,
Cem Karan

> -Original Message-
> From: Jim Wright [mailto:jwri...@commsoft.com]
> Sent: Wednesday, March 01, 2017 11:53 AM
> To: license-discuss@opensource.org
> Cc: Richard Fontana <font...@sharpeleven.org>; Karan, Cem F CIV USARMY RDECOM 
> ARL (US) <cem.f.karan@mail.mil>
> Subject: [Non-DoD Source] Re: [License-discuss] Possible alternative was: Re: 
> U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
> 
> Certainly the approach code.mil spells out to contributions seems ok without 
> having to address the license issue at all, but these questions
> seem orthogonal to me.  Cem seems to be trying to ensure that all open source 
> projects operating using this process are under an OSI
> approved license, which appears to require them to pick one (or several) FOSS 
> licenses to actually apply.  CC0 doesn’t work for that
> purpose because it’s not OSI approved anyway and also doesn’t have a patent 
> license, but observing this doesn’t solve Cem’s problem of
> how to license this stuff in a way that *is* OSI approved, which I think is 
> what he’s getting at.  (Feel free to correct me…)
> 
> 
> > On Mar 1, 2017, at 8:29 AM, Richard Fontana <font...@sharpeleven.org> wrote:
> >
> > Well the complication is mainly a response to Cem wanting the OSI to
> > bless his proposed approach. I think however that code.mil has already
> > rejected this sort of idea.
> >
> > I think the code.mil approach is much more elegant without introducing
> > the use of CC0.
> >
> >



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] [Non-DoD Source] Re: Possible alternative was: Re: U.S. Army Research Laboratory Open Source License (ARL OSL) Version 0.4.1

2017-03-01 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
Then there would still need to be a disclaimer of warranty and liability, and 
there would still need be a way of settling the problems of foreign 
jurisdictions.  The Government could write its own terms, but those terms would 
like not be widely recognized.  CC0 is well-known, and acceptable to our 
lawyers.  Public domain release without disclaimers of warranty and liability 
is not acceptable.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Richard Fontana
> Sent: Wednesday, March 01, 2017 11:30 AM
> To: license-discuss@opensource.org
> Subject: [Non-DoD Source] Re: [License-discuss] Possible alternative was: Re: 
> U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
> 
> 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.
> 
> 
> 
> 
> 
> 
> Well the complication is mainly a response to Cem wanting the OSI to bless 
> his proposed approach. I think however that code.mil has
> already rejected this sort of idea.
> 
> I think the code.mil approach is much more elegant without introducing the 
> use of CC0.
> 
> 
> 
> On Wed, Mar 01, 2017 at 03:08:22PM +, Tzeng, Nigel H. wrote:
> > Richard,
> >
> > It is very hard for me to take a complaint that CC0 not being OSI approved 
> > as a significant issue vs continued feet dragging when the OSI
> won’t provide guidance on license asymmetry, won’t vote on NOSA v2.0 and had 
> the opportunity to pass CC0 years ago.
> >
> > CC0 is accepted as open source by the FSF and by the GSA (see Federal 
> > Source Code Policy examples).  The fact that the OSI has not
> approved CC0 is a “complication” of its own making.  One easily solved with 
> an email from the OSI to CC requesting that CC resubmit CC0
> and then the OSI board approving it.
> >
> > Nigel
> >
> > On 3/1/17, 9:37 AM, "License-discuss on behalf of Richard Fontana" 
> > <license-discuss-boun...@opensource.org on behalf of
> font...@sharpeleven.org> wrote:
> >
> > I really like the approach as it currently exists. But why is use of
> > CC0 necessary? If some work of the US government is in the public
> > domain by virtue of the Copyright Act, there is no need to use
> > CC0. Indeed, I would think use of CC0 by the Government is just as
> > problematic, or non-problematic, as the use of any open source
> > license, such as the Apache License 2.0. Strictly speaking, the use of
> > CC0 assumes that you have copyright ownership.
> >
> > Only noting this because the fact that OSI has not approved CC0 makes
> > this more complicated than the case where CC0 is not used at all.
> >
> > The code.mil folks discussed an earlier version of this approach with
> > the OSI. But this is the first I've heard of using CC0.
> >
> > Richard
> >
> >
> >
> >
> > On Tue, Feb 28, 2017 at 04:23:12PM +, Karan, Cem F CIV USARMY 
> > RDECOM ARL (US) wrote:
> > > All, the folks at code.mil came up with what may be a really, really 
> > good
> > > idea; see
> > > 
> > Caution-https://github.com/deptofdefense/code.mil/blob/master/Proposal/CONTRIBUTING.md.
> > >
> > > The basic idea is simple; when the Government releases code, it's in 
> > the
> > > public domain (likely CC0).  The project owners select an OSI-approved
> > > license, and will only accept contributions to the project under 
> > their chosen
> > > license[1].  Over time the code base becomes a mixture, some of which 
> > is under
> > > CC0, and some of which is under the OSI-approved license.  I've 
> > talked with
> > > ARL's lawyers, and they are satisfied with this solution.  Would OSI 
> > be happy
> > > with this solution?  That is, would OSI recognize the projects as 
> > being truly
> > > Open Source, right from the start?  The caveat is that some projects 
> > will be
> > > 100% CC0 at the start, and can only use the chosen Open Source 
> > license on
> > > those contributions that have copyright attached.  Note that 
> > Government
> > > projects that wish to make this claim would have to choose their 
> > license and
> > > announce it on the project site so that everyone knows what they are 
> > l

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

2017-03-01 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
I see your points about the Apache license vs. CC0, but the reason CC0 is more 
palatable is because we're not trying to make any restrictions based on 
copyright.  We're trying to meet the spirit of US law, and our lawyers believe 
that CC0 has the best chance of doing that.

As to your second point, that is PRECISELY what I'm proposing.  The material 
that has copyright attached will be accepted under the OSI-approved license 
that the project controllers wish to use, and all other material will be 
distributed under CC0.  This way the US Government is not claiming copyright 
where none exists.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Richard Fontana
> Sent: Wednesday, March 01, 2017 11:25 AM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: Possible alternative 
> was: Re: U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
>
> 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.
>
>
>
>
> ----
>
> On Wed, Mar 01, 2017 at 03:45:06PM +, Karan, Cem F CIV USARMY RDECOM ARL 
> (US) wrote:
> > Two reasons.  First is for the disclaimer of liability and warranty.
> > We can write our own notice, but that would be much less recognizable
> > than CC0, which is why we'd prefer to use it.
>
> But my point is that it is arguably inconsistent to say you can't use the 
> Apache License 2.0 but can use CC0, which, for example, contains a
> waiver and fallback copyright license. To put it another way, the public 
> domain that CC0 attempts to achieve is not the same thing as the
> public domain of US government civil servant works.
>
> Anyway looking at some of the closed issues for code.mil it seems they have 
> the same concerns about CC0 that you have about the
> Apache License.
>
> > Second, it solves the question of copyright in foreign jurisdictions;
> > as far as is possible, the work is in the public domain everywhere,
> > which means that someone in (for example) Canada can treat it the same way 
> > as someone in the US
> > would.   If you're wondering how this could be a problem, the issue is 
> > that
> > copyright is a grant by the State at the time of creation, but each
> > State has different rules about this.  As an example, works that I
> > create as a civil servant do not have copyright within the US, but may
> > have copyright protections in Canada unless specifically disclaimed.
> > This could lead to questions about whether or not the code could be
> > merged into a project if the project is being used world-wide, because
> > the license for the US Government furnished code is unclear.  CC0
> > settles the question as far as possible across all jurisdictions, and
> > as long as all external contributions are under the chosen
> > OSI-approved license, all material in a project will be covered by one
> > or the other, and decisions can be made by the courts in any jurisdiction 
> > on the project as a whole.
>
> The approach I understand code.mil to be taking is that a given project will 
> have an open source license and that license will cover
> anything that isn't statutory public domain, including both contributions 
> coming in through the DCO and code released by the US
> government that may be public domain in the US but not elsewhere.
>
> See: 
> Caution-https://github.com/deptofdefense/code.mil/blob/master/Proposal/CONTRIBUTING.md#1-license
>
>
>
>
>
>
>
>
>
> >
> > Note that I am not a lawyer, and none of this should be construed as
> > legal advice.
> >
> > Thanks,
> > Cem Karan
> >
> > > -Original Message-
> > > From: License-discuss
> > > [Caution-mailto:license-discuss-boun...@opensource.org] On Behalf Of
> > > Richard Fontana
> > > Sent: Wednesday, March 01, 2017 9:37 AM
> > > To: license-discuss@opensource.org
> > > Subject: [Non-DoD Source] Re: [License-discuss] Possible alternative 
> > > was:
> > > Re: U.S. Army Research Laboratory Open Source License (ARL
> > > OSL) Version 0.4.1
> > >
> > > 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] [Non-DoD Source] Re: Possible alternative was: Re: U.S. Army Research Laboratory Open Source License (ARL OSL) Version 0.4.1

2017-03-01 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
Two reasons.  First is for the disclaimer of liability and warranty.  We can 
write our own notice, but that would be much less recognizable than CC0, which 
is why we'd prefer to use it.

Second, it solves the question of copyright in foreign jurisdictions; as far 
as is possible, the work is in the public domain everywhere, which means that 
someone in (for example) Canada can treat it the same way as someone in the US 
would.   If you're wondering how this could be a problem, the issue is that 
copyright is a grant by the State at the time of creation, but each State has 
different rules about this.  As an example, works that I create as a civil 
servant do not have copyright within the US, but may have copyright 
protections in Canada unless specifically disclaimed.  This could lead to 
questions about whether or not the code could be merged into a project if the 
project is being used world-wide, because the license for the US Government 
furnished code is unclear.  CC0 settles the question as far as possible across 
all jurisdictions, and as long as all external contributions are under the 
chosen OSI-approved license, all material in a project will be covered by one 
or the other, and decisions can be made by the courts in any jurisdiction on 
the project as a whole.

Note that I am not a lawyer, and none of this should be construed as legal 
advice.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Richard Fontana
> Sent: Wednesday, March 01, 2017 9:37 AM
> To: license-discuss@opensource.org
> Subject: [Non-DoD Source] Re: [License-discuss] Possible alternative was: 
> Re: U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
>
> 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.
>
>
>
>
> 
>
> I really like the approach as it currently exists. But why is use of
> CC0 necessary? If some work of the US government is in the public domain by 
> virtue of the Copyright Act, there is no need to use CC0.
> Indeed, I would think use of CC0 by the Government is just as problematic, 
> or non-problematic, as the use of any open source license, such
> as the Apache License 2.0. Strictly speaking, the use of
> CC0 assumes that you have copyright ownership.
>
> Only noting this because the fact that OSI has not approved CC0 makes this 
> more complicated than the case where CC0 is not used at all.
>
> The code.mil folks discussed an earlier version of this approach with the 
> OSI. But this is the first I've heard of using CC0.
>
> Richard
>
>
>
>
> On Tue, Feb 28, 2017 at 04:23:12PM +, Karan, Cem F CIV USARMY RDECOM ARL 
> (US) wrote:
> > All, the folks at code.mil came up with what may be a really, really
> > good idea; see
> > Caution-https://github.com/deptofdefense/code.mil/blob/master/Proposal/CONTRIBUTING.md.
> >
> > The basic idea is simple; when the Government releases code, it's in
> > the public domain (likely CC0).  The project owners select an
> > OSI-approved license, and will only accept contributions to the
> > project under their chosen license[1].  Over time the code base
> > becomes a mixture, some of which is under CC0, and some of which is
> > under the OSI-approved license.  I've talked with ARL's lawyers, and
> > they are satisfied with this solution.  Would OSI be happy with this
> > solution?  That is, would OSI recognize the projects as being truly
> > Open Source, right from the start?  The caveat is that some projects
> > will be 100% CC0 at the start, and can only use the chosen Open Source
> > license on those contributions that have copyright attached.  Note
> > that Government projects that wish to make this claim would have to
> > choose their license and announce it on the project site so that
> > everyone knows what they are licensing their contributions under, which is 
> > the way that OSI can validate that the project is keeping its
> end of the bargain at the start.
> >
> > If this will satisfy OSI, then I will gladly withdraw the ARL OSL from
> > consideration.  If there are NASA or other Government folks on here,
> > would this solution satisfy your needs as well?
> >
> > Thanks,
> > Cem Karan
> >
> > [1] There is also a form certifying that the contributor has the right
> > to do so, etc.  The Army Research Laboratory's is at
> > Caution-https://github.com/USArmyResearchLab/ARL-Open-Source-Guidance-
> > and-Instructions/blob/master/ARL%20Form%20-%20266.pdf

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

2017-03-01 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
Hi all, I want to keep this question at the forefront of discussion; the next 
Federal Source Code Policy group meeting is this Thursday, and if this 
solution is acceptable to OSI, then this can become a part of the Federal 
policy going forwards.

Thanks,
Cem Karan

> -Original Message-
> From: Karan, Cem F CIV USARMY RDECOM ARL (US)
> Sent: Tuesday, February 28, 2017 11:23 AM
> To: license-discuss@opensource.org
> Subject: Possible alternative was: Re: U.S. Army Research Laboratory Open 
> Source License (ARL OSL) Version 0.4.1
>
> All, the folks at code.mil came up with what may be a really, really good
> idea; see
> https://github.com/deptofdefense/code.mil/blob/master/Proposal/CONTRIBUTING.md.
>
> The basic idea is simple; when the Government releases code, it's in the
> public domain (likely CC0).  The project owners select an OSI-approved
> license, and will only accept contributions to the project under their 
> chosen
> license[1].  Over time the code base becomes a mixture, some of which is 
> under
> CC0, and some of which is under the OSI-approved license.  I've talked with
> ARL's lawyers, and they are satisfied with this solution.  Would OSI be 
> happy
> with this solution?  That is, would OSI recognize the projects as being 
> truly
> Open Source, right from the start?  The caveat is that some projects will be
> 100% CC0 at the start, and can only use the chosen Open Source license on
> those contributions that have copyright attached.  Note that Government
> projects that wish to make this claim would have to choose their license and
> announce it on the project site so that everyone knows what they are 
> licensing
> their contributions under, which is the way that OSI can validate that the
> project is keeping its end of the bargain at the start.
>
> If this will satisfy OSI, then I will gladly withdraw the ARL OSL from
> consideration.  If there are NASA or other Government folks on here, would
> this solution satisfy your needs as well?
>
> Thanks,
> Cem Karan
>
> [1] There is also a form certifying that the contributor has the right to do
> so, etc.  The Army Research Laboratory's is at
> https://github.com/USArmyResearchLab/ARL-Open-Source-Guidance-and-Instructions/blob/master/ARL%20Form%20-%20266.pdf,
> and is, unfortunately, only able to be opened in Adobe Acrobat.  We're 
> working
> to fix that, but there are other requirements that will take some time.


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] [Non-DoD Source] Re: Possible alternative was: Re: U.S. Army Research Laboratory Open Source License (ARL OSL) Version 0.4.1

2017-02-28 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
ARL's policy (see 
https://github.com/USArmyResearchLab/ARL-Open-Source-Guidance-and-Instructions#433214A2C17C11E6952E003EE1B763F8)
 
cover this.  External contributions would be covered by the OSI-approved 
license, so the patent/IP terms in that license will cover those patent 
rights.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Gervase Markham
> Sent: Tuesday, February 28, 2017 12:17 PM
> To: license-discuss@opensource.org
> Subject: [Non-DoD Source] Re: [License-discuss] Possible alternative was: 
> Re: U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
>
> 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.
>
>
>
>
> 
>
> On 28/02/17 17:09, Smith, McCoy wrote:
> > You should consider the fact that CC0 has an express disclaimer of
> > patent licenses (in Section 4.a).  That may mean that it doesn't
> > address one of the concerns that I think you had (i.e., that there
> > might be USG patents covering the non-US copyrightable USG work
> > distributed by the USG).
> >
> > The CC licenses are also not on the OSI list (although there has been
> > some discussion in the past of whether they should be added, IIRC).
>
> Any objections to CC-0 also seemed to be patent-related; if the scheme had a 
> patent grant accompanying the CC-0 license, that might
> solve both of these issues in one go and lead to something very, very good.
>
> Gerv
>
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> Caution-https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss


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] [Non-DoD Source] Re: Possible alternative was: Re: U.S. Army Research Laboratory Open Source License (ARL OSL) Version 0.4.1

2017-02-28 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
As a part of ARL's internal release process, the Lab waives all patent/IP 
rights (except for the ARL trademarks).  That only leaves the external 
contributions, which would be done under one of the OSI-approved licenses.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Smith, McCoy
> Sent: Tuesday, February 28, 2017 12:10 PM
> To: license-discuss@opensource.org
> Subject: [Non-DoD Source] Re: [License-discuss] Possible alternative was: 
> Re: U.S. Army Research Laboratory Open Source License (ARL
> OSL) Version 0.4.1
>
> 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.
>
>
>
>
> 
>
> You should consider the fact that CC0 has an express disclaimer of patent 
> licenses (in Section 4.a).  That may mean that it doesn't address
> one of the concerns that I think you had (i.e., that there might be USG 
> patents covering the non-US copyrightable USG work distributed by
> the USG).
>
> The CC licenses are also not on the OSI list (although there has been some 
> discussion in the past of whether they should be added, IIRC).
>
> -Original Message-
> From: License-discuss 
> [Caution-mailto:license-discuss-boun...@opensource.org] On Behalf Of Karan, 
> Cem F CIV USARMY RDECOM ARL
> (US)
> Sent: Tuesday, February 28, 2017 8:23 AM
> To: license-discuss@opensource.org
> Subject: [License-discuss] Possible alternative was: Re: U.S. Army Research 
> Laboratory Open Source License (ARL OSL) Version 0.4.1
>
> All, the folks at code.mil came up with what may be a really, really good 
> idea; see Caution-
> https://github.com/deptofdefense/code.mil/blob/master/Proposal/CONTRIBUTING.md.
>
> The basic idea is simple; when the Government releases code, it's in the 
> public domain (likely CC0).  The project owners select an OSI-
> approved license, and will only accept contributions to the project under 
> their chosen license[1].  Over time the code base becomes a
> mixture, some of which is under CC0, and some of which is under the 
> OSI-approved license.  I've talked with ARL's lawyers, and they are
> satisfied with this solution.  Would OSI be happy with this solution?  That 
> is, would OSI recognize the projects as being truly Open Source,
> right from the start?  The caveat is that some projects will be 100% CC0 at 
> the start, and can only use the chosen Open Source license on
> those contributions that have copyright attached.  Note that Government 
> projects that wish to make this claim would have to choose
> their license and announce it on the project site so that everyone knows 
> what they are licensing their contributions under, which is the
> way that OSI can validate that the project is keeping its end of the bargain 
> at the start.
>
> If this will satisfy OSI, then I will gladly withdraw the ARL OSL from 
> consideration.  If there are NASA or other Government folks on here,
> would this solution satisfy your needs as well?
>
> Thanks,
> Cem Karan
>
> [1] There is also a form certifying that the contributor has the right to do 
> so, etc.  The Army Research Laboratory's is at Caution-
> https://github.com/USArmyResearchLab/ARL-Open-Source-Guidance-and-Instructions/blob/master/ARL%20Form%20-%20266.pdf,
> and is, unfortunately, only able to be opened in Adobe Acrobat.  We're 
> working to fix that, but there are other requirements that will take
> some time.
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> Caution-https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss


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] [Non-DoD Source] The Federal Register Process

2017-02-27 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
Thank you for your understanding; I know that the process isn't fun, but if we 
can make it happen, then maybe, JUST MAYBE, we can also join Open Source, and 
not just open source.

Thank you all for your patience.

Thanks,
Cem Karan

> -Original Message-
> From: Lawrence Rosen [mailto:lro...@rosenlaw.com]
> Sent: Monday, February 27, 2017 4:28 PM
> To: Karan, Cem F CIV USARMY RDECOM ARL (US) <cem.f.karan@mail.mil>; 
> license-discuss@opensource.org
> Cc: Lawrence Rosen <lro...@rosenlaw.com>
> Subject: [Non-DoD Source] The Federal Register Process
>
> Cem, my previous email about the Federal Register process wasn't clear.
>
> It certainly starts as a proposal from your department's lawyers for a 
> formal legal policy of some sort.
>
> THEN it becomes a public process. THEN there are public hearings and 
> specific written feedback. THEN the arguments become relevant to
> the public.
>
> How that process concludes is up to democracy.
>
> But at least it won't be just a bunch of attorneys in a government 
> department who are worried that their public domain software might
> already be used as a part of open source software without any new license 
> confusion.
>
> I'm on YOUR side to see you join the open source community.
>
> /Larry
>
> P.S. I'm already dealing with Federal Register activities relating to the 
> National Organic Program. I know how lengthy and confusing such
> regulations can become.
>
>
> -Original Message-
> From: Karan, Cem F CIV USARMY RDECOM ARL (US) 
> [mailto:cem.f.karan@mail.mil]
> Sent: Monday, February 27, 2017 1:13 PM
> To: lro...@rosenlaw.com; license-discuss@opensource.org
> Subject: RE: [License-discuss] [Non-DoD Source] Re: U.S. Army Research 
> Laboratory Open Source License (ARL OSL) Version 0.4.1
>
> OK, I've pushed it forward to the guys in charge of code.gov and the Federal 
> Source Code policy; I'll bring it up with them on Thursday as
> well.  I don't know if they'll support it, nor do I know if I'm allowed to 
> point the list to where the comments are[1], but if I am, I'll aim
> everyone there.  My only request is that everyone tries to get **all** their 
> points in on the first round; that way we can limit the number
> of rounds we have to go through on the Federal Register (each round takes 
> months to complete).
>
> Thanks,
> Cem Karan
>
> [1] I'd be **very** surprised if I wasn't allowed to tell people about 
> something in the Federal Register, but the law can be... unexpected.
>
> > -Original Message-
> > From: License-discuss [mailto:license-discuss-boun...@opensource.org]
> > On Behalf Of Lawrence Rosen
> > Sent: Monday, February 27, 2017 3:54 PM
> > To: license-discuss@opensource.org
> > Cc: Lawrence Rosen <lro...@rosenlaw.com>
> > Subject: Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research
> > Laboratory Open Source License (ARL OSL) Version 0.4.1
> >
> > 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.
> >
> >
> > 
> >
> >
> >
> >
> > Cem Karan wrote:
> >
> > > The Federal Register process may be the best way forwards.  I'll
> > > bring it up in the next Federal Source Code policy meeting.
> >
> >
> >
> > That may be a good solution. The Federal Register process requires
> > public notice; public hearings; public feedback; written proposals
> > based on legal reasoning; etc. It is not an in-house in-government
> > discussion. :-)
> >
> >
> >
> > /Larry
>



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] [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) Version 0.4.1

2017-02-27 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
OK, I've pushed it forward to the guys in charge of code.gov and the Federal 
Source Code policy; I'll bring it up with them on Thursday as well.  I don't 
know if they'll support it, nor do I know if I'm allowed to point the list to 
where the comments are[1], but if I am, I'll aim everyone there.  My only 
request is that everyone tries to get **all** their points in on the first 
round; that way we can limit the number of rounds we have to go through on the 
Federal Register (each round takes months to complete).

Thanks,
Cem Karan

[1] I'd be **very** surprised if I wasn't allowed to tell people about 
something in the Federal Register, but the law can be... unexpected.

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Lawrence Rosen
> Sent: Monday, February 27, 2017 3:54 PM
> To: license-discuss@opensource.org
> Cc: Lawrence Rosen 
> Subject: Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research 
> Laboratory Open Source License (ARL OSL) Version 0.4.1
>
> 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.
>
>
> 
>
>
>
>
> Cem Karan wrote:
>
> > The Federal Register process may be the best way forwards.  I'll bring it 
> > up in the next Federal Source Code policy meeting.
>
>
>
> That may be a good solution. The Federal Register process requires public 
> notice; public hearings; public feedback; written proposals
> based on legal reasoning; etc. It is not an in-house in-government 
> discussion. :-)
>
>
>
> /Larry



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] [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) Version 0.4.1

2017-02-27 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
What you just said (the paragraph about the FOIA exemption) seems to be spot 
on.  Our legal counsel **will not** comment on this list.  Full stop.

The Federal Register process may be the best way forwards.  I'll bring it up 
in the next Federal Source Code policy meeting.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Stephen Michael Kellat
> Sent: Monday, February 27, 2017 2:11 PM
> To: license-discuss@opensource.org
> Cc: lro...@rosenlaw.com; license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research 
> Laboratory Open Source License (ARL OSL) Version 0.4.1
>
> 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.
>
>
>
>
> 
>
> I am off-duty from my job over at Treasury today so I guess I can say 
> something.  Standard disclaimer incorporated by reference from
> presentation here: 
> Caution-http://skellat.freeshell.org/blog/pages/about-this-blog.html
>
> 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.
>
> 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.
>
> Stephen Michael Kellat
>
> On Mon, 27 Feb 2017 10:42:59 -0800
> "Lawrence Rosen" <lro...@rosenlaw.com> wrote:
>
> > Cem Karan wrote:
> >
> > > As for our legal counsel posting to this list directly, they've told
> > > me in the past that they won't do that because it violates some
> > > statute or contract clause[1].
> >
> > [1] I'm not sure what exactly, they've explained it to me, but I keep
> > forgetting the finer details.
> >
> >
> >
> > I apologize for again writing to you, Cem, since you are doing a great
> > job at this thread, but it is the only way I know to get my message to
> > your attorneys:
> >
> >
> >
> > Their behavior in funneling their license to this public list via a
> > non-lawyer is insulting to those of us on this list who are lawyers
> > and who well understand the law of copyright and open source. They are
> > also insulting the non-lawyers on this list who know more about open
> > source licenses than most lawyers in your government agency apparently
> > do. Please ask them to talk to us as professionals.
> >
> >
> >
> > As far as some "statute or contract clause" that would prevent a
> > lawyer from justifying his or her own submission of a license to this
> > public open source mail list, I doubt that!
> >
> >
> >
> > I am personally so frustrated at this unnecessary barrier that I might
> > file a FOIA request to force them to speak up publicly about their
> > public legal issue that concerns all of us who use the Apache license
> > with public domain components in our software. That's not the way the
> > open source community works out such issues.
> >
> >
> >
> > /Larry
> >
> >
> >
> > Lawrence Rosen
> >
> > Rosenlaw (Caution-www.rosenlaw.com)
> >
> > 3001 King Ranch Rd., Ukiah, CA 95482
> >
> > Cell: 707-478-8932
> >
> >
> >
> > -Original Message-
> > From: License-discuss
> > [Caution-mailto:license-discuss-boun...@opensource.org]
> > On Behalf Of Karan, Cem F CIV USARMY RDECOM ARL (US) Sent: Monday,
> > February 27, 2017 10:10 AM To: lro...@rosenlaw.com;
> > license-discuss@opensource.org Subject: Re: [License-discuss] [Non-DoD
> > Source] Re: U.S. Army Research Laboratory Open Source License (ARL
> > OSL) Version 0.4.1
> >
> >
> >
> > I've forwarded your question to

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

2017-02-27 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
I've already gotten in contact with her, and I'm hoping to have a face to face 
with either her or someone else from DDS (the people behind code.mil) on 
Thursday at the next Federal Source Code Policy meeting.  Thank you for looking 
her up though!

As for punting it upstairs, I've been pushing everyone I can on this.  My 
feeling is that ARL is leading most of the Government in terms of figuring it 
out at this point, and that means that our analysis is where we're at.  So, if 
you have case law or Federal law that I can look at that says we can **safely** 
use the standard OSI-approved licenses on works that don't have copyright 
attached, please let me know.  And remember that 'safely' in this context means 
that the license's terms remain valid even though the work is in the public 
domain.

Thanks,
Cem Karan

> -Original Message-
> From: Tzeng, Nigel H. [mailto:nigel.tz...@jhuapl.edu]
> Sent: Monday, February 27, 2017 1:53 PM
> To: license-discuss@opensource.org; Karan, Cem F CIV USARMY RDECOM ARL (US) 
> <cem.f.karan@mail.mil>
> Cc: feedb...@dds.mil; sharon.wo...@dds.mil
> Subject: Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research 
> Laboratory Open Source License (ARL OSL) Version 0.4.1
> 
> 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.
> 
> 
> 
> 
> 
> 
> 
> Cem, Sharon Woods is the counsel on the DDS.  That’s probably not her email 
> address above…it’s just a shot in the dark.  But maybe
> feedb...@dds.mil will get you the right email or she might join this 
> discussion.:)
> 
> 
> 
> I still say ARL should punt the problem upstairs and let OSD, DISA or 
> Department of Army create a suitable open source agreement for all
> of DoD.  On first reading I don’t think the Defense Open Source Agreement 
> meets your needs though.
> 
> 
> 
> From: License-discuss <license-discuss-boun...@opensource.org> on behalf of 
> "Smith, McCoy" <mccoy.sm...@intel.com>
> Reply-To: License Discuss <license-discuss@opensource.org>
> Date: Monday, February 27, 2017 at 1:01 PM
> To: "lro...@rosenlaw.com" <lro...@rosenlaw.com>, License Discuss 
> <license-discuss@opensource.org>, "'Karan, Cem F CIV USARMY
> RDECOM ARL (US)'" <cem.f.karan@mail.mil>
> Subject: Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research 
> Laboratory Open Source License (ARL OSL) Version 0.4.1
> 
> 
> 
> For what it’s worth (I think it is generally pretty relevant), the DoD 
> published a draft “Agreement” that is intended to address the issue of
> there being no US copyright in works authored by the US Government:
> 
> 
> Caution-https://github.com/deptofdefense/code.mil/blob/master/Proposal/LICENSE-agreement.md#draft-defense-open-source-
> agreement < 
> Caution-https://github.com/deptofdefense/code.mil/blob/master/Proposal/LICENSE-agreement.md#draft-defense-open-
> source-agreement >
> 
> 
> 
> I find that Agreement somewhat strange in that it says it is an Agreement 
> (and a license) and then refers back to an associated open
> source license appended to the software, but it seems to me that what they 
> are trying to get at is essentially converting the appended
> open source license into a contract to the extent that there is 
> non-copyrighted material distributed by the DoD, such that all the
> provisions of the open source license would apply to that material but not 
> via license but instead via contract.
> 
> 
> 
> I would think that it might be worth synching up the folks who are writing 
> the ARL OSL with the folks promulgating the draft DoD open
> source agreement, as they seem to be pursuing the same goal but in different 
> ways and through different channels.
> 
> 
> 
> 
> 
> From: License-discuss 
> [Caution-mailto:license-discuss-boun...@opensource.org]On Behalf Of Lawrence 
> Rosen
> Sent: Monday, February 27, 2017 9:50 AM
> To: 'Karan, Cem F CIV USARMY RDECOM ARL (US)'; license-discuss@opensource.org
> Cc: Lawrence Rosen
> Subject: Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research 
> Laboratory Open Source License (ARL OSL) Version 0.4.1
> 
> 
> 
> Cem Karan wrote:
> 
> > I'm not a lawyer, I'm not your lawyer, I don't pretend to be one on TV or 
> > anywhere else, and nothing I say should be construed as legal
> advice.
> 
> 
> 
> In that situation, it would be unfair to ask you my question directly, so 
> please forward my email directly to your lawyer(s). I'd like to hear
> f

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

2017-02-27 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
I've forwarded your frustrations onwards; I don't know what the response will 
be.

Thanks,
Cem Karan

> -Original Message-
> From: Lawrence Rosen [mailto:lro...@rosenlaw.com]
> Sent: Monday, February 27, 2017 1:43 PM
> To: license-discuss@opensource.org; Karan, Cem F CIV USARMY RDECOM ARL (US) 
> <cem.f.karan@mail.mil>
> Cc: Lawrence Rosen <lro...@rosenlaw.com>
> Subject: RE: [License-discuss] [Non-DoD Source] Re: U.S. Army Research 
> Laboratory Open Source License (ARL OSL) Version 0.4.1
>
> 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.
>
>
> 
>
>
>
>
> Cem Karan wrote:
>
> > As for our legal counsel posting to this list directly, they've told me in 
> > the past that they won't do that because it violates some statute
> or contract clause[1].
>
> [1] I'm not sure what exactly, they've explained it to me, but I keep 
> forgetting the finer details.
>
>
>
> I apologize for again writing to you, Cem, since you are doing a great job 
> at this thread, but it is the only way I know to get my message to
> your attorneys:
>
>
>
> Their behavior in funneling their license to this public list via a 
> non-lawyer is insulting to those of us on this list who are lawyers and who
> well understand the law of copyright and open source. They are also 
> insulting the non-lawyers on this list who know more about open
> source licenses than most lawyers in your government agency apparently do. 
> Please ask them to talk to us as professionals.
>
>
>
> As far as some "statute or contract clause" that would prevent a lawyer from 
> justifying his or her own submission of a license to this
> public open source mail list, I doubt that!
>
>
>
> I am personally so frustrated at this unnecessary barrier that I might file 
> a FOIA request to force them to speak up publicly about their
> public legal issue that concerns all of us who use the Apache license with 
> public domain components in our software. That's not the way
> the open source community works out such issues.
>
>
>
> /Larry
>
>
>
> Lawrence Rosen
>
> Rosenlaw (Caution-www.rosenlaw.com)
>
> 3001 King Ranch Rd., Ukiah, CA 95482
>
> Cell: 707-478-8932
>
>
>
> -Original Message-
> From: License-discuss 
> [Caution-mailto:license-discuss-boun...@opensource.org] On Behalf Of Karan, 
> Cem F CIV USARMY RDECOM ARL
> (US)
> Sent: Monday, February 27, 2017 10:10 AM
> To: lro...@rosenlaw.com; license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research 
> Laboratory Open Source License (ARL OSL) Version 0.4.1
>
>
>
> I've forwarded your question to our internal counsel, and I'm hoping to get 
> a message back in a day or two.  I'll post it when they get back
> to me.
>
>
>
> As for our legal counsel posting to this list directly, they've told me in 
> the past that they won't do that because it violates some statute or
> contract clause[1].  So, I apologize if I have to act as a filter, but that 
> is the best I can do at the moment.
>
>
>
> Thanks,
>
> Cem Karan
>
>
>
> [1] I'm not sure what exactly, they've explained it to me, but I keep 
> forgetting the finer details.
>
>
>
> > -Original Message-
>
> > From: Lawrence Rosen [Caution-mailto:lro...@rosenlaw.com < 
> > Caution-mailto:lro...@rosenlaw.com > ]
>
> > Sent: Monday, February 27, 2017 12:50 PM
>
> > To: Karan, Cem F CIV USARMY RDECOM ARL (US)
>
> > <cem.f.karan@mail.mil < Caution-mailto:cem.f.karan@mail.mil > >; 
> > license-discuss@opensource.org < Caution-mailto:license-
> disc...@opensource.org >
>
> > Cc: Lawrence Rosen <lro...@rosenlaw.com < 
> > Caution-mailto:lro...@rosenlaw.com > >
>
> > Subject: RE: [Non-DoD Source] Re: [License-discuss] U.S. Army Research
>
> > Laboratory Open Source License (ARL OSL) Version 0.4.1
>
> >
>
> > 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.
>
> >
>
> >
>
> > 
>
> >
>
> >
>
> >
>
> >
>
> > Cem Karan wrote:
>
> >
>
> > > I'm

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

2017-02-27 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
I've read it.  I've gotten in contact with the code.mil folks, and we'll be 
discussing it in person shortly.  

Thanks,
Cem Karan

> -Original Message-
> From: Smith, McCoy [mailto:mccoy.sm...@intel.com]
> Sent: Monday, February 27, 2017 1:01 PM
> To: lro...@rosenlaw.com; license-discuss@opensource.org; Karan, Cem F CIV 
> USARMY RDECOM ARL (US) <cem.f.karan@mail.mil>
> Subject: RE: [License-discuss] [Non-DoD Source] Re: U.S. Army Research 
> Laboratory Open Source License (ARL OSL) Version 0.4.1
> 
> 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.
> 
> 
> 
> 
> 
> 
> 
> For what it’s worth (I think it is generally pretty relevant), the DoD 
> published a draft “Agreement” that is intended to address the issue of
> there being no US copyright in works authored by the US Government:
> 
> 
> Caution-https://github.com/deptofdefense/code.mil/blob/master/Proposal/LICENSE-agreement.md#draft-defense-open-source-
> agreement < 
> Caution-https://github.com/deptofdefense/code.mil/blob/master/Proposal/LICENSE-agreement.md#draft-defense-open-
> source-agreement >
> 
> 
> 
> I find that Agreement somewhat strange in that it says it is an Agreement 
> (and a license) and then refers back to an associated open
> source license appended to the software, but it seems to me that what they 
> are trying to get at is essentially converting the appended
> open source license into a contract to the extent that there is 
> non-copyrighted material distributed by the DoD, such that all the
> provisions of the open source license would apply to that material but not 
> via license but instead via contract.
> 
> 
> 
> I would think that it might be worth synching up the folks who are writing 
> the ARL OSL with the folks promulgating the draft DoD open
> source agreement, as they seem to be pursuing the same goal but in different 
> ways and through different channels.
> 
> 
> 
> 
> 
> From: License-discuss 
> [Caution-mailto:license-discuss-boun...@opensource.org]On Behalf Of Lawrence 
> Rosen
> Sent: Monday, February 27, 2017 9:50 AM
> To: 'Karan, Cem F CIV USARMY RDECOM ARL (US)'; license-discuss@opensource.org
> Cc: Lawrence Rosen
> Subject: Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research 
> Laboratory Open Source License (ARL OSL) Version 0.4.1
> 
> 
> 
> Cem Karan wrote:
> 
> > I'm not a lawyer, I'm not your lawyer, I don't pretend to be one on TV or 
> > anywhere else, and nothing I say should be construed as legal
> advice.
> 
> 
> 
> In that situation, it would be unfair to ask you my question directly, so 
> please forward my email directly to your lawyer(s). I'd like to hear
> from them directly or on this list.
> 
> 
> 
> Cem Karan wrote:
> 
> . . . the truly serious issue is 
> severabilityCaution-https://en.wikipedia.org/wiki/Severability < Caution-
> https://en.wikipedia.org/wiki/Severability > ).  The concern is that if the 
> USG uses a license that depends on copyright (e.g., Apache 2.0),
> and those clauses are declared unenforceable by the courts, then it may be 
> possible to declare the entire license unenforceable.
> 
> 
> 
> Larry Rosen asked:
> 
> Apache-licensed software also may (and frequently does) contain public domain 
> components. Are you suggesting that "severability" is a
> potential problem with Apache software?
> 
> 
> 
> /Larry
> 
> 
> 
> Lawrence Rosen
> 
> Rosenlaw (Caution-www.rosenlaw.com < Caution-http://www.rosenlaw.com > )
> 
> 3001 King Ranch Rd., Ukiah, CA 95482
> 
> Cell: 707-478-8932



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] [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) Version 0.4.1

2017-02-27 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
I've forwarded your question to our internal counsel, and I'm hoping to get a 
message back in a day or two.  I'll post it when they get back to me.

As for our legal counsel posting to this list directly, they've told me in the 
past that they won't do that because it violates some statute or contract 
clause[1].  So, I apologize if I have to act as a filter, but that is the best 
I can do at the moment.

Thanks,
Cem Karan

[1] I'm not sure what exactly, they've explained it to me, but I keep 
forgetting the finer details.

> -Original Message-
> From: Lawrence Rosen [mailto:lro...@rosenlaw.com]
> Sent: Monday, February 27, 2017 12:50 PM
> To: Karan, Cem F CIV USARMY RDECOM ARL (US) <cem.f.karan@mail.mil>; 
> license-discuss@opensource.org
> Cc: Lawrence Rosen <lro...@rosenlaw.com>
> Subject: RE: [Non-DoD Source] Re: [License-discuss] U.S. Army Research 
> Laboratory Open Source License (ARL OSL) Version 0.4.1
>
> 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.
>
>
> 
>
>
>
>
> Cem Karan wrote:
>
> > I'm not a lawyer, I'm not your lawyer, I don't pretend to be one on TV or 
> > anywhere else, and nothing I say should be construed as legal
> advice.
>
>
>
> In that situation, it would be unfair to ask you my question directly, so 
> please forward my email directly to your lawyer(s). I'd like to hear
> from them directly or on this list.
>
>
>
> Cem Karan wrote:
>
> . . . the truly serious issue is severability 
> Caution-https://en.wikipedia.org/wiki/Severability < Caution-
> https://en.wikipedia.org/wiki/Severability > ).  The concern is that if the 
> USG uses a license that depends on copyright (e.g., Apache 2.0),
> and those clauses are declared unenforceable by the courts, then it may be 
> possible to declare the entire license unenforceable.
>
>
>
> Larry Rosen asked:
>
> Apache-licensed software also may (and frequently does) contain public 
> domain components. Are you suggesting that "severability" is a
> potential problem with Apache software?
>
>
>
> /Larry
>
>
>
> Lawrence Rosen
>
> Rosenlaw (Caution-www.rosenlaw.com)
>
> 3001 King Ranch Rd., Ukiah, CA 95482
>
> Cell: 707-478-8932



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] [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) Version 0.4.1

2017-02-27 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
There may be a difference between projects that had copyright initially and 
later on added in public domain components, and projects that never had 
copyright to begin with.  That said, I don't know if there is or isn't[1].  I 
don't want to find out that there **is** a difference, and have it bite 
everyone.  The lawyers I've worked with seem to think that there is a 
difference, and that we should account for it.  If you have case law or 
Federal laws that show that we don't have to worry about it, please show me, 
so I can pass it to our lawyers for review.  If they are convinced that we 
don't have to worry about it, I can drop the ARL OSL (which, to be honest, 
would make my life easier; it ain't fun getting yelled at by everyone on this 
list).  However, at this moment I have yet to find a Government lawyer that is 
100% comfortable with using a copyright-based license on projects that were 
originated by the USG and which don't have any copyright attached.  That's why 
we're currently suggesting CC0 for the ARL (see 
https://github.com/USArmyResearchLab/ARL-Open-Source-Guidance-and-Instructions);
 
right now, we think it has the best chance of standing up in court.  I'd much 
rather be proven wrong by US case law, or a Federal law, so we can go back to 
the standard OSI approved licenses.  Right now though, I'm stuck with CC0, or 
with pushing the ARL OSL and hoping it gets OSI approved.

Thanks,
Cem Karan

[1] I'm not a lawyer, I'm not your lawyer, I don't pretend to be one on TV or 
anywhere else, and nothing I say should be construed as legal advice.

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Lawrence Rosen
> Sent: Monday, February 27, 2017 12:22 PM
> To: license-discuss@opensource.org
> Cc: Lawrence Rosen <lro...@rosenlaw.com>
> Subject: [Non-DoD Source] Re: [License-discuss] U.S. Army Research 
> Laboratory Open Source License (ARL OSL) Version 0.4.1
>
> 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.
>
>
> 
>
>
>
>
> Cem Karan wrote:
>
> . . . the truly serious issue is severability 
> Caution-https://en.wikipedia.org/wiki/Severability < Caution-
> https://en.wikipedia.org/wiki/Severability > ).  The concern is that if the 
> USG uses a license that depends on copyright (e.g., Apache 2.0),
> and those clauses are declared unenforceable by the courts, then it may be 
> possible to declare the entire license unenforceable.
>
>
>
> Apache-licensed software also may (and frequently does) contain public 
> domain components. Are you suggesting that "severability" is a
> potential problem with Apache software?
>
>
>
> The US government isn't special.
>
>
>
> /Larry
>
>
>
>
>
> -Original Message-
> From: License-discuss 
> [Caution-mailto:license-discuss-boun...@opensource.org] On Behalf Of Karan, 
> Cem F CIV USARMY RDECOM ARL
> (US)
> Sent: Monday, February 27, 2017 9:01 AM
> To: license-discuss@opensource.org
> Subject: [License-discuss] U.S. Army Research Laboratory Open Source License 
> (ARL OSL) Version 0.4.1
>
>
>
> All, I've been asked to republish the U.S. Army Research Laboratory Open 
> Source License (ARL OSL) once again so that others can read it.
> This is the most current copy.  It is based off of the Apache 2.0 license 
> that can be found at Caution-
> http://www.apache.org/licenses/LICENSE-2.0.txt < 
> Caution-http://www.apache.org/licenses/LICENSE-2.0.txt > , and is intended 
> to make
> US Government (USG) works released under it completely interoperable with 
> the Apache 2.0 license, while still dealing with the fact that
> most USG works do not have copyright protections.  See further down this 
> message as to why this is necessary.
>
>
>
> The goals of the license are as follows:
>
>
>
> - Protect the USG, contributors, and users of all work licensed under the 
> license against lawsuits in the same manner that the Apache 2.0
> license protects those groups when works have copyright.
>
>
>
> - Be interoperable with Apache 2.0.  Ideally, there would be no airgap 
> between the ARL OSL and Apache 2.0, however because USG works
> don't have copyright, there will be some airgap.  For works that have 
> copyright, the Apache 2.0 license is preferable.  If a project is
> licensed under the ARL OSL, it should be able to accept works that are 
> licensed under the Apache 2.0 license, **and the contribution
> should be able to remain licensed under Apache 2.0**.  This will mean that 
> p

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

2017-02-27 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
All, I've been asked to republish the U.S. Army Research Laboratory Open 
Source License (ARL OSL) once again so that others can read it.  This is the 
most current copy.  It is based off of the Apache 2.0 license that can be 
found at http://www.apache.org/licenses/LICENSE-2.0.txt, and is intended to 
make US Government (USG) works released under it completely interoperable with 
the Apache 2.0 license, while still dealing with the fact that most USG works 
do not have copyright protections.  See further down this message as to why 
this is necessary.

The goals of the license are as follows:

- Protect the USG, contributors, and users of all work licensed under the 
license against lawsuits in the same manner that the Apache 2.0 license 
protects those groups when works have copyright.

- Be interoperable with Apache 2.0.  Ideally, there would be no airgap between 
the ARL OSL and Apache 2.0, however because USG works don't have copyright, 
there will be some airgap.  For works that have copyright, the Apache 2.0 
license is preferable.  If a project is licensed under the ARL OSL, it should 
be able to accept works that are licensed under the Apache 2.0 license, **and 
the contribution should be able to remain licensed under Apache 2.0**.  This 
will mean that portions of the USG sponsored project will be relicensed under 
ARL OSL and other portions under Apache 2.0.  I don't know if the ARL OSL 
meets those goals, if anyone sees a problem with this interpretation, please 
say so.

- Protect Open Source.  That is, the ARL OSL should meet the Open Source 
Definition at https://opensource.org/osd.  If the ARL OSL doesn't meet these 
requirements, then it needs to be corrected.

For those that don't know why we're pushing a new license/agreement, this is a 
quick recap of the problems (search through the mailing list archives to see 
more of what the problems are if you're interested).

In most cases, the USG doesn't allow itself to have copyright on USG-produced 
works within the US.  This means that if a license has clauses that depend on 
copyright for enforcement, then those clauses are likely unenforceable, at 
least for those portions of the code that were USG-produced.  By itself, this 
probably wouldn't be a major problem; the truly serious issue is severability 
(https://en.wikipedia.org/wiki/Severability).  The concern is that if the USG 
uses a license that depends on copyright (e.g., Apache 2.0), and those clauses 
are declared unenforceable by the courts, then it may be possible to declare 
the entire license unenforceable.  If you read the Apache 2.0 license, you'll 
notice that the Apache Foundation did an (IMHO) excellent job of dealing with 
liability, warranty, and IP rights, protecting not only groups accepting 
contributions, but also all downstream users.  Losing that protection could 
harm not only the USG, but also all downstream users as a flurry of litigation 
happens.  This could cause a chilling effect on the USG, making upper 
management far less interested in participating in Open Source, or even 
permitting USG works to be released as Open Source.

I personally don't want to see that happen.  I want to ensure that Open Source 
remains Open Source, and that the gates to litigation Hell remain firmly 
closed.  This is why I'm not willing to risk using copyright-based licenses on 
works that don't have copyright attached.  If you believe that this isn't a 
concern, I respect your opinion, but I'd like to see case law, or better yet, 
Federal law that prevents this sort of problem from popping up.  So far, 
neither I, nor the lawyers at ARL, nor the lawyers at the Justice department 
have been able to find any case law or laws explaining what would happen in 
such a case.  If you know of such laws or case law, please let me know.

For those that believe these concerns are invalid, I'd like to issue a 
challenge to you; would you be willing to enter into a binding contract with 
the USG indemnifying it and its agents against the problems outlined above? 
That is, if the USG uses a copyright-based license on works it produces that 
have no copyright attached, and that license is declared invalid because the 
works have no copyright attached, would you be willing to indemnify the 
USG[1]?  If you aren't, then you may wish to reconsider your arguments against 
having another license/agreement put in place.

[1] I do not have the authority to negotiate on behalf of the USG, and these 
are not negotiations.  This is just a strawman argument to make everyone 
**really think** about the issues facing the USG, and why we're being so 
careful in what we're doing.

Thanks,
Cem Karan

"""
U.S. Army Research Laboratory Open Source License (ARL OSL)
   Version 0.4.1, August 2016
http://no/URL/as/yet

   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

   1. Definitions.

  "License" shall mean the terms and conditions for use, 

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

2017-02-16 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
Beyond that, is the FSF interested in compatibility between non-FSF licenses? 
That is, if MIT and Apache 2.0 happened to be incompatible with one another, 
would FSF care provided they were both compatible with the GPL?  In my 
opinion, OSI is supposed to be more neutral on the matters, and therefore 
should care more about such situations.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Tzeng, Nigel H.
> Sent: Wednesday, February 15, 2017 7:04 PM
> To: license-discuss@opensource.org
> Subject: [Non-DoD Source] Re: [License-discuss] OSI equivalent
>
> 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.
>
>
> 
>
>
>
> Because there is often a compatibility discussion with new license 
> submissions and because the confusion among developers regarding
> OSS license compatibility comes up about once a year.
>
> For example in 2013 it was brought up in the discussion on NOSA 2.0
>
> Caution-https://lists.opensource.org/pipermail/license-review/2013-June/001948.html
>  
> < Caution-
> https://lists.opensource.org/pipermail/license-review/2013-June/001948.html 
>  >
>
> And a major objective of EUPL 1.2 was for increased interoperability between 
> EUPL and other licenses
>
> Caution-https://lists.opensource.org/pipermail/license-review/2013-March/001874.html
>  
> < Caution-
> https://lists.opensource.org/pipermail/license-review/2013-March/001874.html 
>  >
>
> And more recently for LiLiQ there was discussion on its' compatibility with 
> CDDl and MPL
>
> Caution-https://lists.opensource.org/pipermail/license-review/2015-October/002586.html
>  
> < Caution-
> https://lists.opensource.org/pipermail/license-review/2015-October/002586.html
>  >
>
> And I brought up compatibility between the recently proposed ESA licenses 
> and NOSA.
>
> And incompatibility is mentioned as part of the proliferation project:
>
>
> 1....
> 2.some licenses do not play well together
>   Some people use "license proliferation" to refer to the fact that some 
> open 
> source licenses do not inter-operate well with other
> open source licenses. While we can urge people not to mix non-mixable 
> licenses, we cannot keep people from doing so. This comment
> generally came from larger companies.
>
> Caution-https://opensource.org/proliferation < 
> Caution-https://opensource.org/proliferation >
>
> Caution-https://opensource.org/proliferation-report < 
> Caution-https://opensource.org/proliferation-report >
>
> In what way is license interoperability/compatibility ONLY a FSF issue and 
> not also an OSI one?
>
>
> From: Richard Fontana <font...@sharpeleven.org < 
> Caution-mailto:font...@sharpeleven.org > >
> Date: Wednesday, Feb 15, 2017, 5:56 PM
> To: license-discuss@opensource.org <license-discuss@opensource.org < 
> Caution-mailto:license-discuss@opensource.org > >
> Subject: Re: [License-discuss] OSI equivalent
>
> License compatibility is mostly an FSF-made and GPL-specific doctrine. I 
> can't see how it would make any sense for the OSI to provide
> guidance on license compatibility beyond acknowledging (as the OSI 
> occasionally has done) the FSF's authority on the topic.
>
>
>
>
> On Wed, Feb 15, 2017 at 10:46:39PM +, Tzeng, Nigel H. wrote:
> > So what is the point of the OSI if it cannot do a simple up or down vote 
> > on a license submission from NASA after 3 years or provide any
> compatibility guidance on the licenses it managed to approve in the distant 
> past?
> >
> > Especially if the FSF has no problems in providing such guidance?
> >
> > From: David Woolley
> > <for...@david-woolley.me.uk<Caution-mailto:for...@david-woolley.me.uk>
> > >
> > Date: Wednesday, Feb 15, 2017, 4:17 PM
> > To: license-discuss@opensource.org
> > <license-discuss@opensource.org<Caution-mailto:license-discuss@opensou
> > rce.org>>
> > Subject: Re: [License-discuss] OSI equivalent
> >
> > On 15/02/17 16:58, Karan, Cem F CIV USARMY RDECOM ARL (US) wrote:
> > > Does OSI have a license compatibility chart for the various approved 
> > > licenses?
> >
> > I would have thought that any such document would constitute legal
> > advice, which is illegal for half the list members to provide, and the
> > other half would only provide in the c

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

2017-02-15 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Christopher Sean Morrison
> Sent: Wednesday, February 15, 2017 2:17 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: OSI equivalent
> 
>   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:  
> Caution-https://en.wikipedia.org/wiki/License_compatibility#Compatibility_of_FOSS_licenses
>  <
> Caution-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:
> 
> Caution-https://support.office.com/en-us/article/Block-or-unblock-automatic-picture-downloads-in-email-messages-15e08854-6808-
> 49b1-9a0a-50b81f2d617a < 
> Caution-https://support.office.com/en-us/article/Block-or-unblock-automatic-picture-downloads-in-email-
> messages-15e08854-6808-49b1-9a0a-50b81f2d617a >

Thank you for the URL, that worked.  And I've seen that diagram before, but it 
doesn't give enough information about full compatibility between licenses.  The 
web page is better though, and the FSF page seems to be the best currently 
available.

Thanks,
Cem Karan



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] [Non-DoD Source] Re: OSI equivalent

2017-02-15 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
Got it.  Thank you!  The URL will be helpful in this case then.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Kevin Fleming
> Sent: Wednesday, February 15, 2017 2:05 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: OSI equivalent
> 
> 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.
> 
> 
> 
> 
> 
> 
> I see the image in his email, so it was indeed sent out by the list server. 
> It must have been eaten by something on your end, unfortunately.
> It might be best to send a URL to where it can be found instead.
> 
> 
> On Wed, Feb 15, 2017 at 10:35 AM, Karan, Cem F CIV USARMY RDECOM ARL (US) 
> <cem.f.karan@mail.mil < Caution-
> mailto:cem.f.karan@mail.mil > > wrote:
> 
> 
>   > -Original Message-
>   > From: License-discuss 
> [Caution-mailto:license-discuss-boun...@opensource.org < 
> Caution-mailto:license-discuss-
> boun...@opensource.org > ] On Behalf Of Christopher Sean Morrison
>   > Sent: Wednesday, February 15, 2017 1:06 PM
>   > To: License Discussion Mailing List <license-discuss@opensource.org < 
> Caution-mailto:license-discuss@opensource.org > >
>   > Subject: [Non-DoD Source] Re: [License-discuss] OSI equivalent
>   >
>   >   On Feb 15, 2017, at 11:58 AM, Karan, Cem F CIV USARMY RDECOM 
> ARL (US) <cem.f.karan@mail.mil < Caution-
> mailto:cem.f.karan@mail.mil >  < Caution-
>   > Caution-mailto:cem.f.karan@mail.mil < 
> Caution-mailto:cem.f.karan@mail.mil >  > > wrote:
>   >
>   >   Does OSI have a license compatibility chart for the various 
> approved licenses?
>   >   Something similar to 
> Caution-Caution-https://www.gnu.org/licenses/license-list.html < Caution-
> https://www.gnu.org/licenses/license-list.html >  < 
> Caution-Caution-https://www.gnu.org/licenses/license- < Caution-
> 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
> 
>   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 L

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

2017-02-15 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Christopher Sean Morrison
> Sent: Wednesday, February 15, 2017 1:06 PM
> To: License Discussion Mailing List <license-discuss@opensource.org>
> Subject: [Non-DoD Source] Re: [License-discuss] OSI equivalent
> 
>   On Feb 15, 2017, at 11:58 AM, Karan, Cem F CIV USARMY RDECOM ARL (US) 
> <cem.f.karan@mail.mil < Caution-
> mailto:cem.f.karan@mail.mil > > wrote:
> 
>   Does OSI have a license compatibility chart for the various approved 
> licenses?
>   Something similar to 
> Caution-https://www.gnu.org/licenses/license-list.html < 
> Caution-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

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?

Thanks,
Cem Karan


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


[License-discuss] OSI equivalent

2017-02-15 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
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.

Thanks,
Cem Karan


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] [Non-DoD Source] notes on a systematic approach to "popular" licenses

2017-01-10 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
Got it, thank you for the clarification.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Luis Villa
> Sent: Tuesday, January 10, 2017 2:01 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] notes on a systematic 
> approach to "popular" licenses
> 
> I may not have been clear - under this proposal, the "special purpose 
> licenses" category would continue to exist, and could be used for
> licenses like the ones you describe, Cem. Same with categories with more 
> negative connotation, like "redundant", non-reusable,
> superseded, etc.
> 
> 
> It's not entirely clear what level of scrutiny should be applied to new 
> licenses proposed in these older categories. I tend to think less
> (reserving the highest scrutiny for those proposed as significantly 
> innovative general-purpose licenses), but Richard may tend to think
> more, and I've not thought it through very carefully.
> 
> 
> Luis
> 
> 
> On Tue, Jan 10, 2017 at 10:28 AM Karan, Cem F CIV USARMY RDECOM ARL (US) 
> <cem.f.karan@mail.mil < Caution-
> mailto:cem.f.karan@mail.mil > > wrote:
> 
> 
>   I agree with the idea of this, but there will always be niche licenses 
> that are needed and won't make it into the popular list.  E.g.,
> licenses that can be used on public domain software (like US Government 
> works, which generally don't have copyright).  These will need
> to be handled carefully, as for some of us these are the only licenses we're 
> permitted to use, but we'd still like to be Open Sourcing our
> stuff.  So, is there a method of weighting the list based on unavoidable 
> factors?
> 
>   Thanks,
>   Cem Karan
> 
>   > -Original Message-
>   > From: License-discuss 
> [Caution-mailto:license-discuss-boun...@opensource.org < 
> Caution-mailto:license-discuss-
> boun...@opensource.org > ] On Behalf Of Luis Villa
>   > Sent: Tuesday, January 10, 2017 11:08 AM
>   > To: License Discuss <license-discuss@opensource.org < 
> Caution-mailto:license-discuss@opensource.org > >
>   > Subject: [Non-DoD Source] [License-discuss] notes on a systematic 
> approach to "popular" licenses
>   >
>   > 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.
>   >
>   >
>   > 
>   >
>   >
>   >
>   > [Apparently I got unsubscribed at some point, so if you've sent an 
> email here in recent months seeking my feedback, please
> resend.]
>   >
>   >
>   > Hey, all-
>   >
>   > I promised some board members a summary of my investigation in 
> '12-'13 into updating, supplementing, or replacing the
> "popular
>   > licenses" list. Here goes.
>   >
>   >
>   > tl;dr
>   >
>   > I think OSI should have an data-driven short license list with a 
> replicable and transparent methodology, supplemented by a new-
> and-
>   > good(?) list that captures licenses that aren't yet popular but are 
> high quality and have some substantial improvement that
> advances the
>   > goals of OSI.
>   >
>   >
>   > Purposes of non-comprehensive lists
>   >
>   > If you Google "open source licenses", OSI pages are the top two hits. 
> Historically, those pages were not very helpful unless you
> already
>   > knew something about open source. Having a shorter "top" list can 
> help make the OSI website more useful to newcomers by
> suggesting a
>   > starting place for their exploration and education about open source.
>   >
>   > In addition, third parties often look to OSI as a trusted (neutral?) 
> source for "top" or "best" licenses that they can incorporate
> into
>   > products. (The full OSI-approved list is not practical for many 
> applications.) For example, if OSI had an up-to-date short list, it
> might have
>   > been the basis for GitHub's license chooser.
>   >
>   >
>   > A list that is purely based on popularity would freeze open source in 
> a particular time, likely making it hard for new licenses with
>   > important innovations to get adoption. However, 

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

2017-01-10 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
I agree with the idea of this, but there will always be niche licenses that are 
needed and won't make it into the popular list.  E.g., licenses that can be 
used on public domain software (like US Government works, which generally don't 
have copyright).  These will need to be handled carefully, as for some of us 
these are the only licenses we're permitted to use, but we'd still like to be 
Open Sourcing our stuff.  So, is there a method of weighting the list based on 
unavoidable factors?

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Luis Villa
> Sent: Tuesday, January 10, 2017 11:08 AM
> To: License Discuss 
> Subject: [Non-DoD Source] [License-discuss] notes on a systematic approach to 
> "popular" licenses
> 
> 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.
> 
> 
> 
> 
> 
> 
> [Apparently I got unsubscribed at some point, so if you've sent an email here 
> in recent months seeking my feedback, please resend.]
> 
> 
> Hey, all-
> 
> I promised some board members a summary of my investigation in '12-'13 into 
> updating, supplementing, or replacing the "popular
> licenses" list. Here goes.
> 
> 
> tl;dr
> 
> I think OSI should have an data-driven short license list with a replicable 
> and transparent methodology, supplemented by a new-and-
> good(?) list that captures licenses that aren't yet popular but are high 
> quality and have some substantial improvement that advances the
> goals of OSI.
> 
> 
> Purposes of non-comprehensive lists
> 
> If you Google "open source licenses", OSI pages are the top two hits. 
> Historically, those pages were not very helpful unless you already
> knew something about open source. Having a shorter "top" list can help make 
> the OSI website more useful to newcomers by suggesting a
> starting place for their exploration and education about open source.
> 
> In addition, third parties often look to OSI as a trusted (neutral?) source 
> for "top" or "best" licenses that they can incorporate into
> products. (The full OSI-approved list is not practical for many 
> applications.) For example, if OSI had an up-to-date short list, it might have
> been the basis for GitHub's license chooser.
> 
> 
> A list that is purely based on popularity would freeze open source in a 
> particular time, likely making it hard for new licenses with
> important innovations to get adoption. However, a list based on more 
> subjective criteria is hard to create and update.
> 
> 
> Past attempts
> 
> The proliferation report attempted to address this problem by categorizing 
> existing licenses. These categories were, intentionally or not,
> seen as the "popular or strong communities list" and "everything else". 
> Without a process or clear set of criteria to update the "popular"
> list, however, it became frozen in time. It is now difficult to credibly 
> recommend the list to newcomers or third parties (MPL 1.1 is
> deprecated; no mention of Blackduck #4 GPL v3; etc.).
> 
> 
> There was also substantial work done towards a license "chooser" or "wizard". 
> However, this runs into some of the same problems - either
> the chooser is opinionated (and so pisses off people, and potentially locks 
> the licenses in time) or is borderline-useless for newcomers
> (because it still requires substantial additional research after using it).
> 
> 
> Data-driven "popular" list
> 
> 
> With all that in mind, I think that OSI needs a (mostly) data-driven 
> "popular" shortlist, based on a scan of public code + application of
> (mostly?) objective rules to the outcome of that scan.
> 
> 
> To maintain OSI's reputation as being (reasonably) neutral and independent, 
> OSI should probably avoid basing this on third-party license
> surveys (e.g., Black Duck < 
> Caution-https://www.blackducksoftware.com/top-open-source-licenses > ) unless 
> their methodologies and data
> sources are well-documented. Ideally someone will write code so that the 
> "survey" can be run by OSI and reproduced by others.
> 
> Hard decisions on how to collect and "process" the data will include:
> 
> 
> * choice of data sources: What data sources are drawn on? Key Linux 
> distros? GitHub? per-language repos like maven, cpan, npm,
> etc?
> 
> * what are you counting? Projects? (May favor small, throwaway projects?) 
> Lines of code? (May favor the largest, most complex
> projects?) ... ?
> 
> * which license tools? Some scanners are more aggressive in trying to 
> identify something, while others prefer accuracy over
> comprehensiveness. In 2013 there was no good answer to this, but my 
> understanding is that fossology now has three different scanners,
> so for OSI's purposes it may 

Re: [License-discuss] [Non-DoD Source] Groups/Communities

2017-01-04 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
Hi Patrick, if you poke through the archives for the license-discuss mailing 
list, you'll find some discussion under ARL Open Source license.  There is 
also some discussion at the very bottom of 
https://github.com/presidential-innovation-fellows/code-gov-web/issues/41, and 
https://github.com/presidential-innovation-fellows/code-gov-web/issues/28 
discusses the advice that we're getting/giving to some degree.  Most of the 
other discussion that I've been a part of (I'm a US Government employee) has 
been at various meetings that aren't open to the public.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Patrick Masson
> Sent: Wednesday, January 04, 2017 2:25 PM
> To: license-discuss@opensource.org
> Subject: [Non-DoD Source] [License-discuss] Groups/Communities
>
> 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.
>
>
> 
>
>
>
> All,
>
> Could you please point me to any organizations, groups, lists, etc. 
> discussing open source licenses and other legal issues related to open
> source software that you find valuable.
>
> Thank you,
> Patrick
>
> --
>
> |||  |  |||||  |||||||
> Patrick Masson
> General Manager & Director
> Open Source Initiative
> 855 El Camino Real, Ste 13A, #270
> Palo Alto, CA 94301
> United States
> OSI Phone: (415) 857-5398 < tel:%28415%29%20857-5398 > Direct Phone: (970) 
> 4MASSON
> Skype: massonpj
> Em: mas...@opensource.org < Caution-mailto:mas...@opensource.org >
> Ws: Caution-www.opensource.org < Caution-http://www.opensource.org/ >


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] [Non-DoD Source] Re: Views on React licensing?

2016-12-13 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Tzeng, Nigel H.
> Sent: Tuesday, December 13, 2016 1:28 PM
> To: license-discuss@opensource.org
> Subject: [Non-DoD Source] Re: [License-discuss] Views on React licensing?
> 
> On 12/13/16, 12:07 PM, "License-discuss on behalf of Richard Fontana"
>  
> wrote:
> 
> >If the US government standardizes on some particular explicit patent
> >language to use with CC0 I would welcome OSI review of that.
> >
> >Richard
> 
> The point is that the implementers of the open source policy within the 
> federal government doesn¹t care that CC0 isn¹t OSI approved.  Nor
> do they have standing to submit CC0 anyway so Creative Commons would have to 
> do so.
> 
> Why would they bother?  The FSF already recommends CC0 for public domain 
> release and so does the US government (or a notable part
> of it anyway).
> 
> I also doubt that any patent grant drafted by US government lawyers would be 
> broad but necessarily nuanced so it wouldn¹t fare any
> better than NOSA v2.0.  I¹m curious, when is the next board meeting and are 
> you going to allow an up or down vote on NOSA at that
> meeting?

I am VERY interested in this; I will be attending the USG Open Source policy 
meeting on Thursday, if someone can tell me where NOSA 2.0 is at this point, I 
could fill in everyone else there.

Thanks,
Cem Karan


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] [Non-DoD Source] Re: Views on React licensing?

2016-12-05 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Henrik Ingo
> Sent: Monday, December 05, 2016 6:55 AM
> To: license-discuss@opensource.org
> Subject: [Non-DoD Source] Re: [License-discuss] Views on React licensing?
>
> On Fri, Dec 2, 2016 at 6:26 AM, Richard Fontana  
> wrote:
> > - 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 should of course be discouraged. However, I sympathize with this kind 
> of setup if it is intended to be a proposal for a license that
> doesn't yet exist. If Facebook a) intends for the combined license to 
> qualify as open source, and b) eventually submit it for OSI approval,
> then it seems to me this is a natural path towards such a goal.

If it is discouraged, then OSI will need to start accepting more licenses into 
the fold.  I brought up the problems that the US Government has with regards 
to copyright, which is why we developed a new license based on Apache 2.0.  It 
was roundly criticized as not being necessary, and at this point, I suspect 
we're probably going to be going with CC0 + Patent release, in much the same 
way as React has.  That will probably cause license fracturing in a way that I 
don't think OSI or anyone in the Open Source community wants.

Thanks,
Cem Karan



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] [Non-DoD Source] The License Talking-About List

2016-08-25 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
We've used GitLab before, and we like it as well.  Might be a good way to go 
too.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Rick Moen
> Sent: Wednesday, August 24, 2016 6:29 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] The License Talking-About 
> List
>
> 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.
>
>
>
>
> 
>
> [cross-post to license-review, snipped.]
>
> Quoting Karan, Cem F CIV USARMY RDECOM ARL (US) (cem.f.karan@mail.mil):
>
> > What about GitHub?
>
> Using a proprietary hosting platform for outsourced tracking of open-source 
> licenses?  Could work, but that risks punishment by the Gods
> of Irony.
>
>
> BTW, at $WORK, we found the open-source workalike platform GitLab to our 
> liking.  Caution-https://about.gitlab.com/
>
> --
> Cheers,"An idealist is one who, on noticing that a 
> rose
> Rick Moen  smells better than a cabbage, concludes that 
> it
> r...@linuxmafia.commakes a better soup."
> McQ! (4x80)-- H.L. Mencken, _A Book of 
> Burlesque_
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> Caution-https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss


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] [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

2016-08-24 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Tzeng, Nigel H.
> Sent: Monday, August 22, 2016 5:02 PM
> 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
> 
> Caution-https://opensource.org/approval
> 
> Yep, you get to start this all over again. :)
> 
> A lot of folks do read both lists so it¹s probably not a huge deal. 

*WHEW!* :)

Thanks,
Cem Karan


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] [Non-DoD Source] The License Talking-About List

2016-08-24 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
What about GitHub?  There have been suggestions on the Python-ideas list to do 
this for any new python ideas.  The idea is simple; each license becomes its 
own project.  Issues can then be tracked via the issue tracker, making it easy 
to segregate the issues into individual threads, and as issues are corrected 
or ended, the issue is closed and the git commit where the issue was dealt 
with can be noted in the issue itself.  Finally, as long as we're dealing with 
a pure-text version of the license, we get all the power of git; diffs, forks, 
merges, etc.,

Would this work for everyone?

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Lawrence Rosen
> Sent: Monday, August 22, 2016 5:51 PM
> To: license-discuss@opensource.org; 'License submissions for OSI review' 
> <license-rev...@opensource.org>
> Cc: Lawrence Rosen <lro...@rosenlaw.com>
> Subject: [Non-DoD Source] [License-discuss] The License Talking-About List
>
> 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.
>
>
> 
>
>
>
>
> Cem Karan wrote:
>
> > I'm aware of the other list, but my understanding was that it had to be 
> > submitted to this list for discussion first, and then submitted to
> license-review once there was some consensus; am I wrong about this?
>
>
>
> Cem, please don't feel bad about your confusion. I've been around these 
> lists for years and I still get confused about their differences. You
> can't talk about license A without comparing it to license B, but those 
> discussions may involve different email lists, at OSI and at FSF and
> at CC. And for additional confusion, lots of FOSS organizations like OSI 
> move discussions from list to list merely to discuss everything a
> second time. It often permanently delays the decision (like the NASA and CC0 
> licenses have been delayed here). That was also often my
> email experience at Apache.
>
>
>
> Someone ought to invent a better solution than email lists to analyze 
> licenses and reach decisions.
>
>
>
> /Larry
>
>
>
> -Original Message-
> From: Karan, Cem F CIV USARMY RDECOM ARL (US) 
> [Caution-mailto:cem.f.karan@mail.mil]
> Sent: Monday, August 22, 2016 1:46 PM
> 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
>
> 



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] [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

2016-08-24 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
OK, so it's the way I thought.  First, propose a license on this list for 
discussion, but the actual review takes place on the license-review mailing 
list.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Richard Fontana
> Sent: Monday, August 22, 2016 5:04 PM
> 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
> 
> Yes, that is mistaken. This list plays no role in the OSI license approval 
> process, though it can be an appropriate place to discuss a license
> that has not been submitted for OSI approval.
> 
> Richard
> 
> 
> On Mon, Aug 22, 2016 at 08:45:41PM +, Karan, Cem F CIV USARMY RDECOM ARL 
> (US) wrote:
> > I'm aware of the other list, but my understanding was that it had to be 
> > submitted to this list for discussion first, and then submitted to
> license-review once there was some consensus; am I wrong about this?
> >
> > Thanks,
> > Cem Karan
> >
> > > -Original Message-
> > > From: License-discuss
> > > [Caution-mailto:license-discuss-boun...@opensource.org] On Behalf Of
> > > Richard Fontana
> > > Sent: Monday, August 22, 2016 2:53 PM
> > > 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
> > >
> > > 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.
> > >
> > >
> > >
> > >
> > > 
> > >
> > > I'm not sure if you're already aware but for several years this
> > > mailing list has not been used for discussing licenses submitted for
> > > OSI approval -- that is done on the license-review mailing list. The 
> > > license review process is described at Caution- Caution-
> https://opensource.org/approval.
> > >
> > > I haven't followed this thread too closely but it is clear that the
> > > ARL OSL is very different from NOSA 2.0. The only way to see whether it 
> > > would merit OSI approval (if that's what you are seeking)
> would be to submit it for review.
> > >
> > > Richard
> > >
> > >
> > > On Mon, Aug 22, 2016 at 05:14:59PM +, Karan, Cem F CIV USARMY RDECOM 
> > > ARL (US) wrote:
> > > > OK, so assuming that the NOSA 2.0 license is dead in the water,
> > > > what about the ARL OSL?  Is it also, dead, and if so, why?  Leave
> > > > aside
> > > the license proliferation aspect, and focus on what needs to be changed 
> > > with the ARL OSL to make it acceptable.
> > > >
> > > > Thanks,
> > > > Cem Karan
> > > >
> > > > > -Original Message-
> > > > > From: License-discuss
> > > > > [Caution-Caution-mailto:license-discuss-boun...@opensource.org]
> > > > > On Behalf Of Richard Fontana
> > > > > Sent: Saturday, August 20, 2016 10:21 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
> > > > >
> > > > > 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.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 
> > > > >
> > > > > On Sat, Aug 20, 2016 at 02:24:53AM +, Tzeng, Nigel H. wrote:
> > > > > > My understanding then and now was that it had become clear to
> > > > > > them that Richard and Bruce was going to stall approval for a
> > > > > > long time/forever unless they took out the patent clause that
> > > > > > the open data folks wanted. So they withdrew because they were
> > > > > > never going to do that and

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

2016-08-22 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
I'm aware of the other list, but my understanding was that it had to be 
submitted to this list for discussion first, and then submitted to 
license-review once there was some consensus; am I wrong about this?

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Richard Fontana
> Sent: Monday, August 22, 2016 2:53 PM
> 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
> 
> 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.
> 
> 
> 
> 
> 
> 
> I'm not sure if you're already aware but for several years this mailing list 
> has not been used for discussing licenses submitted for OSI
> approval -- that is done on the license-review mailing list. The license 
> review process is described at Caution-
> https://opensource.org/approval.
> 
> I haven't followed this thread too closely but it is clear that the ARL OSL 
> is very different from NOSA 2.0. The only way to see whether it
> would merit OSI approval (if that's what you are seeking) would be to submit 
> it for review.
> 
> Richard
> 
> 
> On Mon, Aug 22, 2016 at 05:14:59PM +, Karan, Cem F CIV USARMY RDECOM ARL 
> (US) wrote:
> > OK, so assuming that the NOSA 2.0 license is dead in the water, what about 
> > the ARL OSL?  Is it also, dead, and if so, why?  Leave aside
> the license proliferation aspect, and focus on what needs to be changed with 
> the ARL OSL to make it acceptable.
> >
> > Thanks,
> > Cem Karan
> >
> > > -Original Message-
> > > From: License-discuss
> > > [Caution-mailto:license-discuss-boun...@opensource.org] On Behalf Of
> > > Richard Fontana
> > > Sent: Saturday, August 20, 2016 10:21 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
> > >
> > > 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.
> > >
> > >
> > >
> > >
> > > 
> > >
> > > On Sat, Aug 20, 2016 at 02:24:53AM +, Tzeng, Nigel H. wrote:
> > > > My understanding then and now was that it had become clear to them
> > > > that Richard and Bruce was going to stall approval for a long
> > > > time/forever unless they took out the patent clause that the open
> > > > data folks wanted. So they withdrew because they were never going
> > > > to do that and the discussions were getting more and more heated.
> > >
> > > I'm assuming 'Richard' is me and 'Bruce' is Bruce Perens. Neither of
> > > us were on the OSI board at that time; we were just participants on
> > > a mailing list. Also, I don't recall Bruce Perens' involvement in
> > > the
> > > CC0 discussion at all, but my objective was to encourage the OSI
> > > take a consistent approach to the problem of nonstandard provisions
> > > dealing with patents, having remembered the discussion of the MXM license 
> > > in ~2009, rather than an approach that would be
> explainable solely by attitudes towards the license steward.
> > >
> > > > If you don¹t believe that was a correct assessment on their part
> > > > then pray tell the status of NOSA v2 that was originally submitted
> > > > for approval in 2013.
> > >
> > > That's a special, unfortunate case. With NOSA 2.0 I continued (and
> > > sort of continue) to feel that the license was salvageable with a lot of 
> > > work, which no one (including me and I think including NASA)
> seems to have the time or inclination to take on individually or collectively.
> > > Possibly, in retrospect, the better approach with NOSA
> > > 2.0 would have been to outright reject it as being way too complex
> > > with a number of likely or actual fatal problems. An issue there was
> > > that, until recently, I assumed that the OSI customarily does not
> > > formally reject licenses, as opposed to just not approving those
> > > that are problematic

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

2016-08-22 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
OK, so assuming that the NOSA 2.0 license is dead in the water, what about the 
ARL OSL?  Is it also, dead, and if so, why?  Leave aside the license 
proliferation aspect, and focus on what needs to be changed with the ARL OSL to 
make it acceptable.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Richard Fontana
> Sent: Saturday, August 20, 2016 10:21 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
> 
> 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.
> 
> 
> 
> 
> 
> 
> On Sat, Aug 20, 2016 at 02:24:53AM +, Tzeng, Nigel H. wrote:
> > My understanding then and now was that it had become clear to them
> > that Richard and Bruce was going to stall approval for a long
> > time/forever unless they took out the patent clause that the open data
> > folks wanted. So they withdrew because they were never going to do
> > that and the discussions were getting more and more heated.
> 
> I'm assuming 'Richard' is me and 'Bruce' is Bruce Perens. Neither of us were 
> on the OSI board at that time; we were just participants on a
> mailing list. Also, I don't recall Bruce Perens' involvement in the
> CC0 discussion at all, but my objective was to encourage the OSI take a 
> consistent approach to the problem of nonstandard provisions
> dealing with patents, having remembered the discussion of the MXM license in 
> ~2009, rather than an approach that would be explainable
> solely by attitudes towards the license steward.
> 
> > If you don¹t believe that was a correct assessment on their part then
> > pray tell the status of NOSA v2 that was originally submitted for
> > approval in 2013.
> 
> That's a special, unfortunate case. With NOSA 2.0 I continued (and sort of 
> continue) to feel that the license was salvageable with a lot of
> work, which no one (including me and I think including NASA) seems to have 
> the time or inclination to take on individually or collectively.
> Possibly, in retrospect, the better approach with NOSA
> 2.0 would have been to outright reject it as being way too complex with a 
> number of likely or actual fatal problems. An issue there was
> that, until recently, I assumed that the OSI customarily does not formally 
> reject licenses, as opposed to just not approving those that are
> problematic (holding out the possibility of the license steward submitting 
> revisions or improvements). I think that is actually true of
> licenses submitted in the past several years, but I recently learned that in 
> the distant past there were licenses the OSI actually formally
> rejected.
> 
> Even now, I still think NOSA 2.0 can be fixed without revising it beyond all 
> recognition. However, I pointed out at least one significant
> problem (related, in fact, to the MXM/CC0 patent provisions issue) and it did 
> not seem that Bryan was receptive to discussing it. Even if
> the OSI did have at least an earlier history of rejecting licenses, I believe 
> it's true that revised versions of problematic submitted licenses
> have generally been prepared by the license steward rather than that task 
> being taken on by the OSI itself. That is, it would be strange if
> the only way to get an acceptable version of NOSA 2.0 would be for the OSI to 
> take on primary responsibility for drafting it.
> 
> Richard
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> Caution-https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
 U.S. Army Research Laboratory Open Source License (ARL OSL)
   Version 0.4.1, August 2016
http://no/URL/as/yet

   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

   1. Definitions.

  "License" shall mean the terms and conditions for use, reproduction,
  and distribution as defined by Sections 1 through 10 of this document.

  "Licensor" shall mean the project originator or entity authorized by
  the project originator that is granting the License.

  "Legal Entity" shall mean the union of the acting entity and all
  other entities that control, are controlled by, or are under common
  control with that entity. For the purposes of this definition,
  "control" means (i) the power, direct or indirect, to cause the
  direction or management of such entity, whether by contract or
  otherwise, or (ii) ownership of fifty percent (50%) or more of the
  outstanding shares, or (iii) beneficial ownership of such entity.

  "You" (or "Your") shall mean an individual or Legal Entity
  exercising 

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

2016-08-19 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
Exactly.  Anyone that gets something from the USG deserves to know that they 
won't be facing a patent lawsuit from any of the contributors.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Chris DiBona
> Sent: Thursday, August 18, 2016 6:12 PM
> To: license-discuss@opensource.org
> Cc: Lawrence Rosen 
> 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
> 
> 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.
> 
> 
> 
> 
> 
> 
> 
> In military contracting , patent grants are key to the point where I wouldn't 
> consider a non patent granting license from, say, lockheed as
> being open source at all.
> 
> 
> On Aug 18, 2016 3:05 PM, "Tzeng, Nigel H."  Caution-mailto:nigel.tz...@jhuapl.edu > > wrote:
> 
> 
>   On 8/18/16, 3:57 PM, "License-discuss on behalf of Lawrence Rosen"
>    Caution-mailto:license-discuss-boun...@opensource.org >  on behalf of
> lro...@rosenlaw.com < Caution-mailto:lro...@rosenlaw.com > >
>   wrote:
> 
> 
>   >Nigel Tzeng wrote:
>   >> The issue here is for code that is potentially quite substantial.  I
>   >>would think that would be a different scenario.
>   >
>   >If I include the works of Shakespeare in my software, it would of 
> course
>   >be substantial and yet still be public domain almost everywhere (?).
> 
>   If patents aren't a concern then okay.  Copyright lasts longer than
>   patents so for anything that is in the public domain because of age then
>   no patents would still apply.
> 
>   There isn¹t a lot of code that has aged out.  Only code written between
>   before 1963 and didn¹t get a renewal.
> 
>   ___
>   License-discuss mailing list
>   License-discuss@opensource.org < 
> Caution-mailto:License-discuss@opensource.org >
>   
> Caution-https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss 
> < Caution-https://lists.opensource.org/cgi-
> bin/mailman/listinfo/license-discuss >
> 



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] [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

2016-08-19 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
We apply for and are granted patents on a regular basis at ARL.  In fact, part 
of how scientists and engineers are evaluated on their performance can include 
the number of patents they get, all of which are owned by the USG.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Brian Behlendorf
> Sent: Thursday, August 18, 2016 8:46 PM
> To: ch...@dibona.com; license-discuss@opensource.org
> Cc: Lawrence Rosen 
> 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
> 
> 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.
> 
> 
> 
> 
> 
> 
> 
> Totally agree.  But can the USG file patents?  I suppose research 
> organizations can (MITRE, maybe even NASA?) so it's not that academic;
> but presumably any place where this public domain arises, it applies to 
> patents too.  Would be nice to get that sorted.
> 
> Brian
> 
> On Thu, 18 Aug 2016, Chris DiBona wrote:
> > In military contracting , patent grants are key to the point where I 
> > wouldn't consider a non patent granting license from, say, lockheed as
> being open source at all.
> >
> >
> > On Aug 18, 2016 3:05 PM, "Tzeng, Nigel H."  wrote:
> >   On 8/18/16, 3:57 PM, "License-discuss on behalf of Lawrence Rosen"
> >    > lro...@rosenlaw.com>
> >   wrote:
> >
> >
> >   >Nigel Tzeng wrote:
> >   >> The issue here is for code that is potentially quite substantial.  
> > I
> >   >>would think that would be a different scenario.
> >   >
> >   >If I include the works of Shakespeare in my software, it would of 
> > course
> >   >be substantial and yet still be public domain almost everywhere (?).
> >
> >   If patents aren't a concern then okay.  Copyright lasts longer than
> >   patents so for anything that is in the public domain because of age 
> > then
> >   no patents would still apply.
> >
> >   There isn¹t a lot of code that has aged out.  Only code written 
> > between
> >   before 1963 and didn¹t get a renewal.
> >
> >   ___
> >   License-discuss mailing list
> >   License-discuss@opensource.org
> >
> > Caution-https://lists.opensource.org/cgi-bin/mailman/listinfo/license-
> > discuss
> >
> >
> >


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] [Non-DoD Source] Re: [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

2016-08-18 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
There likely will be some USG-only discussion beforehand, but since there are 
a lot of people to coordinate on this, the sooner I get started, the better.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Tzeng, Nigel H.
> Sent: Thursday, August 18, 2016 5:00 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: [Non-DoD Source] Re: 
> [Non-DoD Source] Re: U.S. Army Research Laboratory Open
> Source License (ARL OSL) 0.4.0
>
> 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.
>
>
>
>
> 
>
> Why not limit it to USG lawyers? That may be an easier sell for a first 
> meeting.  Especially if you can convince someone at the OMB to host
> the telcon because of the new policy and get the relevant DOJ lawyers to 
> dial in.
>
>
> It is too much to expect clear guidance (this is the government after all) 
> but it would at least be useful if the lawyers that approved the
> release of code.gov under CC0 could tell your lawyers why they thought it 
> was sufficient.  Especially if these are the same set of lawyers
> providing legal guidance to the White House OMB 20% OSS mandate.
>
> On 8/18/16, 4:36 PM, "License-discuss on behalf of Karan, Cem F CIV USARMY 
> RDECOM ARL (US)"  boun...@opensource.org on behalf of cem.f.karan@mail.mil> wrote:
>
> >Larry, I agree with you completely about the need for all attorneys
> >talking to one another, while us engineers sit back and listen.  I'm
> >going to try to talk the various attorneys in the USG that I've
> >contacted into being part of a telecon.  If I'm able to do so, are
> >there any attorneys on this list who would be interested in taking part
> >in that discussion?  If you are, please email me directly; put "ARL OSL
> >telecon" as the subject line, and tell me what times are best for you
> >relative to the Eastern Time Zone.
> >
> >PLEASE NOTE!  That telecon MUST be for attorneys ONLY!  I may be able
> >to convince the ARL attorneys to talk to outside attorneys, but they
> >will be VERY unhappy if anyone else is coming in on the line.  There
> >are good legal reasons for this; please don't try to sneak in.
> >
> >Thanks,
> >Cem Karan
>
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> Caution-https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss


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] [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

2016-08-18 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Tzeng, Nigel H.
> Sent: Thursday, August 18, 2016 4:26 PM
> To: Lawrence Rosen ; 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
> 
> >Cem Karan wrote:
> 
> >> The only reason that the ARL OSL was proposed AT ALL is because there is a 
> >> strong concern that since USG code doesn't have copyright
> [1], any license that relies exclusively on copyright may be invalidated by 
> the courts [2].
> 
> 
> 
> >We understand that strong concern. Most of us don't share it.
> 
> 
> Well, if all lawyers agreed then IP cases would go a lot more quickly, no?
> 
> Plaintiff’s lawyer: We think X!
> Defendant’s lawyer: We agree!
> 
> I don’t believe that there is an OSD requirement that the lawyers on 
> License-Review/License-Discuss agree that the legal concern being
> addressed by a new license submission is valid.  Especially when other 
> lawyers disagree.
> 
> Given that NOSA is still in limbo, it might be fair (not really given how 
> long NOSA has been in limbo) to ask that ARL and NASA lawyers get
> together and address their concerns in one special purpose license since both 
> are trying to address legal concerns they believe are valid for
> USG OSS projects.  Although, with the current white house interest, both NASA 
> and ARL could punt the issue up to the Tony Scott at the
> OMB (or whomever Chris suggested) and say “here are our requirements…give us 
> a FedGov OSS license that address those needs and
> submit it to the OSI".
> 
> And then approve (or deny) that license quickly once submitted If it passes 
> the OSD and retire the existing NOSA license rather than sit on
> it for three years without resolution.  Hopefully, if the White House submits 
> a license to the OSI it is reviewed with a bit more alacrity.

Actually, we ARE in talks with NASA; the attorney at ARL that is working on 
this used to work at NASA, and so knows the right people to talk to over there.

Thanks,
Cem Karan


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] [Non-DoD Source] Re: [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

2016-08-18 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
Larry, I agree with you completely about the need for all attorneys talking to 
one another, while us engineers sit back and listen.  I'm going to try to talk 
the various attorneys in the USG that I've contacted into being part of a 
telecon.  If I'm able to do so, are there any attorneys on this list who would 
be interested in taking part in that discussion?  If you are, please email me 
directly; put "ARL OSL telecon" as the subject line, and tell me what times 
are best for you relative to the Eastern Time Zone.

PLEASE NOTE!  That telecon MUST be for attorneys ONLY!  I may be able to 
convince the ARL attorneys to talk to outside attorneys, but they will be VERY 
unhappy if anyone else is coming in on the line.  There are good legal reasons 
for this; please don't try to sneak in.

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Lawrence Rosen
> Sent: Thursday, August 18, 2016 2:15 PM
> To: license-discuss@opensource.org
> Cc: Lawrence Rosen <lro...@rosenlaw.com>
> Subject: [Non-DoD Source] Re: [License-discuss] [Non-DoD Source] Re: 
> [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source
> License (ARL OSL) 0.4.0
>
> 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.
>
>
> 
>
>
>
>
> Cem Karan wrote:
>
> > The only reason that the ARL OSL was proposed AT ALL is because there is a 
> > strong concern that since USG code doesn't have copyright
> [1], any license that relies exclusively on copyright may be invalidated by 
> the courts [2].
>
>
>
> We understand that strong concern. Most of us don't share it.
>
>
>
> Many of us have noted that NO FOSS LICENSE relies exclusively on copyright 
> law. That argument was made here on this list years ago. No
> court anywhere has ever decided a FOSS case without also using CONTRACT 
> interpretation rules.
>
>
>
> We also noted that MOST FOSS SOFTWARE already contains public domain 
> components. Perhaps ALL FOSS SOFTWARE, considering that
> engineers often claim copyright on more than they deserve.
>
>
>
> Our U.S. Army software is no different: Portions copyright; portions not.
>
>
>
> We attorneys here will try to convince your attorneys of that if they 
> consent to speak to us. You engineers should not volunteer to be
> translators in that discussion, but listen in. And we attorneys should speak 
> candidly about copyright and contract law. Several of us are
> specialists, and several here have already volunteered to have that legal 
> chat with your counsel.
>
>
>
> /Larry
>
>
>
> Lawrence Rosen
>
> Rosenlaw (Caution-www.rosenlaw.com)
>
> 3001 King Ranch Rd., Ukiah, CA 95482
>
> Cell: 707-478-8932
>
>
>
>
>
> -Original Message-
> From: Karan, Cem F CIV USARMY RDECOM ARL (US) 
> [Caution-mailto:cem.f.karan@mail.mil]
> Sent: Thursday, August 18, 2016 10:52 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
>
>
>
> The only reason that the ARL OSL was proposed AT ALL is because there is a 
> strong concern that since USG code doesn't have copyright
> [1], any license that relies exclusively on copyright may be invalidated by 
> the courts [2].  If the USG had copyright, then I could stop
> pushing the ARL OSL entirely as we could use any of the OSI-supplied 
> licenses.
>
>
>
> So to be 100% clear, we don't know if any copyright-based license will stand 
> up in court for works that don't have copyright attached.  The
> only reason that the ARL OSL was proposed was to deal with that particular 
> situation.  If you have case law where the USG won a lawsuit
> over material licensed under one of the copyright-based OSI licenses where 
> there was no claim of copyright, please provide it.  I can pass
> that to the ARL Legal team who can then review it.
>
>
>
> Thanks,
>
> Cem Karan
>
>
>
> [1] I'm making the usual assumption that this was code created by USG 
> employees in the course of their duties; copyright can be assigned
> to the USG where and when it exists, but I'm ignoring that for right now.
>
>
>
> [2] My expectation is that it would be invalidated for the USG-supplied 
> portion, but not for any portion that had copyright attached.  Note
> that this is just my opinion, and I have nothing to back it up.  IANAL.

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

2016-08-18 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: Wheeler, David A [mailto:dwhee...@ida.org]
> Sent: Thursday, August 18, 2016 2:52 PM
> To: legal-disc...@apache.org
> Cc: Karl Fogel ; Lawrence Rosen ; 
> license-discuss@opensource.org
> Subject: RE: [License-discuss] [Non-DoD Source] Re: US Army Research 
> Laboratory Open Source License proposal
>
> William A Rowe Jr [Caution-mailto:wr...@rowe-clan.net]:
> > Unsure how this news might apply but it sounds like changes in overall 
> > policy might gain some traction to address this... If OMB came up
> with the rational of either approving AL 2.0 as is, or made a compelling 
> case for AL 2.1 clarifications.
> Caution-https://techcrunch.com/2016/08/08/the-white-house-just-released-the-federal-source-code-policy-to-help-government-agencies-
> go-open-source/
>
> The detailed policy is here:
> Caution-https://www.whitehouse.gov/sites/default/files/omb/memoranda/2016/m_16_21.pdf
>
> That new US federal government policy doesn't directly apply to many of 
> Cem's cases.  The policy doesn't apply to National Security
> Systems (NSS), and I expect that a lot of what the Army research labs do 
> would be classified as NSS.  The policy certainly presses for the
> release of open source software in general; it requires that a minimum of 
> 20% of custom-developed code be released as OSS in each year
> for 3 years.  It does note (in its definitions) that "custom developed code" 
> includes software developed by government officials as part of
> their official duties.  The policy itself does not delve into this kind of 
> legal analysis.

The current lack of legal analysis is the problem.  If they had complete 
analysis and full guidance about the license, we wouldn't be here at all!

Thanks,
Cem Karan


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] [Non-DoD Source] Re: [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

2016-08-18 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Lawrence Rosen
> Sent: Thursday, August 18, 2016 2:35 PM
> To: license-discuss@opensource.org
> Cc: Lawrence Rosen 
> Subject: [Non-DoD Source] Re: [License-discuss] [Non-DoD Source] Re: 
> [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source
> License (ARL OSL) 0.4.0
>
> Cam Karan asked:
>
> > If you have case law where the USG won a lawsuit over material licensed 
> > under one of the copyright-based OSI licenses where there was
> no claim of copyright, please provide it.
>
>
>
> A copyright lawsuit requires copyright, so that's impossible.
>
>
>
> A contract lawsuit requires damages and is usually fought in state (or small 
> claims?) court without even being published. Ask your own
> attorneys if they have ever won a contract lawsuit in a state or federal 
> court without proof of damages because the USG or anyone else
> merely distributed harmless public domain software.

I can, but I suspect that the answer is 'no' because I believe that the DoJ is 
the one that handles defending the USG.  And, considering that you are a 
lawyer and I'm not, I suspect that you're right about damages being necessary. 
;)

That said, what is being proposed is new ground for the USG.  I suspect that 
there is very little if any case law regarding Open Source and the USG.  I'd 
rather get all this right BEFORE there are any lawsuits.

Thanks,
Cem Karan



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] [Non-DoD Source] Re: US Army Research Laboratory Open Source License proposal

2016-08-18 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
The real trick is the DoJ; they have to defend the USG in court, as well as 
deal with any other legal aspects.  If they are willing to accept the licenses 
as-is, then I suspect that rest of the USG would go along (note that I can't 
speak for the USG on this, someone with authority to sign off on the policy 
would have to make that decision).

Thanks,
Cem Karan

> -Original Message-
> From: William A Rowe Jr [mailto:wr...@rowe-clan.net]
> Sent: Thursday, August 18, 2016 2:26 PM
> To: legal-disc...@apache.org
> Cc: Karl Fogel <kfo...@red-bean.com>; Lawrence Rosen <lro...@rosenlaw.com>; 
> license-discuss@opensource.org
> 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.
>
>
> ____________________
>
>
>
>
> On Aug 3, 2016 08:51, "Karan, Cem F CIV USARMY RDECOM ARL (US)" 
> <cem.f.karan@mail.mil < Caution-
> mailto:cem.f.karan@mail.mil > > wrote:
> >
> > Hi all, Karl Fogel on the mil-oss (Caution-http://www.mil-oss.org/ <
> > Caution-http://www.mil-oss.org/ > ) mailing list made a suggestion
> > that might be the solution.  Would the Apache foundation be willing to
> > work on Apache 2.1, or maybe 3.0, incorporating changes as needed to
> > cover works that don't have copyright attached to them?  If that were 
> > possible, we wouldn't need the ARL OSL at all.
> >
> > Thanks,
> > Cem Karan
>
> Unsure how this news might apply but it sounds like changes in overall 
> policy might gain some traction to address this... If OMB came up
> with the rational of either approving AL 2.0 as is, or made a compelling 
> case for AL 2.1 clarifications.
>
> Caution-https://techcrunch.com/2016/08/08/the-white-house-just-released-the-federal-source-code-policy-to-help-government-agencies-
> go-open-source/ < 
> Caution-https://techcrunch.com/2016/08/08/the-white-house-just-released-the-federal-source-code-policy-to-help-
> government-agencies-go-open-source/ >



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] [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

2016-08-18 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Richard Fontana
> Sent: Thursday, August 18, 2016 11:04 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
>
> On Thu, Aug 18, 2016 at 02:50:18PM +, Karan, Cem F CIV USARMY RDECOM ARL 
> (US) wrote:
> > >
> > > Even if you were correct in the assertions you've made about ARL
> > > code, why is a new license needed for contributors other than ARL?
> >
> > Are you suggesting a dual license scheme, where all copyrighted
> > portions are under Apache 2.0, and all non-copyrighted portions are under 
> > the ARL OSL?
>
> No, I'm just suggesting why not adopt a rule that all contributors (other 
> than ARL -- though for the reasons others have stated I think this
> should also apply to ARL) license contributions under the Apache License 
> 2.0.
>
> As a few have pointed out, all code that is nominally licensed under open 
> source licenses will contain noncopyrighted portions.

OK, so you're proposing that contributions that have copyright use the Apache 
2.0 license, and contributions that don't have copyright use the ARL OSL, 
correct?  I just want to make sure I fully understand what you're proposing.

Thanks,
Cem Karan



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] [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

2016-08-18 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Brian Behlendorf
> Sent: Wednesday, August 17, 2016 4:25 PM
> 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
>
> On Wed, 17 Aug 2016, Smith, McCoy wrote:
> > 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 with Apache 2.0
> > that we are skeptical even exists.  Perhaps the ARL lawyers can
> > clarify what the problem is, and that we are missing something.  But I
> > think at least I am having a hard time understanding how this license
> > does anything that Apache 2.0 doesn't.
>
> Is there something that a non-governmental entity can do to help with this, 
> by simply redistributing under AL2.0 that which they obtained
> from ARL by "contract" such as this license?  E.g., if this license was used 
> as the contributor agreement to a project hosted at the Apache
> Software Foundation, could it then be redistributed by the ASF under AL2.0, 
> with appropriate credit given in a Contributing.md?  Being an
> IP laundry service for government is an awful reason to be an Apache 
> project, but if there some other reason for ARL's code to be hosted
> there or at a similar organization (whether NGO or for-profit company even) 
> that might solve the problem, and then doesn't have to
> worry about being an "open source license".  A government agency (or branch 
> of the U.S. military) isn't really a great home for the
> governance of a code base and community anyways.

Actually, this was one of the first things we looked into; not ASF directly, 
but by having a contractor take ownership, and then assign copyright back to 
the USG, or even release it on behalf of the USG.  Unfortunately, it doesn't 
work legally as there is no copyright for the contractor (or anyone else) to 
take over, so nothing to launder.

Thanks,
Cem Karan


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] [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

2016-08-18 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
The only reason that the ARL OSL was proposed AT ALL is because there is a 
strong concern that since USG code doesn't have copyright [1], any license 
that relies exclusively on copyright may be invalidated by the courts [2].  If 
the USG had copyright, then I could stop pushing the ARL OSL entirely as we 
could use any of the OSI-supplied licenses.

So to be 100% clear, we don't know if any copyright-based license will stand 
up in court for works that don't have copyright attached.  The only reason 
that the ARL OSL was proposed was to deal with that particular situation.  If 
you have case law where the USG won a lawsuit over material licensed under one 
of the copyright-based OSI licenses where there was no claim of copyright, 
please provide it.  I can pass that to the ARL Legal team who can then review 
it.

Thanks,
Cem Karan

[1] I'm making the usual assumption that this was code created by USG 
employees in the course of their duties; copyright can be assigned to the USG 
where and when it exists, but I'm ignoring that for right now.

[2] My expectation is that it would be invalidated for the USG-supplied 
portion, but not for any portion that had copyright attached.  Note that this 
is just my opinion, and I have nothing to back it up.  IANAL.

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Smith, McCoy
> Sent: Wednesday, August 17, 2016 2:54 PM
> 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 with Apache 2.0 that we are 
> skeptical even exists.  Perhaps the ARL lawyers can clarify what
> the problem is, and that we are missing something.  But I think at least I 
> am having a hard time understanding how this license does
> anything that Apache 2.0 doesn't.
>
> -Original Message-
> From: License-discuss 
> [Caution-mailto:license-discuss-boun...@opensource.org] On Behalf Of Richard 
> Fontana
> Sent: Wednesday, August 17, 2016 11:33 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
>
> On Wed, Aug 17, 2016 at 06:17:07PM +, Karan, Cem F CIV USARMY RDECOM ARL 
> (US) wrote:
> >
> > Once again, liability isn't the only issue; there are also copyright
> > issues (for contributors), and IP issues.  If we could solve the
> > problem via a simple disclaimer of liability, we would.  We need to handle 
> > ALL the issues.
>
> Even if you were correct in the assertions you've made about ARL code, why 
> is a new license needed for contributors other than ARL?




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] [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

2016-08-18 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Engel Nyst
> Sent: Wednesday, August 17, 2016 2:59 PM
> To: license-discuss <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
>
> On Wed, Aug 17, 2016 at 8:32 PM, Richard Fontana <font...@sharpeleven.org> 
> wrote:
> > On Wed, Aug 17, 2016 at 06:17:07PM +, Karan, Cem F CIV USARMY RDECOM 
> > ARL (US) wrote:
> >>
> >> Once again, liability isn't the only issue; there are also copyright
> >> issues (for contributors), and IP issues.  If we could solve the
> >> problem via a simple disclaimer of liability, we would.  We need to 
> >> handle ALL the issues.
> >
> > Even if you were correct in the assertions you've made about ARL code,
> > why is a new license needed for contributors other than ARL?
>
> I'm assuming it's because they (ARL) don't have section 5 otherwise.
>
> ARL OSL can apply to public domain works and have a clause 5 to point to why 
> contributors' code is under AL2.0.
> While arguably unnecessary, I believe I see where they're coming from, it's 
> not hurting, and it's better in a document that equally gives
> from USG all AL2.0-for-public-domain-works including patent grant.
>
> Just my understanding of the needs of the OP.

Precisely; copyright is just one form of IP.  We want to make sure that all IP 
is covered as completely as possible.

Thanks,
Cem Karan



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] [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

2016-08-18 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Richard Fontana
> Sent: Wednesday, August 17, 2016 2:33 PM
> 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
>
> On Wed, Aug 17, 2016 at 06:17:07PM +, Karan, Cem F CIV USARMY RDECOM ARL 
> (US) wrote:
> >
> > Once again, liability isn't the only issue; there are also copyright
> > issues (for contributors), and IP issues.  If we could solve the
> > problem via a simple disclaimer of liability, we would.  We need to handle 
> > ALL the issues.
>
> Even if you were correct in the assertions you've made about ARL code, why 
> is a new license needed for contributors other than ARL?

Are you suggesting a dual license scheme, where all copyrighted portions are 
under Apache 2.0, and all non-copyrighted portions are under the ARL OSL?

Thanks,
Cem Karan



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] [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

2016-08-17 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Smith, McCoy
> Sent: Wednesday, August 17, 2016 11:34 AM
> To: license-discuss@opensource.org
> Subject: [Non-DoD Source] Re: [License-discuss] [Non-DoD Source] Re: U.S. 
> Army Research Laboratory Open Source License (ARL OSL) 0.4.0
>
> I find it odd that your lawyers are making you argue the legal issues here 
> even though you aren't a lawyer, and won't themselves join in to
> the conversation.

They have their reasons, but I'll try to get at least one on this list again.

> Further on my point, the US DOJ (i.e., the top government lawyers in the 
> USA) website states that most of the material on their website is
> public domain and freely usable by the public, yet still appends a 
> disclaimer of liability to that material:  Caution-
> https://www.justice.gov/legalpolicies  That seems to me like a pretty 
> concrete example of the USG understanding that a disclaimer of
> liability is not null and void just because the materials for which 
> liability is disclaimed is not licensable because it is in the public 
> domain.
> The very problem the ARL lawyers are saying this new license proposal is 
> attempting to solve.

Once again, liability isn't the only issue; there are also copyright issues 
(for contributors), and IP issues.  If we could solve the problem via a simple 
disclaimer of liability, we would.  We need to handle ALL the issues.

Thanks,
Cem Karan


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] [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

2016-08-17 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Smith, McCoy
> Sent: Tuesday, August 16, 2016 4:51 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research 
> Laboratory Open Source License (ARL OSL) 0.4.0
>
> I think what a lot of the lawyers on here are trying to say to you is -- why 
> not just use Apache 2.0 and be done with it?
>
> You appear to find Apache 2.0 wanting because some of the materials that 
> will be transmitted might not be copyrightable in some
> jurisdictions.  And you believe as a result, the entire Apache 2.0 license 
> (including the patent grants, and the disclaimer of warranties)
> would be rendered null & void as a result.  Perhaps the lawyers from ARL are 
> telling you that;  if so, perhaps you could invite them to the
> conversation.

I have, but they've refused, and won't budge on it.

> I think many people on here are skeptical of the latter part of your 
> analysis.  In fact, I suspect that virtually every piece of code licensed
> under Apache 2.0 has some parts that aren't subject to copyright, since they 
> don't satisfy the provisions of 17 USC 102 and the various
> judicial tests to separate expressive vs. non-expressive content.

Possibly true.  If our management eventually says that they're willing to take 
the risk and go with it, I'll be willing to drop the ARL OSL.  So far it 
hasn't happened, and so far our lawyers are convinced that the copyright is 
going to be a problem.

Thanks,
Cem Karan


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] [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

2016-08-16 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Lawrence Rosen
> Sent: Tuesday, August 16, 2016 4:36 PM
> To: license-discuss@opensource.org
> Cc: Lawrence Rosen <lro...@rosenlaw.com>
> Subject: Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research 
> Laboratory Open Source License (ARL OSL) 0.4.0
>
> Keran, your description of the "chain" is not usually correct for FOSS. The 
> Apache and GPL and MPL licenses don't have to work that way
> through sublicensing. Each licensee receives his or her license directly 
> from the licensor. There is no chain. The licensor (contractor) can
> directly enforce that license -- including its warranties and liability 
> disclaimers -- against each of its licensees even if it is not a copyright
> owner.
>
> In law, that means that privity [1] is not an enforcement problem for most 
> FOSS licenses because there are no contractual "third parties".
>
> > The closest analogy I can provide is that contract law is innocent
> > until proven guilty, while copyright is guilty until proven innocent.
>
> No.

I didn't say it was a *good* analogy! ;)

You're right that normal licenses don't rely on chains; they have copyright to 
fall back on.  If I have a piece of software licensed to me under the Apache 
2.0 license, then I'm allowed to do certain things because the license 
protects me from the copyright holder's legal attacks; in their eyes, I'm 
'guilty' until I can prove my innocence via the Apache 2.0 license (and my 
complying with its terms, of course!).

Contract law and the principle of privity means that I can only sue the person 
I had a contract with.  If the USG has a contract with A and A breaks the 
license in some way, and hands off the code to B, then B is an innocent party. 
The trick is that the USG has to prove that A was the guilty party.  In a 
chain, the USG would have to follow the chain until it could find the guilty 
party (innocent until proven guilty).  At that point the USG may be able to 
help the upstream party sue (I don't know if this is possible, I'm not a 
lawyer).

So, given that the USG doesn't have copyright to fall back on in all cases 
(copyright can be assigned to the USG, so there are cases where copyright 
applies), it has to make do with contract law.  This is why the ARL OSL is 
written as it is; it tries to use copyright whenever possible, but still 
provide protections when there is no copyright.

Thanks,
Cem Karan

> /Larry
>
> [1] Privity: The doctrine of privity in the common law of contract provides 
> that a contract cannot confer rights or impose obligations
> arising under it on any person or agent except the parties to it.
>
>
> -Original Message-
> From: Karan, Cem F CIV USARMY RDECOM ARL (US) 
> [Caution-mailto:cem.f.karan@mail.mil]
> Sent: Tuesday, August 16, 2016 12:44 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research 
> Laboratory Open Source License (ARL OSL) 0.4.0
>
> > -Original Message-
> > From: License-discuss
> > [Caution-mailto:license-discuss-boun...@opensource.org]
> > On Behalf Of Engel Nyst
> > Sent: Tuesday, August 16, 2016 11:34 AM
> > To: license-discuss <license-discuss@opensource.org>
> > Subject: Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research
> > Laboratory Open Source License (ARL OSL) 0.4.0
> >
> > On Tue, Aug 16, 2016 at 5:12 PM, Karan, Cem F CIV USARMY RDECOM ARL
> > (US) <cem.f.karan@mail.mil> wrote:
> > > OK, but wouldn't those changes mean that the license no longer
> > > applies to the uncopyrightable portions?  That would mean that
> > > downstream users would no longer have any protection from being sued, 
> > > etc., right?
> >
> > The obligations (a)-(d) would not apply to the uncopyrightable portions.
> > That's not the whole license/contract, only those particular
> > obligations that try to put "restrictions" on the rights to reproduce,
> > prepare derivative works, and distribute them.
> >
> > For example, (a) says "[you can reproduce this work], provided that
> > ... you give other recipients a copy of this license". In other words,
> > "you can't reproduce this work if you don't add a copy of this license".
> > This obligation doesn't apply to a public domain work, I can reproduce
> > it without.
>
> OK, I see where you're coming from now.  I had to have the ARL Legal team 
> explain this to me as well, but the ARL OSL is actually a
> contract, and the contract can apply even if there is no copyright.  We 
> release material to our col

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

2016-08-16 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Scott K Peterson
> Sent: Tuesday, August 16, 2016 4:35 PM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research 
> Laboratory Open Source License (ARL OSL) 0.4.0
>
> > 2) Liability is only one part of the puzzle; as I mentioned in an
> > earlier email, there are IP issues that need to be solved (e.g.
> > Caution-https://en.wikipedia.org/wiki/Rambus#Lawsuits). That makes CC0 
> > unattractive.
>
>
> Rambus and free software?
>
> What about the Rambus patent litigation informs the software license choice 
> issues being discussed in this thread?
>
> I'm sorry. I clearly have not been paying enough attention to this thread. I 
> have been engaged in issues at the intersection of patents and
> standards since before patent enforcement by Rambus attracted the attention 
> of the FTC. "Rambus". Now you have my attention.

The issue is the one that the Apache 2.0 license solves, and that the ARL OSL 
is attempting to solve for works that don't have copyright attached. 
Basically, clause 3 in each of the licenses means that you can't contribute 
software that has patents on it, and then sue everyone for using said 
contribution.  Putting everything under CC0 doesn't protect the USG or anyone 
that uses USG-sponsored projects from being sued, which at the very least 
would be embarrassing, and in the worst-case, damaging to Open Source in 
general.  I want to avoid that issue entirely by having a license that will 
stand up in court that makes it clear that contributors ARE licensing all 
patents and other necessary IP rights when they contribute.

Thanks,
Cem Karan
 U.S. Army Research Laboratory Open Source License (ARL OSL)
   Version 0.4.1, August 2016
http://no/URL/as/yet

   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

   1. Definitions.

  "License" shall mean the terms and conditions for use, reproduction,
  and distribution as defined by Sections 1 through 10 of this document.

  "Licensor" shall mean the project originator or entity authorized by
  the project originator that is granting the License.

  "Legal Entity" shall mean the union of the acting entity and all
  other entities that control, are controlled by, or are under common
  control with that entity. For the purposes of this definition,
  "control" means (i) the power, direct or indirect, to cause the
  direction or management of such entity, whether by contract or
  otherwise, or (ii) ownership of fifty percent (50%) or more of the
  outstanding shares, or (iii) beneficial ownership of such entity.

  "You" (or "Your") shall mean an individual or Legal Entity
  exercising permissions granted by this License.

  "Source" form shall mean the preferred form for making modifications,
  including but not limited to software source code, documentation
  source, and configuration files.

  "Object" form shall mean any form resulting from mechanical
  transformation or translation of a Source form, including but
  not limited to compiled object code, generated documentation,
  and conversions to other media types.

  "Work" shall mean the work of authorship, whether in Source or
  Object form, made available under the License, as indicated by a
  notice that is included in or attached to the work
  (an example is provided in the Appendix below).

  "Derivative Works" shall mean any work, whether in Source or Object
  form, that is based on (or derived from) the Work and for which the
  editorial revisions, annotations, elaborations, or other modifications
  represent, as a whole, an original work of authorship. For the purposes
  of this License, Derivative Works shall not include works that remain
  separable from, or merely link (or bind by name) to the interfaces of,
  the Work and Derivative Works thereof.

  "Contribution" shall mean any work of authorship, including
  the original version of the Work and any modifications or additions
  to that Work or Derivative Works thereof, that is intentionally
  submitted to Licensor for inclusion in the Work by the author
  or by an individual or Legal Entity authorized to submit on behalf of
  the author. For the purposes of this definition, "submitted"
  means any form of electronic, verbal, or written communication sent
  to the Licensor or its representatives, including but not limited to
  communication on electronic mailing lists, source code control systems,
  and issue tracking systems that are managed by, or on behalf of, the
  Licensor for the purpose of discussing and improving the Work, but
  excluding communication that is conspicuously marked or otherwise
  designated in writing 

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

2016-08-16 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Richard Fontana
> Sent: Tuesday, August 16, 2016 4:10 PM
> To: license-discuss@opensource.org
> Cc: lro...@rosenlaw.com
> Subject: Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research 
> Laboratory Open Source License (ARL OSL) 0.4.0
>
> On Tue, Aug 16, 2016 at 08:03:18PM +, Karan, Cem F CIV USARMY RDECOM ARL 
> (US
>
> > As for 'license vs. contract', was that something discussed in
> > relation to the ARL OSL?
>
> No, that's a much older topic of debate in open source. It's safe to say 
> from your previous remarks that ARL assumes that licenses are
> contracts. :)

As I understand it from ARL Legal, licenses ARE contracts.  I am not a lawyer 
and don't know if they are the same or not.  I'd really rather not open up a 
can of worms regarding what they are, I just want to make sure that the ARL 
OSL is interoperable with Apache 2.0, that it is as close to being legally 
identical to it as possible when applied to anything that has copyright 
attached, and that the OSI and Apache are happy with it.

Thanks,
Cem Karan


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] [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

2016-08-16 Thread Karan, Cem F CIV USARMY RDECOM ARL (US)
Here are the problems:

1) ARL doesn't know if it can use copyright-based licenses on public domain 
software.  In particular, will the entire license be held invalid, including 
the disclaimers, if the copyright portions are held to be invalid?

2) Liability is only one part of the puzzle; as I mentioned in an earlier 
email, there are IP issues that need to be solved (e.g. 
https://en.wikipedia.org/wiki/Rambus#Lawsuits).  That makes CC0 unattractive.

If the entire license is held to be invalid, then contributors may have 
standing to sue both the USG and anyone that uses USG code for patent 
violations.  We're trying to have a license that will withstand legal 
scrutiny, and protect not just the USG, but also all innocent contributors and 
users of USG-sponsored projects.

As for 'license vs. contract', was that something discussed in relation to the 
ARL OSL?

Thanks,
Cem Karan

> -Original Message-
> From: License-discuss [mailto:license-discuss-boun...@opensource.org] On 
> Behalf Of Lawrence Rosen
> Sent: Tuesday, August 16, 2016 12:57 PM
> To: license-discuss@opensource.org
> Cc: Lawrence Rosen 
> Subject: Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research 
> Laboratory Open Source License (ARL OSL) 0.4.0
>
> 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.
>
>
>
>
> 
>
> Regardless of whether a licensor owns the copyright, distribution of that 
> work is still a conveyance of a piece of software in commerce.
> Among other things, that is a contractual act. Even public domain software 
> can cause harm. A disclaimer of warranty and liability -- even
> for the public domain portion of a work, within the limitations of the 
> law -- can still be effective in a FOSS license.
>
> Why does the Army Research Laboratory confuse the distribution of a work 
> under a waiver of liability with the ownership (or not) of its
> embedded copyrights?
>
> Is this a resurrection of the old "license vs. contract" dispute that we 
> buried long ago?
>
> /Larry
>
>
> -Original Message-
> From: Richard Fontana [Caution-mailto:font...@sharpeleven.org]
> Sent: Tuesday, August 16, 2016 9:42 AM
> To: license-discuss@opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] Re: U.S. Army Research 
> Laboratory Open Source License (ARL OSL) 0.4.0
>
> On Tue, Aug 16, 2016 at 04:19:31PM +, Christopher Sean Morrison wrote:
> >
> >
> >
> > 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.
>
> 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.
>
> 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.)
>
>
> Richard
>
>
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> Caution-https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
>
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> Caution-https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss


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


  1   2   >