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

[Richard Fontana]

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 
> (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.

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 
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 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 CC0 to be used to ceremonially declare (possibly in
some cases incorrectly or misleadingly) that something that is not
subject to copyright ownership in the first place is indeed ... not
subject to copyright ownership in the first place -- which is not what
CC0 says.

Richard

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

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

[Richard Fontana]

Interesting but at first glance the data seems too unreliable to be of
any use. I started checking the identified projects under the so-called
Clear BSD license (the FSF-free, never-OSI-submitted BSD variant that
explicitly excludes patent licenses) and the ones I looked at were all
spurious matches.


Richard







On Thu, Apr 6, 2017, at 11:21 AM, Luis Villa wrote:

> Yet another (inevitably flawed) data set: 

> https://libraries.io/licenses

> 

> On Tue, Jan 10, 2017, 11:07 AM Luis Villa  wrote:

>> [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[1]) 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 be sufficient to take those
>>three and average.
>>* Could throw in Black Duck or other non-transparent surveys as a
>>  fourth, fifth, etc.?
>>  * *new versions? *If a new version exists but isn't widely adopted
>>yet, how does the list reflect that? e.g., MPL 1.1 still shows up
>>in Black Duck's survey; should OSI replace 1.1 with 2.0 in the
>>"processed" list? What about GPL v2 v. v3? BSD/MIT v. UPL?
>>  * *gaps/"mistakes":* What happens when the board thinks the data is
>>incorrect? :) e.g., should ISC be listed?
>> Part of why we didn't go very far in 2013 is because there are no
>> great answers for these - different answers will refle

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

[Richard Fontana]

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 [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)"
> > > >  > > > 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

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

[Richard Fontana]

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 [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)" 
> >  > 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)" 
> >  > 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
> > >   > 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 
> > add

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

[Richard Fontana]

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:

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

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

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
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[Richard Fontana]

On Wed, Mar 01, 2017 at 01:50:42PM -0500, Christopher Sean Morrison wrote:

> 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 …

I think it was withdrawn before the discussion was complete. I believe
there were some who felt it was inappropriate for an OSI-approved
license to explicitly deny patent rights. 

> 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.

https://opensource.org/approval implies that it's supposed to be the
license steward. The *GPLv3 cases suggest that there's an implied
exception to this where there's no likelihood that the license steward
will submit a license that is nonetheless likely to be of significant
interest to many in the OSI community.







___
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

[Richard Fontana]

I see (I think). So you want to approximately harmonize the treatment
of US government works outside the US with the treatment inside the
US, but not harmonize the treatment of US government works with the
treatment of non-US-government works. 


On Wed, Mar 01, 2017 at 05:33:57PM +, Karan, Cem F CIV USARMY RDECOM ARL 
(US) wrote:
> 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
> > &g

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

[Richard Fontana]

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-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.
> > > >
> > > >
> > > >
> > > >
> > > > 
> > > >
> > > > 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-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
> > > > > pro

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

[Richard Fontana]

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" 
>  
> 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 
> > 
> 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.
> 
> 
> 
> > ___
> > License-discuss mailing list
> > License-discuss@opensource.org
> > https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
> 
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
> 
> 
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[Richard Fontana]

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: 
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 [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 CC

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

[Richard Fontana]

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
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

[Richard Fontana]

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 
> 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.



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

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

Re: [License-discuss] OSI equivalent

[Richard Fontana]

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 
> mailto:for...@david-woolley.me.uk>>
> Date: Wednesday, Feb 15, 2017, 4:17 PM
> To: license-discuss@opensource.org 
> mailto:license-discuss@opensource.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 context of their specific client's
> circumstances.
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

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

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

[Richard Fontana]

On Tue, Jan 10, 2017 at 04:07:53PM +, Luis Villa wrote:

> 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 ) 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.

+1

> *Supplementing with high-quality, value-adding options*
> To encourage progress, while still avoiding proliferation, I'd suggest a
> second list of licenses that are good but not (yet?) popular. "Good" would
> be defined as something like:
> 
>1. meets the OSD
>2. isn't on the data-driven popularity list
>3. drafted by an attorney (at minimum) or by a collaborative, public
>drafting process with clear support from a sponsoring-maintaining
>organization (ideal)
>4. has a new "feature" that is firmly in keeping with the overall goals
>of open source and can be concisely explained in a few sentences (e.g., for
>UPL, "GPL-compatible permissive license with explicit patent grant")
>1. but not "just for a particular community" - has to be at least
>   plausible applicable to most open source projects
>   2. this is unavoidably subjective; suggest having it fall to the
>   board with pre-discussion on license-review.

> #4 allows for some innovation (and OSI support of such innovation) while #3
> applies a quality filter. (Both #3 and #4 have anti-proliferation effects.)
> Hopefully licenses that meet #3 and #4 would eventually move into #2, but
> you could imagine placing a time limit on this list; if you're not in the
> top 10 most popular within five years, then you get retired? But not sure
> that's a good idea at all - just throwing it out as one option.

I like the general idea, and I suppose it corresponds to what the OSI
was trying to do with the partial updating of the 2006 popular list. I
would rather have #3 be "must be determined to be well drafted and of
high quality" without giving specifics (despite the additional
subjectivity this would introduce). Looking at the whole history of
open source licensing, it is hard to make the case that involvement of
an attorney is a likely indicator of higher quality. :)

> If a new license meets #1, but not #3 and #4, then OSI's formal policy
> should be to approve, but bury it in one of the other proliferation list
> groups. (Those groups are actually quite good, and should be fairly
> non-controversial — once you have a good policy for what gets in the more
> "favored" groups.) I don't think a new "deprecated" group is necessary -
> the proliferation categories are basically a good list of that already.

I actually think we should take a fresh look at these proliferation
categories.

>- With SPDX and Fedora providing more comprehensive lists of FOSS
>licenses, it might make sense for OSI to link to those as "extended"
>resources, to reduce pressure from obscure license authors to get their
>license approved.

A bigger problem is that somehow, and quite early on, the OSI came to
be seen as an organization that encouraged "experimental
licenses". (Not entirely a problem - the good part of this is that it
actively encouraged creativity and advancement in the field of open
source licensing.) One characteristic of the SPDX, Fedora, Debian [to
the extent an actual 'list' of DFSG-compatible licenses exists, which
I'm not sure of], and the FSF lists is that they deal with the actual
real world, for the most part: they consider licenses that are really
being used. OSI came to be a place where one would bring licenses that
are not being used yet -- which in some cases could mean licenses that
never end up being used.

SPDX and Fedora are thus not really going to reduce pressure for
obscure license authors unless those license authors actually see
their licenses in real use.

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

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

[Richard Fontana]

On Tue, Jan 10, 2017 at 04:07:53PM +, Luis Villa wrote:

> 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.).
[...]
 
>- I don't recommend merely updating the existing "popular and..." list
>through a subjective or one-time process. The politics of that will be
>messy, and without a documented, mostly-objective, data-driven method,
>it'll again become an outdated mess.

Luis, I agree.

I just want to point out something I've said privately (and I think
publicly as well, if not in a few years), which is that the current
version of the "popular or strong communities list" is in my opinion a
mess. It takes the original (flawed IMO) ~2006 list and does the
following:

* Changes MPL 1.1 to MPL 2.0 (which of course didn't exist in 2006 and
  which is significantly different from MPL 1.1)

* In contrast to MPL, the existence of significantly different
  OSI-approved versions of the GPL and LGPL is ignored

* Ignores the fact that CDDL's current license steward has for several
  years had a minor (1.1) update which has not been submitted for OSI
  approval

I had thought it might be preferable to return to the original
"popular list" and just make clear that it is the product of a
now-distant point in time, but I now believe this solution would
probably be seen by many as worse than the current approach.

Richard


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

Re: [License-discuss] Is the OBM License OSD compatible?

[Richard Fontana]

On Fri, Jan 06, 2017 at 05:19:44PM +, Gervase Markham wrote:
> On 06/01/17 17:09, Smith, McCoy wrote:
> > GPLv3 (and the variants, LGPLv3 and AGPLv3) do *not* permit
> > "Additional Terms" (despite the section header called "Additional
> > Terms");  they permit "Additional Permissions" which are defined in
> > the license, Sec 7, as "terms that supplement the terms of this
> > License *by making exceptions from one or more of its conditions*."
> 
> The section 7, titled "Additional Terms", permits "Additional
> Permissions" in the first two paragraphs, but also in the following
> paras permits 6 categories of other sorts of additional terms which are
> not necessarily entirely permissive. Section 7 b) through f) are clearly
> not entirely permissive if you read them. So the section heading is
> correct, and I believe your interpretation that everything envisaged by
> that section must be an Additional Permission is wrong.

That's correct. Section 7 authorizes 'additional permissions'
generally and a limited set of "non-permissive" additional
terms. Conceptually 7a through 7f were seen as categories of
'non-permissive' terms over and above the conditions of GPLv3 that do
not violate the general rule against 'further restrictions'. These
were designed to codify aspects of FSF interpretation of GPLv2
including license compatibility doctrine as well as extend it in some
ways (e.g. 7f is intended to provide a basis for Apache License 2.0
compatibility with GPLv3 by abstracting from the condition of Apache
License 2.0 section 9).

Richard

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

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

[Richard Fontana]

On Tue, Dec 13, 2016 at 04:17:03PM +, Tzeng, Nigel H. wrote:
> With or without OSI approval CC0 appears to be an accepted open source
> license to the US Government.
> 
> 
> https://code.gov/
>
> "We understand OSI's reservations (which relate to the lack of
> explicit patent language), but are comfortable with our assessment
> that CC0 meets the definition of open source. There are other
> standard open source licenses which also do not explicitly address
> patents."

The concern that some on license-review had about CC0 was not about
lack of explicit patent language (which is characteristic of many
OSI-approved licenses) but rather the explicit statement: "No
trademark or patent rights held by Affirmer are waived, abandoned,
surrendered, licensed or otherwise affected by this document."  (I
don't think anyone raised any concerns about the trademark side of
that sentence.)

> Creative Commons recommends that CC0 be used with a patent grant for
> Code.gov which the government folks at 18F are considering.
> 
> "Patents are a thing, and Creative Commons' comment on the White House
> source code policy 
> recommends an
> explicit patent disclaimer, something we're considering at 18F.²
> 
> https://github.com/WhiteHouse/source-code-policy/issues/258

If the US government standardizes on some particular explicit patent
language to use with CC0 I would welcome OSI review of that. 

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

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

[Richard Fontana]

On Thu, Dec 01, 2016 at 11:26:03PM -0500, Richard Fontana wrote:
> 
> The OSI has received several inquiries concerning its opinion on the
> licensing of React

Another reference: Facebook has published a brief FAQ on what it calls
the "Facebook BSD+Patents license":
https://code.facebook.com/pages/850928938376556


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

[License-discuss] Views on React licensing?

[Richard Fontana]

The OSI has received several inquiries concerning its opinion on the
licensing of React [1], which is essentially the 3-clause BSD license
along with, in a separate file, an 'Additional Grant of Patent Rights'
[2].

The Additional Grant of Patent Rights is a patent license grant that
includes certain termination criteria. These termination criteria are
not entirely unprecedented when you look at the history of patent
license provisions in OSI-approved licenses, but they are certainly
broader than the termination criteria [or the equivalent] in several
familiar modern licenses (the Apache License 2.0, EPL, MPL 2.0, and
GPLv3).

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

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

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

- 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.)

- if the React patent license should be seen as not legitimate from an
  OSI/OSD perspective, what about the substantial number of
  past-approved (if now mostly obsolete) licenses that incorporated
  patent license grants with comparably broad termination criteria?

- should Facebook be encouraged to seek OSI approval for the React
  license including the patent license grant?

Richard


[1] https://facebook.github.io/react/

[2] https://github.com/facebook/react/blob/master/PATENTS

[3] http://www.elcaminolegal.com/single-post/2016/10/04/Facebook-Reactjs-License

[4] http://lu.is/blog/2016/10/31/reacts-license-necessary-and-open/
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Is OSI still alive?

[Richard Fontana]

On Mon, Nov 28, 2016 at 06:01:40PM +, Tzeng, Nigel H. wrote:
> Just curious as I get crickets in license-review.
> 
> I guess it must still be alive as I got asked for a donation...but an update 
> on NOSA v2 and UCL would be nice.

Sorry Nigel, I have now responded on license-review.

Richard

___
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

[Richard Fontana]

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 [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
> > > > >

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

[Richard Fontana]

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 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 [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
> > __

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

[Richard Fontana]

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
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

[Richard Fontana]

On Thu, Aug 18, 2016 at 08:55:54PM +, Tzeng, Nigel H. wrote:
> If the USG is using CC0 for their new OSS initiative
> is this something that should be revisited?

Yes, I think so. 

> Of course, you know I¹m of the opinion that is the OSI states a license is
> open source if it passes the OSD then we should either amend the OSD to
> require explicit patent grants moving forward or not block useful new
> licenses because of the lack of a patent grant.

I'm inclined to agree with that. Note, though, the controversial issue
with CC0 was the explicit refusal to grant a patent license. I don't
think a license with a similar feature has been submitted for OSI
approval since the CC0 event. The OSI has approved at least one
license since that time that did not explicitly address patents.

Richard

___
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

[Richard Fontana]

On Thu, Aug 18, 2016 at 07:15:52PM +, Tzeng, Nigel H. wrote:
> From: License-discuss 
> mailto:license-discuss-boun...@opensource.org>>
>  on behalf of "Smith, McCoy" 
> mailto:mccoy.sm...@intel.com>>
> 
> > Interestingly enough, the code of the code.gov site is licensed under CC0 
> > 1.0:  
> > https://github.com/presidential-innovation-fellows/code-gov-web/blob/master/LICENSE.md
> 
> But but but...that's not an OSI approved software license!
> 
> Why did that fail again?  The person who submitted didn't have standing or 
> something?

The license steward withdrew the submission following negative
reaction on license-review to the "No ... patent rights held by
Affirmer are waived, abandoned, surrendered, licensed or otherwise
affected by this document" clause.

Richard
___
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

[Richard Fontana]

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.
___
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

[Richard Fontana]

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?











___
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

[Richard Fontana]

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. :)

___
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

[Richard Fontana]

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
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

[License-discuss] New settings for license--discuss

[Richard Fontana]

Greetings,

The OSI recently changed the settings for license-discuss to permit
posting only from subscribers to the list. All nonsubscribers who
attempt to post to the list will receive an informative rejection
message. This step was particularly necessary because of the enormous
volume of spam directed at the list.

Richard

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

Re: [License-discuss] Can OSI take stance that U.S. public domain is open source?

[Richard Fontana]

On Sun, 04 May 2014 11:48:13 -0500
Karl Fogel  wrote:

> IMHO it would be a long-term problem for the OSI (and for open source
> in general, given the useful standardization/certification role OSI
> plays) to have there be licenses that we call "open source" but don't
> certify.
> 
> After all, the *definition* of "open source" is supposed to be just
> "whatever complies with the OSD".  And our certification process is
> also "Does this comply with the OSD?"...  So the two shouldn't
> diverge; to the extent that they do, we have a problem.
[...]
> But in the long run I think we have two
> mutually exclusive choices:
> 
>   1) Have licenses out in the world that are OSD-compliant, and that
> we informally agree are "open source", but that we don't certify.
>  This will cause growing divergence between "what is open source"
>  and "what the OSI has approved".  That would be very, very bad.

I consider it important to understand, and acknowledge, that this
divergence already exists in most people's minds (i.e. those people who
have enough knowledge of what's going on in the real world).
It exists in my own mind. 

I don't know offhand the current count of OSI-approved licenses but I
think it is around 70. In a typical traditional server/desktop Linux
distro, the numbers of distinct licenses regarded *reasonably* by the
communities of users and distributors of that distro as "open
source" must number at least in the several hundreds. (Think of
the universe of licenses covering packages considered
DFSG-conformant in Debian, since the criteria are at least superficially
very similar to the OSD, its descendant.)  

To me the bigger problem has always been the use of "open source" to
label things that are not reasonably considered OSD-compliant
(regardless of whether a license has been certified by the OSI). 

>   2) Officially certify any license (or PD status / PD dedication)
> that is OSD-compliant as open source, but for most of them attach
>  commentary explaining why most people probably shouldn't use it
> and why one should one of the popular licenses instead.
> 
> (1) is a disaster.  It will defeat much of the point of the OSI, in
> the long run.

But (1) is where we are today, and where we always have been, except
that the OSI is the one institution that can't easily admit this. 

> We're sort of doing the complement of (2) right now, with the "Popular
> Licenses" section. 

Sort of except that OSI does not consider the issue of certification if
no one (or no one with authority, in the typical case) submits a
license for approval. One effect of this is that legacy licenses are
unlikely to be OSI-approved (although we've seen a few license
submissions of this sort), which may be fine. But we shouldn't pretend
that just because a license was never submitted for OSI approval, it
must fail the OSD. An interesting example someone brought up some time
ago is that the OSI apparently never certified GPLv1, not surprisingly
since it's seen little (explicit) use since 1991, though usage is not
zero. 

> ...but I think we do need to come to some sort of solution soon.  The
> U.S. government is going to keep releasing what is (obviously) open
> source software into the public domain; CC0 is also becoming more
> popular in non-software works and will inevitably make inroads into
> software too.

I'm going to out myself here and say that I believe CC0 is obviously
lowercase-o, lowercase-s open source despite the clause about patents.
That doesn't mean the OSI should have approved it, that doesn't mean
the OSI should recommend its use in its current form or cease its
current practice of recommending against its use. I have a similar view
of US government public domain works (with the added problem that it is
clear that many intellectual property lawyers working across different
US government agencies are confused over what 17 USC 105 means). 

Yes, US works that are public domain worldwide are obviously open
source, but as with CC0 this has some implications for how licenses that
explicitly mention disposition of patent rights should be treated.
 
> I completely agree, by the way, that we can be active about requiring
> certain kinds of patent promises.  E.g., maybe we wouldn't certify PD
> itself for software works, but would certify PD *when accompanied by*
> a particular patent non-assertion text.  We'd have a lot of leverage
> to do so, given that refusing to make that non-assertion promise,
> when asked for it, would draw attention to the fact that the party
> has now publicly decided not to be open source enough for the OSI.
> So I'm not saying we should just certify PD and CC0 and be done with
> it -- it's more complex than that.

I agree.

- RF
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Can OSI take stance that U.S. public domain is open source?

[Richard Fontana]

On Sat, 03 May 2014 14:00:53 -0500
Karl Fogel  wrote:

> Richard Fontana  writes:
 
> >Also with statutory public domain works you have the same old MXM/CC0
> >inconsistency problem in a different form. Consider the case of
> >public domain source code created by a US government employee,
> >having features covered by a patent held by the US government.
> 
> The patent issue would apply just as much if it were MIT- or
> BSD-licensed, though, and we'd call it "open source" then, right?

Unless perhaps the situation -- a statute that says that US government
works are in the copyright public domain, with no counterpart provision
in the Patent Act -- is more akin to CC0, and depending on whether you'd
call CC0-covered source code "open source". 
 
> http://www.cendi.gov/publications/04-8copyright.html#317 seems to
> indicate that we'd need an explicit notice that the U.S. government
> will not claim any copyright on the work in jurisdictions outside the
> U.S.
> 
> If the US government were to publish such notice on a given work --
> say, if standardized language for doing so were approved by the
> OSI :-) -- then would there be any sense in which the work would not
> be compliant with the OSD?  E.g., would its open-sourceness be
> materially different from an MIT-licensed work?

When the MXM license was considered, some people pointed to OSD #7 as
suggesting that a sufficiently narrowly-drawn patent license grant in
a license would not be Open Source. This was the problem I raised when CC0 was
submitted. It was the inconsistency. It depends on your view of how the
OSD applies to patents. 

- RF
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Can OSI take stance that U.S. public domain is open source?

[Richard Fontana]

On Sat, 3 May 2014 22:07:19 +0300
Henrik Ingo  wrote:
 
> Does the US government grant itself patents, 

Yes.

> and if so, what does it
> do with those patents?

Many are licensed to the private sector for revenue. 

 - RF
 
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Can OSI take stance that U.S. public domain is open source?

[Richard Fontana]

On Fri, 02 May 2014 14:55:55 -0500
Karl Fogel  wrote:

> This thread on GitHub gets (needlessly?) complicated.  It's about a
> public-domain software work put out by the U.S. government, and
> there's no clarity on whether calling it "open source" and citing the
> OSI's definition of the term would be appropriate:
> 
>   https://github.com/ngageoint/geoevents/issues/2#issuecomment-41739913
> 
> Someone cites our FAQ item on it (which, as its primary author, I
> found tickled my vanity :-) ), but really, I wish they didn't have to
> cite the OSI FAQ and could instead just say "yup, public domain is
> open source".
> 
> The things we don't like about public domain (lack of explicit
> liability limitation, different definitions in different
> jurisdictions) are not in themselves counter to the OSD, after all.
> 
> Thoughts?  Should OSI look for a route to say that public domain works
> (like ones put out by the U.S. government) are open source too, or is
> it just too problematic?

This work's authors seem to explicitly say that they are dedicating it
to the public domain, not merely (or explicitly at all, as far as
I can see here) relying on the notion of statutory public domain for
US government works. I'd argue those are two different concepts of
"public domain" (one of which is really something more akin to the
effect achieved by CC0). 

With statutory public domain works, you can't be sure out of context
what the status of the work is when published outside the US. See e.g.
http://www.cendi.gov/publications/04-8copyright.html#317. I've found
that many US government lawyers dealing with open source seem to assume
that 17 USC 105 operates worldwide (this sometimes comes up in the form
of a refusal to sign CLAs because 'there is no copyright to license').

Also with statutory public domain works you have the same old MXM/CC0
inconsistency problem in a different form. Consider the case of public
domain source code created by a US government employee, having features
covered by a patent held by the US government.

 - RF

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

Re: [License-discuss] FAQ entry (and potential website page?) on "why standard licenses"?

[Richard Fontana]

On Mon, 28 Apr 2014 13:31:06 -0700
Ben Tilly  wrote:

> Suggested solution, can we use the word "common" instead of
> "standard"?  And our definition of common should be something
> relatively objective, like the top X licenses in use on github, minus
> licenses (like the GPL v2) whose authors are pushing to replace with a
> different license. 

You'd exclude the most commonly-used FLOSS license from "common"?

 - RF
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] FAQ entry (and potential website page?) on "why standard licenses"?

[Richard Fontana]

On Mon, 28 Apr 2014 15:03:20 -0300
"Bruno F. Souza"  wrote:

> Sidestepping the whole discussion around standard's bodies and other
> meanings of "standard", when I read Luis' FAQ entry, the use of the
> term "standard" is really confusing...

I think so too now, in light of this thread at least. 

> The entry seems to equate "standard" with "OSI-approved": 
>   "Using standard, OSI-approved open source licenses"
>   "standard licenses that comply with the Open Source
> Definition" "standard licenses that have been approved by the Open
> Source Initiative" "Using standard, widely-used terms that comply
> with the Open Source Definition"
> 
> It has nothing to do with popularity or license proliferation,
> because "standard" is not used in this way in the text. More
> specifically: "Using standard licenses [...] particularly those
> licenses that are widely-used" (for me this clearly states that all
> approved licenses are "standard", not only the widely-used ones)
> 
> It also opposes "standard" with "custom" or "new":
>   "reducing [...] legal errors that can be present in new,
> "custom" licenses."
> 
> And some times, it seems to be one thing more then OSI-approved:
>   "using a well-known license that is standard in the community
> *and* [OSI-]approved" (emphasis added)
> 
> So, I think the text is really calling for a less confusing term, and
> I think "OSI-approved" is probably what we want here. After all,
> talking about the advantages of the OSI-approved licenses for
> projects, developers and managers is a great way to promote OSI. 

I'll pick on the Motosoto License here since someone else brought it up.

If "OSI-approved" is what is meant by "standard", then these arguments
get much weaker. There is much to be said for the fact that the
Motosoto License was OSI-approved. But any new project resurrecting the
Motosoto License today would not inspire confidence or increase trust
as a result of that license choice. (Maybe for a legacy project it
would be different.)  

To make use of another use of the word "standard", OSI approval
signifies to me that a license meets minimum standards of
acceptability, minimum standards of conformance to FLOSS norms, and I
believe this is true of the Motosoto License. But only some OSI-approved
licenses go further and inspire for me the kind of trust and confidence
spoken of in Luis's draft FAQ entry. (For me, these are not limited to
the licenses the OSI has recommended as popular or widely-used.)
 

 - RF






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

Re: [License-discuss] FAQ entry (and potential website page?) on "why standard licenses"?

[Richard Fontana]

On Mon, 28 Apr 2014 11:42:51 -0400
Ben Cotton  wrote:

> On Mon, Apr 28, 2014 at 11:26 AM, Lawrence Rosen
>  wrote:
> > I'm not quarreling with OSI's attempt to get everyone to use
> > approved licenses
> 
> Larry hit on my suggestion. Anywhere the word "standard" is used, some
> variant of "approved" or "OSI-approved" is a reasonable replacement.
 
I might be confused but when Luis speaks of "standard" licenses I
assumed he means a proper subset of the OSI-approved licenses,
perhaps approximately the set of licenses the OSI has labeled
"popular" (something I'm known to have criticized in the past), and I
took Larry's initial response to be based on the same interpretation.

To characterize all of the OSI-approved licenses as being "standard" in
a common-sense sense would really stretch the common-sense meaning of
"standard". For an arbitrary example I picked in going down the list of
OSI-approved licenses, to assert that there is something "standard"
about the Attribution Assurance License would be bizarre; I trust no
one would disagree with that. It's a *nonstandard* license. The fact
that it was approved by the OSI is very important but it does not
transform the Attribution Assurance License into something that is
"standard" in a common-sense sense.

As to whether it is appropriate to liken OSI to a standards group, that
seems to be an orthogonal issue -- it's a different use of the word
"standard" from the use I believe Luis is employing.


 - Richard

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

Re: [License-discuss] [Osi] [General enquiries] Contact to a german site

[Richard Fontana]

Ralf,

The folks behind OSLiC, noted below (http://dtag-dbu.github.io/oslic/)
are I believe mainly associated with Deutsche Telekom, so they might be
good contacts to seek out.

 - RF



On Sat, 05 Apr 2014 10:32:07 -0400
Patrick Masson  wrote:

> Ralf,
> 
> Sorry, but the OSI does not maintain on German language version of
> the OSI web site.
> 
> It's possible, others on this list or the license-discuss list might 
> have some additional resources. The OSI has collected some additional 
> information and have posted it here: 
> http://wiki.opensource.org/bin/Projects/Improving+License+Pages
> 
> In addition you may want to look at:
> https://www.softwarefreedom.org/resources/2008/compliance-guide.html
> http://www.linuxfoundation.org/programs/legal/compliance
> http://www.ifosslr.org/ifosslr/
> http://dtag-dbu.github.io/oslic/
> 
> Hope this helps,
> Patrick
> 
> 
> On 04/02/2014 09:31 AM, ralf_vonpetersdo...@gmx.de wrote:
> > Ralf von Petersdorff (ralf_vonpetersdo...@gmx.de) sent a message
> > using the
> > contact form at http://opensource.org/contact.
> >
> > Hi, I need a contact to the german OSI Site. I'm a license manager
> > and I want
> > learn more about the GPL and the correct using of part of OSS.
> > Please send me the contact details.
> > Many thanks in advance
> > cheers
> > Ralf
> >
> > Report as inappropriate:
> > http://opensource.org/mollom/report/mollom_content/14040223a48822b134
> >
> > ___
> > Osi mailing list
> > o...@opensource.org
> > http://projects.opensource.org/cgi-bin/mailman/listinfo/osi
> 

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

Re: [License-discuss] [Osi] [General enquiries] Dual License for CC0

[Richard Fontana]

On Thu, 3 Apr 2014 08:22:52 +0100
Simon Phipps  wrote:

> On 3 Apr 2014 00:59, "John Cowan"  wrote:
> >
> > Wilson, Andrew scripsit:
> >
> > > Interesting point, though.  I'd speculate that if the embedded
> > > "public license fallback" inside CC0 is ever sent to OSI as a
> > > stand-alone license, it would be approved.  It is mighty similar
> > > in effect to MIT/BSD/Apache, with the distinctive feature that it
> > > explicitly disclaims patent licensing, is clearly copyright-only,
> > > and therefore non-duplicative.
> >
> > I thought that was precisely why we rejected it.
> >
> 
> As I recall it was withdrawn by CC before we were forced to consider
> whether its explicit removal of any implied patent protection was in
> fact a breach of the OSD.
 
Yes, it was voluntarily withdrawn from consideration by Creative
Commons:
http://projects.opensource.org/pipermail/license-review/2012-February/000231.html

- R


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

Re: [License-discuss] Zimbra licenses ?

[Richard Fontana]

On Fri, 21 Mar 2014 09:08:06 +0100 (CET)
a...@free.fr wrote:

> Good morning (i'm living in France),
> 
> I do not found the Zimbra licenses on OSI web site :
> - Zimbra Public License :
> http://www.zimbra.com/license/zimbra-public-license-1-4.html
> - Zimbra Public EULA :
> https://www.zimbra.com/license/zimbra-public-eula-2-5.html
> - Zimbra Network LA :
> http://files.zimbra.com/website/docs/zimbra_network_la.pdf
> Do you plan to study?
 
As far as I know, no version of the Zimbra Public License was never
submitted to the OSI for approval as an open source license. I don't
think anyone would contend either of the two referenced EULAs are open
source licenses.

Were the Zimbra Public License to be submitted for OSI approval I
suspect the most interesting issue to consider would be its 'badgeware'
requirement.

 - RF




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

Re: [License-discuss] Pars pro toto: a fundamental(?) lack in (MIT licensed) (jquery) java-script packages?

[Richard Fontana]

On Thu, 2 Jan 2014 13:59:37 +0100
"Reincke, Karsten"  wrote:

> Question: Is it really necessary to add the MIT license to jquery for
> using this javascript library compliantly?

Note: IANYL, TINLA.

> So, we might say that Javascript libraries are
> distributed, namely in the form of source code.

Certainly distributed, though minified JavaScript is more
analogous to object code. 

> As an example, let us take the famous and very widely used jquery
> library ( https://jquery.com/ ) as. It is 'maintained' by an
> organization ( https://jquery.org/ ). It is licensed under the MIT
> license
> ( https://github.com/jquery/jquery/blob/master/MIT-LICENSE.txt ).
> Like all other instances of the MIT licenses with a customized
> copyright notice, it contains the requirement: 
> 
> "The above copyright notice and this permission notice shall be
> included in all copies or substantial portions of the Software."
> 
> If one downloads this package from the official download page
> ( https://jquery.com/download/ ), one unfortunately receives a
> package (a flat text file, even in its' compressed version) which
> does contain "the above copyright notice", but does not contain "this
> permission notice". Instead of this, it only offers a link to a
> license interpretation ( http://jquery.org/license/ ), being inserted
> into the first commenting lines. 

Which says, significantly, I think, for the issue here:

 "You are free to use any jQuery project in any other project (even
 commercial projects) as long as the copyright header is left intact."

> Based on these facts, we tend to conclude, that each user, who embeds
> jquery into his own pages, has manually to add "this permission
> notice" into that "copy" of jquery to which he links his pages - what
> probably means to add the complete license text. But - as far as we
> can see - this is 'not so often practiced' - perhaps because asking
> for that seems to be a kind of nitpicking.
> 
> Nevertheless: if we want to take the open source licenses really
> seriously, if we want to act compliantly and to fulfill the open
> source license conditions very thoroughly, then - as far as we can
> see for the moment - we have to add the license retroactively.
> Indeed, currently we are testing concrete solutions to do so
> ( http://opensource.telekom.net/oscad/fileadmin/js/jquery-1.5.2.js ).
> But from a viewpoint of a programmer, this is a suboptimal solution:
> Modifying an already tested component only for adding the license
> text is an unnecessary source of error.
> 
> Therefore, we want to ask: 
> 
> Are we right? Do we really have to add the MIT license to an MIT
> licensed package which does not contain this license? Or is there any
> way to distribute the library to our 3rd. parties in exact that form
> we received from jquery? 

I have considered this issue before. First, if you're really bothered by
the uncertainty here you can contact the jQuery Foundation or other
relevant authors -- it is possible they are not aware that some of us
think about this matter.

My view: by not including the full text of the MIT license themselves,
the jQuery authors are by implication giving everyone else permission
not to have to include it either. There are many issues of open source
license compliance analogous to this one which I interpret similarly.
If license foo literally requires X, but I the licensor myself do
something that implies a more liberal set of permissions than the
literal reading of license foo would indicate, it would be
preposterous for me to hold my licensees to a higher standard than I
myself exhibit. (Of course there may be reasons why you'd want to
'retroactively' include the license text anyway -- for example, this
might be convenient or helpful for your downstream customers. But I do
not think you are *required* to do this.) 

This assumes that the authors in question aren't in turn using other
people's MIT-licensed code as to which the full license text was
included.  

Any other interpretation seems unreasonable to me. It would defy common
sense: why would a project deliberately choosing one of the most
permissive licenses adopt a 'gotcha' sort of interpretation designed to
impose a burden greater than mere notice preservation, the true policy
reflected in the MIT license? The alternative interpretation would
further a policy of making open source license compliance more rather
than less difficult, which I do not think is in the interest of jQuery
specifically or open source generally.

I also assume that the non-inclusion of the full text of the MIT
license is done deliberately to save space, suggesting that licensees
are expected not to include the full text.

If the jQuery Foundation or the relevant authors clarified the matter
in favor of the stricter interpretation, I might change my opinion on
this.

 - RF


___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-b

Re: [License-discuss] Proposal to revise (and move?) the CC0 FAQ

[Richard Fontana]

On Thu, 14 Nov 2013 13:49:40 -0800
Simon Phipps  wrote:

> I don't favour a list of "rejected licenses" for just this reason,
> but I do favour a better rendition of our institutional memory so
> that people seeking the history of approval of licenses like CC0 or
> TrueCrypt can easily find the answer without needing to digest the
> full archives for the two licensing mailing lists.

Agreed. I discovered that TrueCrypt had been submitted for approval in
2006 (?) only because of a Twitter conversation.

> What's needed is an indexed activity catalogue for license approval
> at OSI. Perhaps we could raise a work group to prepare such a thing?

Good idea.

 - RF

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

Re: [License-discuss] Proposal to revise (and move?) the CC0 FAQ

[Richard Fontana]

On Wed, 13 Nov 2013 21:46:22 -0800
Luis Villa  wrote:

> Hey, all-
> I was just looking at the FAQ entry on CC0, and two things jump out:
> 
>1. It's extremely odd that we have a FAQ entry about one particular
>rejected license, and no others. I would recommend removing this
> FAQ entry on that grounds.

I am inclined to agree. John Cowan has said that this is in fact a
frequently asked question - is that the impression of anyone else?

> Tangentially, as I pointed out earlier on
> this list, we probably should maintain a list of rejected licenses,
> and the reasons for their rejections, so that future license authors
> (and license-review members!) can refer to those precedents in a
> useful, non-mythological, manner.

+1. Although:

>2. Whether the CC0 entry stays in the FAQ or moves to a list of
> rejected licenses,

CC0 was not rejected per se: it was withdrawn before the OSI board had
an opportunity to vote on it. (How many licenses have been 'rejected'
in any official sense?)

> if it stays anywhere on the site, it should be
> rewritten to make it neutral and historically accurate; it is neither
> of those things right now. Any takers? If not, I'll get to it
> eventually, but I'd love for someone else to tackle it.

I am not sure there should be a specific FAQ entry on CC0. Maybe one
unified question and answer on public domain dedications that notes the
history around CC0.

- Richard
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] FAQ suggestion

[Richard Fontana]

On Wed, 13 Nov 2013 21:46:50 -0800
Luis Villa  wrote:

> Karl, Richard, anyone else: any thoughts on this?

It seems a useful addition. I would suggest the following changes:

Use initial caps for 'open source definition'. 

Change 'perpetual and irrevocable' to 'perpetual'.

The draft entry ignores the fact that there are some licenses that have
been approved by the OSI but considered nonconformant to the FSD by the
FSD, but that may not be an important detail to emphasize here.

- Richard






> 
> 
> On Mon, Nov 11, 2013 at 1:59 PM, Luis Villa  wrote:
> 
> > That seems like a reasonable addition to me, and addresses real,
> > recent confusion.
> >
> > Karl and Richard are on planes today, and I would like to hear their
> > thoughts before taking it live, though.
> >
> > Thanks, Engel!
> > Luis
> > On Nov 10, 2013 10:38 AM, "Engel Nyst"  wrote:
> >
> >> Hello license-discuss,
> >>
> >> I would propose an additional paragraph to the FAQ, for the
> >> question What is "free software" and is it the same as "open
> >> source"?
> >>
> >> The text currently says:
> >> > One of the tactical concerns most often cited by adopters of the
> >> > term "open source" was the ambiguity of the English word "free",
> >> > which can refer either to freedom or to mere monetary price;
> >> > this ambiguity was also given by the OSI founders as a reason to
> >> > prefer the new term (see "What Does `free' Mean, Anyway?", and
> >> > similar language on the marketing for hackers page, both from
> >> > the original 1998 web site).
> >>
> >> At this point in the text, I'd suggest to insert a little
> >> explanation on the ambiguity in the use of the term of open source
> >> as well. Quick draft...
> >>
> >> > On the other hand, the term "open" applied to the source is
> >> > sometimes used in the sense of merely "provided" or "visible",
> >> > but the open source definition sets the criteria for "open
> >> > source" to software licenses that guarantee a set of perpetual
> >> > and irrevocable rights to every recipient.
> >>
> >> The text should then probably skip "furthermore", and continue...
> >>
> >> > The FSF uses a shorter, four-point definition of software freedom
> >> > when evaluating licenses, while the OSI uses a longer, ten-point
> >> > definition. The two definitions lead to the same result in
> >> > practice, but use superficially different language to get there.
> >>
> >> I hope it will help with a number of misunderstandings.
> >> ___
> >> License-discuss mailing list
> >> License-discuss@opensource.org
> >> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
> >>
> >

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

Re: [License-discuss] Proposal to revise (and move?) the CC0 FAQ

[Richard Fontana]

On Thu, 14 Nov 2013 10:32:59 -0500
"Tzeng, Nigel H."  wrote:

> The wording appears to me to be neutral, just mildly embarrassing for
> the OSI that it couldn't get it's act together to actually accept CC0
> or reject CC0 or provide a useful alternative for folks wishing to do
> a public domain declaration.  Instead it sat and dithered.

I don't think "couldn't get its act together" and "sat and dithered" is
fair. Existing processes for license certification were followed. The
license steward withdrew the submission of CC0 for approval following a
period of public debate (which I think lasted no more than a month or
so).

- Richard

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

Re: [License-discuss] license information improvement project - now with a mockup!

[Richard Fontana]

On Thu, 7 Nov 2013 09:28:54 -0800 (PST)
Brian Behlendorf  wrote:

> On Thu, 7 Nov 2013, Luis Villa wrote:
> > The board meeting notes, in every case that I'm aware of, are
> > pretty uninformative- they simply say approved/not approved. I'm
> > open to persuasion on this point, I suppose, but I'm inclined to
> > see it as noise/additional clutter.  
> 
> It's the validation that indeed the approval happened - sort of like
> a commit message that just references an issue ID.  Even if
> minimalist, useful for traceability.

I have found that the date of approval is sometimes of historical
interest.

 - RF

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

Re: [License-discuss] license information improvement project - now with a mockup!

[Richard Fontana]

On Wed, 6 Nov 2013 09:33:03 -0800
Luis Villa  wrote:

> - Any comments on what information is/isn't presented? 

Maybe a link to the license steward's FAQ, if any (perhaps with some
appropriate disclaimer that the OSI does not necessarily endorse
anything in such FAQs)? This will only be relevant to a few licenses but
some of them are among the more widely used ones.

> - Obviously this information will not all be available for all
> licenses. In those cases, should we simply omit reference to the
> information, or should we say something like "Canonical text: the
> canonical text is no longer available" or "OSI discussion: this
> license was approved before OSI's current mail archive system, and so
> the discussion is no longer available"? I think the latter.

Agreed. (Re the first example there are some cases where there really
never was a canonical text, so that might be an appropriate statement
for such cases.) 
 
> - MOST IMPORTANTLY: Any volunteers to gather more information for more
> licenses?

I offer to volunteer to the extent I have time. :)

 - RF

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

Re: [License-discuss] Rejected license list [was Re: TrueCrypt license (not OSI-approved; seeking history, context).]

[Richard Fontana]

On Mon, 14 Oct 2013 21:36:56 -0400
Richard Fontana  wrote:

> On Mon, 14 Oct 2013 16:35:20 -0700
> Luis Villa  wrote:
 
> > Your list would
> > presumably be a subset, as some licenses might have been submitted
> > and rejected without a later, false claim to being open source.
> 
> There are also licenses that are clearly (to me) open source but which
> have not been and are unlikely ever to be evaluated by the OSI. 
> 
> But there is a separate category of licenses that are claimed to be
> open source by their license stewards (at least implicitly in
> characterizing the software as open source) but have not been
> submitted for approval -- TrueCrypt is presumably an example of this. 

To clarify this: by the first category I mean licenses that are or
would be generally accepted as open source on some pragmatic and
historical analysis but, largely because they are legacy or obscure
licenses are unlikely ever to be submitted for approval. A somewhat
atypical example, but the one that first came to mind and certainly
historically notorious, is the 4-clause BSD license. Atypical because
the commentary on the OSI website seems to me to hint that it is not or
ought not be thought of as open source (see:
http://opensource.org/licenses/BSD-3-Clause
[unless I'm reading too much into what is said there]).

- RF

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

Re: [License-discuss] Rejected license list [was Re: TrueCrypt license (not OSI-approved; seeking history, context).]

[Richard Fontana]

On Mon, 14 Oct 2013 20:09:02 -0400
John Cowan  wrote:

> Luis Villa scripsit:
> 
> > Slightly more broad than that: a list of licenses that we have
> > rejected, including the rationales for rejection. Your list would
> > presumably be a subset, as some licenses might have been submitted
> > and rejected without a later, false claim to being open source.
> 
> I think publishing such a list would be a supremely bad idea.  Our
> business is to approve licenses, not to disapprove them. 

But if a license *has* been rejected (in some official way -- does
this actually apply to any submitted license, historically?) it is
highly useful to understand why, really just as useful as understanding
what's been approved (and why). 

 - RF
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Rejected license list [was Re: TrueCrypt license (not OSI-approved; seeking history, context).]

[Richard Fontana]

On Mon, 14 Oct 2013 16:35:20 -0700
Luis Villa  wrote:

> On Mon, Oct 14, 2013 at 4:06 PM, Karl Fogel 
> wrote:
> 
> > On Mon, Oct 14, 2013 at 5:32 PM, Luis Villa  wrote:
> > > Might be a good idea to finally start the list of non-open
> > > licenses
> > someone
> > > suggested a few months ago ;)
> >
> > Oh, that is *such* a good idea.
> >
> > This is the "list of licenses that people often mistake for being
> > open source, or whose authors claim are open source, but are
> > actually not or at least have not been evaluated by the OSI", right?
> >
> 
> Slightly more broad than that: a list of licenses that we have
> rejected, including the rationales for rejection. 

Excellent idea.

> Your list would
> presumably be a subset, as some licenses might have been submitted
> and rejected without a later, false claim to being open source.

There are also licenses that are clearly (to me) open source but which
have not been and are unlikely ever to be evaluated by the OSI. 

But there is a separate category of licenses that are claimed to be
open source by their license stewards (at least implicitly in
characterizing the software as open source) but have not been submitted
for approval -- TrueCrypt is presumably an example of this. 

- RF
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Open source license and non disclosure agreement

[Richard Fontana]

On Thu, 03 Oct 2013 15:59:38 +0200
Quentin Lefebvre  wrote:

> First of all, and to be completely clear about this, our point is not
> to make money with our project...
> 
> Let's start from another point of view.
> On http://qt-project.org/downloads , we can read :
> "Qt is available under GPL v3, LGPL v2 and a commercial license".
> 
> Can we investigate this approach a bit further...
> Indeed, it may be a good one for us. We may make our source code 
> available to the public through a LGPL license, with a way to work
> with companies through a more conservative license.

Some companies do take the approach of providing the same, or
related, versions of some software under open source and proprietary
licenses. If this is what you want to do, you should discuss it with a
lawyer. I personally find some of these practices quite problematic
(generally if they involve strong copyleft licensing on the open source
side and the other side is something more than what the FSF calls
'selling exceptions'), but not others.
 
> I may be still misunderstanding the point, but why isn't it what we
> want ? Don't we own a copyright on the software (as authors), even
> under LGPL ? To me, this point means that we can sign some agreement
> with a company in order to "control" its work and limit
> redistribution (of the modified work) to third parties.

Perhaps, but if that's all there is, I do not see how you can call it
open source, and in the instance where you are licensing the software
to a company under terms that prohibit distribution, that license that
the company gets is not an open source license, and therefore the
software that the company gets is not open source (unless it is
precisely identical to a version available under an open source
license).  
 
> >> But in GNU GPL's FAQ, here is what we found :
> >> http://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLAllowNDA ,
> >> http://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLAllowModNDA ,
> >> http://www.gnu.org/licenses/gpl-faq.en.html#DevelopChangesUnderNDA .
> 
> What about this third link ? 

That is about a corner case in GPL interpretation concerning the degree
to which NDAs are compliant with the GPL. I'm not sure how relevant
this (a situation that involves two separate legal instruments, a
software license and an NDA) is to your scenario. 

> If someone can accept a contract, why 
> wouldn't we be able to sign such contracts with developpers or
> companies (or students we teach), so that we can review their
> contribution prior to making it available to the public ?

Of course you can do that (assuming there are no legal constraints
upstream of you that would prevent this, etc.), but the issue I
understand you to be interested in is whether the result is that the
software is not open source, or not open source licensed.

Does the developer/company/student have any permission from you to
redistribute the software (without needing to check with you first)? If
not, I do not see how it would be describable as open source.  

- RF

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

Re: [License-discuss] Open source license and non disclosure agreement

[Richard Fontana]

On Thu, 03 Oct 2013 10:54:41 +0200
Quentin Lefebvre  wrote:

> Hi,
> 
> Currently working on an open source project, we are looking for an 
> appropriate license for it.
> 
> We would like something that allows us to work with people in a way
> such that :
>   - we can be informed of modifications of our program by developers,

Unless such a requirement were sufficiently narrowly tailored it would
IMO make a license not open source. Certainly no mainstream
OSI-approved license contains anything like such a requirement.

>   - we can have "our word to say" about redistribution of modified
> code (i.e. we would like to be able to explicitly authorize people to
> share the modified code).

That would obviously make the license not open source. 
 
> There is something in the GNU (L)GPL in article 2 that looks like
> what we want, but this 2nd article is not so obvious and seems in 
> contradiction with others. Here is what is said :

To clarify, this is from GPLv3, section 2.

> "You may convey covered works to others *for the sole purpose of
> having them make modifications exclusively for you*, or provide you
> with facilities for running those works, provided that you comply
> with the terms of this License in conveying all material for which
> you do not control copyright. Those thus making or running the
> covered works for you must do so exclusively on your behalf, under
> your direction and control, *on terms that prohibit them from making
> any copies of your copyrighted material outside their relationship
> with you*."

I believe you may be misunderstanding the point of this provision. It
is intended to carve out of the normal copyleft requirements the
situation where a company gives some software to an off-site contractor
for development or datacenter operations, in circumstances that might
otherwise be argued to be distribution to a third party in the GPLv2
sense. Anyway, this is not what you want. 

> But in GNU GPL's FAQ, here is what we found :
> http://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLAllowNDA ,
> http://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLAllowModNDA ,
> http://www.gnu.org/licenses/gpl-faq.en.html#DevelopChangesUnderNDA .
> 
> I'd be very pleased to have more information and explanations about
> this kind of non disclosure agreement. How is it possible exactly
> under the GPL or LGPL terms ?
> Should we maybe choose another license for our purpose ?
> Are our goals in total contradiction with open source software ?

Your goals appear to be essentially in total contradiction with open
source software. 

- RF

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

Re: [License-discuss] Started discussion with Figaro re their license.

[Richard Fontana]

On Thu, 19 Sep 2013 19:38:02 -0400
John Cowan  wrote:

> Karl Fogel scripsit:
> 
> > Just in case anyone else noticed this:
> > 
> >   
> > https://www.cra.com/commercial-solutions/probabilistic-modeling-services.asp
> > 
> > They want to be open source, and almost are, but they're using a
> > custom license based on 3-clause BSD with an extra clause -- clause
> > (4) -- that IMHO is problematic.  I've attached the license to this
> > mail.
> 
> I don't think it is.  Clauses 1 and 2 (as usual for BSD) require that
> the license itself be preserved by downstream distributors.  That
> license already includes the pointer required by clause 4 -- in the
> text of clause 4 itself.  So clause 4 is self-satisfying taken in
> conjunction with clauses 1 and 2.

Ah, but what does it mean to have a pointer to probabilistic modeling
services? :)
 
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] System 76's BeanBooks Public License v1.0

[Richard Fontana]

On Wed, 18 Sep 2013 01:06:31 -0400
Richard Fontana  wrote:

> "Submit" is susceptible to a broad reading that would give System76 a
> privileged license relative to everyone else (somewhat like the old
> NPL). 
 
Re-reading this, I may not have been sufficiently clear. Section
3.1 says: 

  A "Contribution" means any work of authorship that is Submitted by You
  to System76 in which You own or assert ownership of the Copyright.
  "Submit" means to provide a Contribution to System76 by any form of
  communication." 

It is possible to read this as wildly unbounded, so that anything over
which one holds copyright that is made publicly available falls under
the broad license of 3.3. I'm sure *that* was not intended, but
something less than that conceivably may have been (any derivative work
of 'the Software', say, that one makes public available, though not
specifically meant as an upstream contribution to System76, is
automatically available for use by System76 under the broader license).

I know from experience that these baked-in CLAs are really difficult to
draft well, so I don't want to be too critical of whoever drafted this. 

Under the first, broadest interpretation I give above, and maybe the
second one too, this clause would violate the 'spirit' of the OSD,
though possibly not the letter. We have OSD 9, which says "The license
must not place restrictions on other software that is distributed along
with the licensed software. For example, the license must not insist
that all other programs distributed on the same medium must be
open-source software." 

Here you have the license placing restrictions on other
software that is not even distributed along with the licensed software,
the problem being that it is insufficiently clear that it is meant to
be limited to the case of "other software" that is meant as an upstream
contribution to the work that was received. 
 
- RF
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] System 76's BeanBooks Public License v1.0

[Richard Fontana]

On Tue, 17 Sep 2013 19:50:29 -0700
Luis Villa  wrote:

> I just wanted to raise this thread again; I'm interested in
> discussion/comment from others but have had only the barest time to
> skim.

(Same here.)
 
> Sec. 3.3 strikes me as odd; essentially a very strong CLA baked into
> the license. Not non-free/open, per se, at least at first glance -
> just... odd?

"Submit" is susceptible to a broad reading that would give System76 a
privileged license relative to everyone else (somewhat like the old
NPL). *Presumably* this is not what was intended, but given the nature
of the rest of this license I am not entirely sure. The only reason why
I could see this being a non-free/non-open issue is the arguable lack of
clarity. (Compare Apache License 2.0 section 5, and the ASF CLAs.)

Policywise, the clause bothers me, because even if "Submit" is given a
narrow reading it still means that System76 is baking in a CLA that
gives it privileges not given to others. 

> Sec. 4.3 strikes me as actually conceptually somewhat interesting,
> inasmuch as many commercial lawyers have argued that this type of
> clause is often implicit in software that contains a protect trademark
> embedded in the software and not removed by a downstream licensee.
> This, obviously, makes it very explicit. I'd suggest that it violates
> the spirit of the OSD, but not necessarily the letter (again, with
> only very brief thought to the matter - I may be forgetting something
> obvious in the OSD).

I believe this violates the letter of the OSD.

OSD 2: The program must include source code, and must allow
distribution in source code as well as compiled form.

OSD 4: The license may require derived works to carry a different name
or version number from the original software.

OSD 5: The license must not discriminate against any person or group of
persons.

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

The BeanBooks license appears to make it a condition of the license that
if you're in one particular group (commercial redistributors), you have
to execute and possibly pay for an additional trademark license from
System76 to distribute copies of the software covered by *this license*
that you get from System76. 

Even if it is the case that the version provided by System76 contains
some embedded trademark, it should not be a condition *within* an open
source license that a fee-bearing trademark license is required for all
commercial redistribution, above all for forms of commercial
redistribution that are otherwise outside the scope of trademark law.  

As a separate matter, this license contains an archaic badgeware
provision in section 4.2. I also now consider badgeware conditions to
violate the OSD, though I recognize that was not the historical view for
narrowly-tailored badgeware provisions (and for the record in the
distant past I regarded the license this is based on, the Yahoo! Public
License 1.1, to be FLOSS, and it contained an identical or similar
badgeware provision). Badgeware provisions inherently violate the OSD
because they are in effect undue burdens placed on the right of
modification, and appear to have been invented precisely in order to
discourage modification, or at least modification by commercial
licensees. (OSD 3: "The license must allow modifications and derived
works..."). 

I also believe I goofed in regarding the Yahoo! Public License
badgeware provision to be acceptable in 2008 (or else my views must
have changed in some subtle way), because it is not narrowly tailored.
Notably, it does not account for the possibility that preservation of
logos will be technically impossible, a point which I remember being
brought up in the license-discuss criticism of badgeware licenses back
in 2006/2007. The same applies to the badgeware provision in the
BeanBooks license.


- Richard















> 
> Luis
> 
> On Wed, Aug 28, 2013 at 8:11 AM, Bradley M. Kuhn 
> wrote:
> > A colleague of mine asked for my comment on the following license:
> > https://beansbooks.com/home/opensource (included in full text below
> > for the archives).  It's reminiscent of the Yahoo! Public License
> > and Zimbra Public License.
> >
> > I notice that it seems that the Zimbra Public License and Yahoo! are
> > listed as Free Software licenses by the FSF but not as Open Source
> > by OSI.
> >
> > Does someone from OSI want talk to System 76 about this and why
> > this is a "bad idea" to make their own license?  System 76 is
> > generally a pretty friendly company to Open Source and Free
> > Software.
> > ##
> > URL: https://beansbooks.com/home/opensource BeansBooks Public
> > License v1.0
> >
> > This BeansBooks Public License (this "Agreement") is a legal
> > agreement that describes the terms under which System76, Inc., a
> > Colorado corporation (

Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com launched.)

[Richard Fontana]

On Wed, Aug 28, 2013 at 10:59:43AM -0400, Bradley M. Kuhn wrote:
> The GPL has always tried to go as far as copyright would allow to
> mandate software freedom.  That's what Michael Meeks (and/or Jeremy
> Allison -- I heard them both use this phrase within a few weeks of each
> other and not sure who deserves credit) call "copyleft's judo move on
> copyright".  It's the essence of strong copyleft.

A few sources credit Richard Stallman with saying that the GPL is "a
form of intellectual jujitsu, using the legal system that software
hoarders have set up against them" in a _Byte_ interview in July 1986.
However, I do not see any RMS interview in that issue of _Byte_ (which
is now available at archive.org).

The gnu.org site has republished what it says is a July 1986 _Byte_
interview of RMS, but this contains no jujitsu quote.

It seems likely that RMS *did* originate this characterization of the
GPL, and probably in a _Byte_ interview, but it would be nice to track
down the precise date of publication.

- RF

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

Re: [License-discuss] Open source license chooser choosealicense.com launched.

[Richard Fontana]

On Tue, Aug 20, 2013 at 03:01:24AM -0400, Richard Fontana wrote:
> license oompatibility, 

License compatibility, that is. :)


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

Re: [License-discuss] Open source license chooser choosealicense.com launched.

[Richard Fontana]

On Mon, Aug 19, 2013 at 08:48:06PM +0300, Engel Nyst wrote:
> Hello license-discuss,
> 
> On 08/18/2013 04:38 AM, Richard Fontana wrote:
> >Independent of this point, I'm concerned about inaccurate statements
> >made on the choosealicense.com site (one that we talked about was the
> >assertion that GPLv3 "restricts use in hardware that forbids software
> >alterations").
> 
> Please allow me to ask the impossible question: how would you write
> the summary of GPLv3 vs GPLv2 in 8-16 words?

"GPLv3 is lengthier, with additional provisions concerning patents,
'Tivoization', anticircumvention law, license oompatibility, and
cure".

- RF

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

Re: [License-discuss] Open source license chooser choosealicense.com launched.

[Richard Fontana]

On Sun, Aug 18, 2013 at 11:10:52AM -0400, Pamela Chestek wrote:
> On 8/17/2013 9:38 PM, Richard Fontana wrote:
> 
> Speaking just for myself, it is difficult for me to imagine any
> license chooser or license explanation site that I wouldn't think was
> more problematic than useful. Linking to a *wide* variety of license
> choosers or summary sites with a very strong caveat emptor statement
> might be okay.
> 
> Because you are so intimately familiar with the licenses and know every 
> feature
> and blemish, so you seek the perfect when maybe we should only aspire to the
> better-than-nothing. Maybe not; I read your slides and take your point that
> "nothing" isn't really all that scary. 

I really believe it is best for anyone to try to read the actual
license in question. A summary can be a reasonable starting point, but
it especially bothers me if it is distorted (as I think it may almost
always be) by political or cultural bias. Also, if a license is really
too difficult to understand, that is itself useful (for the would-be
licensor and for the license steward) to find out. 

- RF
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Open Source Eventually License Development

[Richard Fontana]

On Sat, Aug 17, 2013 at 08:44:02PM -0400, Bradley M. Kuhn wrote:
> Zooko,
> 
> It might be worth mentioning here that you and I have had discussions
> for years about the idea of drafting TGPPL as a set of exceptions to
> Affero GPLv3 and/or GPLv3.
> 
> I believe this is indeed possible, 

Not with an exception in the GPLv2 exception sense, and not without
the result being (A)GPLv3-incompatible, since under TGPPL each
downstream distributor appears to be required to give the grace
period. 

 - RF
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Open source license chooser choosealicense.com launched.

[Richard Fontana]

On Thu, Aug 15, 2013 at 10:17:47AM -0400, Bradley M. Kuhn wrote:
> Sorry for posting a month late on this thread [I hadn't poked into the
> folder for this list in some time], but I didn't see a consensus and
> wanted to add my $0.02.
> 
> Luis Villa wrote on 16 July:
> > In the long-term, I'd actually like OSI to promote a license chooser
> > of its own. But in the meantime I'm pretty OK with linking to a
> > variety of license choosers.
> 
> Richard Fontana pointed out in his OSCON talk that license choosers
> generally make political statements about views of licenses.  He used
> the GitHub chooser as an example, which subtly pushes people toward
> permissive licenses.
> 
> I was told GitHub's chooser accepts patches, and I was planning at some
> point to try to patch out this bias myself and see if my patch was
> accepted -- but of course any patch I produce is going to have subtle
> copyleft biases -- which I think was Fontana's point.
> 
> (Fontana, do I have that right?)

It is fairly obvious that the GitHub site's presentation of what
licenses it recommends, and why, is politically biased, though I
wouldn't say it "subtly pushes people toward permissive licenses".
Rather, the impression I get is that it was originally designed to
blatantly encourage non-copyleft licenses but threw in the GPL in its
top three recommended licenses as a kind of simple political
concession.

It is certainly true that any patch you make will reflect your own
political biases and maybe this is difficult for anyone to avoid
unless they either struggle to overcome or correct for bias or don't
have any bias to begin with.

Independent of this point, I'm concerned about inaccurate statements
made on the choosealicense.com site (one that we talked about was the
assertion that GPLv3 "restricts use in hardware that forbids software
alterations"). This is a general problem with all efforts I have seen
to summarize or provide simplified explanations of licenses, and it
happens even where the summary is provided by the license steward.

> Therefore, I think OSI should likely avoid license chooser lest OSI
> end up in the quagmire of taking a position in the copyleft/permissive
> debates.

Speaking just for myself, it is difficult for me to imagine any
license chooser or license explanation site that I wouldn't think was
more problematic than useful. Linking to a *wide* variety of license
choosers or summary sites with a very strong caveat emptor statement
might be okay.

 - RF
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Minor change to website

[Richard Fontana]

Pam, Luis: 
I have fixed this.
- Richard


On Fri, Aug 16, 2013 at 04:27:01PM -0700, Luis Villa wrote:
> Hi, Pam-
> Right place; right comment. I'm a bit out of pocket right now with
> regards to passwords for the site (a long, sad story involving
> multiple computers and a lot of travel ;) but will fix it at some
> point.
> 
> [Anyone else with access to the CMS on the list should feel free to
> fix as well :)
> 
> Luis
> 
> On Fri, Aug 16, 2013 at 1:13 PM, Pamela Chestek  
> wrote:
> > Apologies in advance if this is the wrong list --
> >
> > I was looking at the Open Source Licenses page
> > (http://opensource.org/licenses) and had one moment of ambiguity -- the
> > headings are "Popular Licenses" and "Other Approved Licenses." I found the
> > word "other" to be misleading; the licenses that are listed under "Popular"
> > are also on the page for "Other" licenses - as they should be, but the word
> > "other" suggests they wouldn't be. Should "other" be changed to "All"
> > perhaps?
> >
> > Pam
> >
> > --
> > Pamela S. Chestek, Esq.
> > Chestek Legal
> > PO Box 2492
> > Raleigh, NC 27602
> > 919-800-8033
> > pam...@chesteklegal.com
> > www.chesteklegal.com
> >
> > ___
> > License-discuss mailing list
> > License-discuss@opensource.org
> > http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] FAQ entry for slight variations in licenses?

[Richard Fontana]

On Thu, Mar 07, 2013 at 05:01:03PM -0600, Karl Fogel wrote:
> "Many older licenses have a variety of minor variations in the
> language. Unfortunately, it is not possible for OSI to review every
> variation, so we cannot say if a given variation is approved.  However,
> if you have a competent lawyer review the variation and you conclude
> that it is minor and could not possibly have any legal signifance, in
> terms of the license being compatible with the Open Source Definition,
> then if you use that license and call the licensed software 'open
> source', there is at least a possibility that any subsequent discussion
> with the OSI about it would go well.  Please use good judgement and be
> conservative in this situation."
> 
> Not terribly much more meaningful, really, but maybe enough for most
> people to work with & do what they need to do? :-)
> 
> Comments, missiles welcome...

One missile: The idea that you would need a lawyer, competent or
otherwise, to be involved in such review, though personally appealing
from a guild-aggrandizement standpoint, seems highly dubious, and
probably sends the wrong message.

 - RF

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

Re: [License-discuss] what would de-listing of licenses look like?

[Richard Fontana]

On Wed, Mar 06, 2013 at 08:49:37PM -0800, Bruce Perens wrote:
> The justification for de-listing presently accepted licenses is that:
> 
> 1. They are ambiguous or likely to perform in court in unexpected ways, should
> they ever be litigated. And thus they are harmful to their users. De-listing 
> is
> a prompt to the organization that originally created the license to replace it
> with an accepted license or to submit a new version with greater legal
> competence in its construction. These would be the "crayon" licenses, mostly,
> those written without legal counsel.
> 
> 2. They don't comply with the OSD and were accepted in error.
> 
> 3. They are both redundant and rarely used.
> 
> Those are the only justifications. You don't get to de-list something because
> you don't like its politics.

In my view, Bruce's justification 2 is the only justification: the
license does not comply with the OSD and was accepted in error.

I don't believe it is practical for the OSI to assess Bruce's
justification 1. As for Bruce's justification 3, I think the OSI does
enough here in its efforts to classify already-approved licenses. 

I certainly agree with Bruce that de-listing cannot be for political
reasons. The rationale must be somehow grounded in the OSD, much like
approval of licenses. 

> I think you need to have a committee review a proposal to de-list, with
> arguments from the submitter regarding the problems in the license, 

I agree with that.

> and with
> advice from an attorney on whether the suggested problems are really problems.

I don't agree with this, since my view is that the OSD should be the
basis for an argument for delisting, and you don't need to be, or to
get, a lawyer to interpret the OSD (more precisely, lawyers and
non-lawyers are equally competent to interpret the OSD).

- Richard







> 
>     Thanks
> 
>     Bruce
> 
> On 03/06/2013 08:23 PM, Luis Villa wrote:
> 
> On Wed, Mar 6, 2013 at 11:48 AM, Richard Fontana
>  wrote:
> 
> The Frameworx license is one of those OSI-approved licenses that I
> believe was approved "in haste". If OSI had such a procedure, I would
> recommend that the Frameworx license be reviewed for de-listing.
> 
> Any recommendations on what such a process would look like, Richard?
> I'm not super-enthused about the idea, but don't want to rule out
> anything without at least some discussion.
> 
> Luis
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
> 
> 

> begin:vcard
> fn:Bruce Perens
> n:Perens;Bruce
> org:Perens LLC
> adr:1563 Solano Ave.;;PMB 549;Berkeley;CA;94707;USA
> email;internet:br...@perens.com
> title:Strategic Consultant
> tel;work:+1-510-4PERENS (510-473-7367)
> url:http://perens.com/
> version:2.1
> end:vcard
> 

> ___
> License-discuss mailing list
> License-discuss@opensource.org
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

Re: [License-discuss] Questions about the Frameworx license.

[Richard Fontana]

> Alex writes:
> 
> >I would like to use the Frameworx license.

The Frameworx license is one of those OSI-approved licenses that I
believe was approved "in haste". If OSI had such a procedure, I would
recommend that the Frameworx license be reviewed for de-listing.


- RF

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

Re: [License-discuss] [FAQ] Is Open Source?

[Richard Fontana]

Would it be clearer to say:

  I have some code written in a scripting language. Does that mean
  it's open source by definition?


'Source code for a program written in a script language' is confusing
to me because, as phrased, it could describe situations where the
'source code' spoken of is different from the 'program written in a
script language'. In some such situations, the source code could be
open source and the program might be non-open source.


On Fri, Jan 25, 2013 at 12:37:18PM -0200, Bruno Souza wrote:
> How about being more to the point:
> 
> Just because I have the source code for a program written in a script language
> should I consider it open source?
> 
> We could reference a few script languages on the answer.
> 
> Bruno.
> 
> Weird? Mobile.
> 
> On Jan 25, 2013 10:06 AM, "Reincke, Karsten"  wrote:
> 
> > [...]
> > >
> > > "You can see the PHP source code, so it's Open Source, right?"
> >
> > That could be misleading, since "the PHP source code" could mean
> > https://github.com/php/php-src.
> >
> > How about:
> >
> > "FooProgram is written in PHP, and I have the source code.  Does that
> > mean it's definitely open source?"
> >
> > Matt Flaschen
> > ___
> 
> Perhaps this should be generalized because it's not specific for PHP, but
> relevant for all interpreter languages:
> 
> "FooProgram is written in ScriptLanguageBar, and I have the source code.
> Does that mean it's definitely open source?"
> 
> Best regards Karsten Reincke
> 
> ---
> Deutsche Telekom AG
> Products & Innovation
> Karsten Reincke, PMP(r)
> Fach-Senior Manager
> Open Source Review Board - T&P/A&S/TM
> T-Online-Allee 1
> 64295 Darmstadt
> Tel.: +49 6151 680 - 8941
> Fax.: +49 6151 680 - 2529
> E-Mail k.rein...@telekom.de
> http://www.telekom.de/
> 
> Erleben, was verbindet.
> 
> 
> 
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
> 

> ___
> License-discuss mailing list
> License-discuss@opensource.org
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

Re: [License-discuss] proposal for revising (and making relevant) the code of conduct

[Richard Fontana]

On Wed, Jan 02, 2013 at 08:04:23PM -0800, Luis Villa wrote:
> Sigh. The actual attachments are as follows:
[...]

+1 from me.

 - RF

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

Re: [License-discuss] License which requires watermarking? (Attribution Provision)

[Richard Fontana]

On Wed, Dec 19, 2012 at 12:34:33AM -0500, Richard Fontana wrote:
> I believe that the OSI's approval of CPAL (the license you may be
> intentionally not naming) was, in retrospect, wrongly decided.

To be fair, and to spread the blame around, the FSF's decision that
CPAL is a free software license was also wrongly decided, as was the
Fedora Project's decision that CPAL was free for purposes of Fedora
(which appears to be my fault -- sorry Tom!). I believe Debian treats
CPAL as DFSG-free but whether this was a wrong decision depends on
whether a decision was actually made, I suppose.

- RF
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] License which requires watermarking? (Attribution Provision)

[Richard Fontana]

On Tue, Dec 18, 2012 at 09:17:11PM -0800, Rick Moen wrote:
> An FSF author involved with the GPLv3 draft speaks to FSF's intent
> (FWIW):  http://gplv3.fsf.org/additional-terms-dd2.html
> 
>   A GPL licensee may place an additional requirement on code for which
>   the licensee has or can give appropriate copyright permission, but only
>   if that requirement falls within the list given in subsection 7b.
>   Placement of any other kind of additional requirement continues to be a
>   violation of the license. Additional requirements that are in the 7b
>   list may not be removed, but if a user receives GPL'd code that purports
>   to include an additional requirement not in the 7b list, the user may
>   remove that requirement.
> 
> The literal wording of 7b is exactly as quoted above.

This 7b refers to the 7b of GPLv3 Discussion Draft 2, which contained
the whole 'additional requirements' portion of section 7. In later
drafts of GPLv3, and in the final version, there were no subsections
of section 7, and 7b is one of the enumerated list of allowable
additional requirements. 

- RF

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

Re: [License-discuss] License which requires watermarking? (Attribution Provision)

[Richard Fontana]

On Tue, Dec 18, 2012 at 08:58:16PM -0800, Rick Moen wrote:
> As you have noticed, some firms have now adopted the clever if sleazy
> -- my interpretation -- ploy of purporting to use GPLv3 but sliding a
> mandatory badgeware notice requirement for every single UI page by
> claiming those are Additional Terms within the meaning of GPLv3 clause
> 7.
> 
> I personally think that is a total crock, and hope it gives rise to
> litigation at some point:  Clause 7 is a mechanism for adding
> _exceptions_ to the conditions GPLv3 would otherwise require.  The dodge
> of claiming you can add _restrictions_ via that clause or similar
> methods such as hanging a restriction off GPLv2 -- and the sheer
> dishonesty of pretending that is still open source -- almost certainly
> doesn't fool anyone.

Actually, section 7 of GPLv3 was intended to allow a limited form of
badgeware (as well as certain other kinds of restrictions). But the
example cited by the original poster:
http://www.nopcommerce.com/licensev3.aspx 
goes well beyond what the FSF intended to authorize. 
Unfortunately, I have seen a number of such misuses of GPLv3/AGPLv3 7(b).

As for adding a similarly-broad badgeware requirement on top of GPLv2,
it would be enough of a stretch to argue that limited GPLv3-acceptable
badgeware provisions are acceptable under GPLv2.

I believe that the OSI's approval of CPAL (the license you may be
intentionally not naming) was, in retrospect, wrongly decided.

 - RF

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

Re: [License-discuss] objective criteria for license evaluation

[Richard Fontana]

On Mon, Dec 10, 2012 at 10:57:10AM +, Gervase Markham wrote:
> On 09/12/12 18:46, Luis Villa wrote:
> >So let me restate the question to broaden it a bit. If you had a
> >*blue-sky dream* what subjective information would you look at?
> >
> >For example, if you had the resources to scan huge numbers of code
> >repositories, what numbers would you look for?
> >
> >* ranking by LoC under each license
> >* ranking by "projects" under each license
> >* ... ?
> 
> If we are blue-sky dreaming, then I would like to rank by "_useful_,
> unique lines of code under each license". "Useful" in the sense that
> some half-finished barely-compiling "my first Windows CD player" on
> Sourceforge counts for nothing, whereas jQuery counts for a lot.
> "Unique", in the sense that I shouldn't be able to game the stats by
> going to github and forking every project with my preferred license.

I can also imagine other metrics of license popularity. Download
statistics are problematic but it is the usual metric for distro
popularity. One might be able to measure the size of contributor and
user communities (numbers of committers, numbers of unique patch
authors for a given release, subscriptions to mailing lists...?).
 
[...]
> I think there is also a place for "lawyers generally think it's
> vague and has sub-optimal word choice", which might apply to e.g.
> Artistic v1.

I think that's highly problematic. I really don't think one can
successfully attempt to measure consensus among lawyers regarding
specific open source licenses. You could probably find enough lawyers
to criticize features of any number of OSI-approved licenses, and
there is also the problem (to which the GPL family is especially
vulnerable for historical reasons) of 'popular' licenses being
scrutinized for flaws more severely than less widely-used licenses. 

As for 'suboptimal word choice' that seems unavoidably subjective, and
probably can be legitimately applied to every single OSI-approved
license, including all of the ones assumed to be the most popular, and
probably every software license that's ever been drafted. 

- RF

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

Re: [License-discuss] Making the PHP FAQ generic

[Richard Fontana]

On Fri, Dec 07, 2012 at 01:07:23PM -0600, Karl Fogel wrote:
> Also, it might good to talk about implementations of languages being
> open source, rather than the languages themselves.  It's a bit pedantic,
> but I think it can be worded naturally, and it would emphasize the
> conceptual cut one has to make to really understand the answer.  If you
> compile your C program with Borland's C compiler, that doesn't make your
> program closed-source; by the same token, if you run your Python program
> on the most widely-used implementation of Python, which is open source,
> that doesn't make your code open source by default.
> 
> People who ask that question may think they're asking about the
> language, but they're really asking about the particular language
> implementation.  This should be made clear to them in the answer.

+1. I encounter a surprising amount of confusion about this point.

 - Richard

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

Re: [License-discuss] The alphabetical list

[Richard Fontana]

On Mon, Nov 12, 2012 at 11:19:17PM +0200, Henrik Ingo wrote:
> On Mon, Nov 12, 2012 at 11:10 PM, Luis Villa  wrote:
> > Heard loud and clear re usefulness of the alphabetical list; it will
> > not go away.
> >
> > I'm surprised by that, so (in a different thread) I'd welcome more
> > detail on what people use it for.
> 
> User story:
> 
> Henrik needs to look up (or link to) the Acme Corporation Public
> License. He goes to opensource.org, and clicks on "Open Source
> Licenses". Since he knows the name of the license he wants to look up,
> he clicks on "Licenses by Name". He then presses Ctrl+F to search for
> the wanted license within the alphabetical list.

This is generally why I've found the alphabetical list useful too.

It's good for looking up the relatively obscure OSI-certified licenses
which happen to have some official name; such licenses are often more
difficult to find elsewhere.

 - Richard






> 
> This is pretty much the only way I personally ever look up a license.
> 
> henrik
> 
> --
> henrik.i...@avoinelama.fi
> +358-40-8211286 skype: henrik.ingo irc: hingo
> www.openlife.cc
> 
> My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] proposal to revise and slightly reorganize the OSI licensing page [revisited]

[Richard Fontana]

On Sun, Nov 11, 2012 at 04:01:03PM -0800, Luis Villa wrote:
> 2. REVISE /LICENSES/ : The "Open Source Licensing" page (replacing the
> current http://opensource.org/licenses/)  would say (hopefully all
> changes self-explanatory):
> 
> "
> Open source licenses are licenses that comply with the Open Source
> Definition[link] - in essence, they allow software to be used,
> modified, and redistributed without restriction. 

I don't agree with the "in essence" part. 

> * In the longer term, once Drupal is upgraded, it will likely make
> sense to generate http://opensource.org/licenses/alphabetical and
> http://opensource.org/licenses/category programatically, rather than
> through the current manual listing, which is of course error-prone.
> (Some people have suggested doing away with the alphabetical list
> altogether, which I personally would be fine with.) 

I've actually found the alphabetical list useful at times, FWIW.

- Richard

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

Re: [License-discuss] plain text license versions?

[Richard Fontana]

On Thu, Sep 06, 2012 at 06:13:11PM -0400, John Cowan wrote:
> Richard Fontana scripsit:
> 
> > That assumes that the printed text is not "source code" in the sense
> > meant in sections 1 and 2 of GPLv2 but is instead "object code or
> > executable form" (section 3). I believe the better interpretation of
> > GPLv2 is that text in a printed book is "source code ... in any
> > medium" (the particular medium being printed text); thus you never
> > reach section 3.
> 
> "The source code for a work means the preferred form of the work for
> making modifications to it."  

Leaving aside the fact that this definition only appears in section 3
(GPLv3 is different here), I regard the preferred form of
human-readable text as human-readable text (e.g. not some encoded or
obfuscated form), which GPLv2 section 1 says I can distribute "in any
medium". "In any medium" implies that the source code (even if it is
by definition "the preferred form for making modifications") can be
distributed without triggering section 3 regardless of the nature of
the medium of distribution. If your interpretation is correct then the
question arises why the words "in any medium" appear in GPLv2 section
1. It doesn't say "You may copy and distribute verbatim copies of the
Program's source code as you receive it, provided that you only do so
in a machine-readable medium that is preferable as a medium for
modification of the source code". IOW I think "form" and "medium" must
mean different things in the GPL.

- RF

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

Re: [License-discuss] plain text license versions?

[Richard Fontana]

On Thu, Sep 06, 2012 at 03:07:44PM -0700, Luis Villa wrote:
> As a practical matter, indicating, tracking and relying on waiver is a
> bit of a pain. e.g., lets say upstream says:
> 
> "I give you a copy of the license this work is licensed under by
> pointing you at http://www.apache.org/licenses/LICENSE-2.0.html";

Not entirely unlike the standard ASF-recommended license notice in
specifying the canonical Apache License 2.0 URL. 

> Downstream now has a problem: does this text constitute a waiver? Is
> this indication that we can "give any other recipients... a copy"
> (Apache 4.1) in the same manner? The easiest solution to this
> (admittedly small) problem is... to include a full copy of the
> license.

I have encountered situations similar to this and I typically treat
them as a waiver of the requirement to provide downstream recipients
with (in this case) a copy of the license text by doing more than
upstream bothered to do for me. I apply that principle so extensively
in open source contexts (not just to issues of license text inclusion)
that I ought to come up with some sort of Latin legal maxim for it.

> Or to put it another way: OSI spent a lot of time and energy
> discouraging people from using custom licenses. Custom waivers
> (particularly for something trivial like this) are just another form
> of the same mess.

The usual situation is that the waiver (if you accept my
characterization of it as a waiver) is implicit. The FSF has tried to
encourage the practice of explicit exceptions ("additional
permissions" in GPLv3 parlance) to literal (or presumed) license
requirements but it hasn't had much effect on behavior in the GPL
licensor community. 

- RF

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

Re: [License-discuss] plain text license versions?

[Richard Fontana]

On Thu, Sep 06, 2012 at 05:45:00PM -0400, John Cowan wrote:
> Rick Moen scripsit:
> 
> > Years ago, I reminded readers on this mailing list that possibly useful
> > reciprocal licences for non-software use by people disliking GFDL
> > include GPLv2, and that FSF even published a piece explaining the
> > advantages before they fell in love with GFDL:
> 
> The difficulty is that text often winds up in printed books, and then
> you either have to distribute a CD with the book containing the editable
> source, or be prepared to issue such CDs for no more than the cost of
> distributing them.   Both are expensive and awkward activities, and
> neither is well-supported by the printed-book sales channels that exist.

That assumes that the printed text is not "source code" in the sense
meant in sections 1 and 2 of GPLv2 but is instead "object code or
executable form" (section 3). I believe the better interpretation of
GPLv2 is that text in a printed book is "source code ... in any
medium" (the particular medium being printed text); thus you never
reach section 3.

 - RF

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

Re: [License-discuss] plain text license versions?

[Richard Fontana]

On Thu, Sep 06, 2012 at 02:37:38PM -0700, Lawrence Rosen wrote:
> Is distribution of the *link* to the license sufficient compliance with this 
> requirement? 

For licenses that appear literally to require inclusion of a copy of
the license text? I have wondered whether we ought to start treating
that as a reasonable modern interpretation of such requirements, given
that many developers aren't bothering to bundle license texts to begin
with.

 - RF





> 
> /Larry (from my tablet and brief) 
> 
> Luis Villa  wrote:
> 
> >On Thu, Sep 6, 2012 at 12:14 PM, Lawrence Rosen  wrote:
> >> Karl Fogel wrote:
> >>> Many coders expect to find plaintext license terms in a LICENSE or
> >>> COPYING file, directly in the source tree.
> >>
> >> I'd count that as another reason *not* to provide plain text license 
> >> files. I think it would be FAR more useful to have a simple license 
> >> statement in the source tree of each program that points to the OFFICIAL 
> >> version of that license on the OSI website. This also avoids the 
> >> duplication of text -- with potential transcription or legal errors -- in 
> >> many source code trees, and completely avoids the need to actually read 
> >> the licenses if one trusts OSI.
> >>
> >> Doesn't CC do that, in a way, with their license logos?
> >
> >More specifically, CC does it with the requirement in the license that
> >attribution notices link to the canonical text. Many OSS software
> >licenses, unfortunately, require distribution of the actual text of
> >the license.
> >
> >Luis
> ___
> License-discuss mailing list
> License-discuss@opensource.org
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Can copyrights be abandoned to the public domain?

[Richard Fontana]

On Tue, Aug 14, 2012 at 11:22:05AM -0700, Rick Moen wrote:
> Quoting Richard Fontana (rfont...@redhat.com):
> 
> > I believe I am the counsel Tom is referring to, though the Fedora
> > policy conclusion Tom refers to was prepared by Tom. Nevertheless I
> > would see it as Fedora adopting more or less the liberal and pragmatic
> > view I have had on this subject for a long time. 
> 
> Seems reasonable to me.
> 
> Correct me if I'm wrong (you're the professional), but I would imagine
> the relevant question for Red Hat, Inc. was not whether the erstwhile
> copyright owner actually succeeded in eradicating legal title to his/her
> copyright property (what is properly meant by 'public domain'), 

Yes. I agree with you that 'public domain' is a misnomer (but no more
than, say, the use of 'proprietary' to mean 'not free-as-in-freedom
software').

> but rather whether Red Hat, Inc. will be reasonably protected
> against infringement claims by either the owner's success or by
> estoppel.

Close enough, but I wouldn't want you to think Red Hat is just
concerned about Red Hat. We presume that software we consider open
source/free software allows certain permissions to everyone, not just
Red Hat, or we'd classify it otherwise.[1] The "public domain"-labeled
stuff we distribute in open source distribution contexts is code we
consider open source software (equivalent, essentially, to what is now
achievable through the quite detailed CC0). 

There are strange things I've seen in my time, like "public domain for
noncommercial purposes". We would treat that as
nonfree/non-open-source.

  - RF

[1]Incidentally, I seem to remember encountering at least one case of
a license that said the equivalent of "everyone *except* Red Hat is
free to use this code". Also not free software/open source. :)
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Can copyrights be abandoned to the public domain?

[Richard Fontana]

On Tue, Aug 14, 2012 at 01:10:49PM -0400, Matthew Flaschen wrote:
> On 08/14/2012 11:52 AM, Tom Callaway wrote:
> > Fedora used to spend a lot of time stressing out over this question, but
> > recently, after counsel with Red Hat Legal, we concluded that if someone
> > is explicitly and clearly abandoning their copyright on a work (as in
> > CC-0, for example), treating that work in good faith as being in the
> > public domain presented a very minimal amount of risk, especially since
> > such a declaration, were it to go to trial, would likely limit the
> > effectiveness of the copyright "holder" suing for infringement.
> 
> CC0 (http://creativecommons.org/publicdomain/zero/1.0/legalcode)
> actually has an explicit license fallback in section 3, for cases where
> the PD dedication fails.  I would be interested to hear if the counsel's
> conclusion would hold without such fallback.

I believe I am the counsel Tom is referring to, though the Fedora
policy conclusion Tom refers to was prepared by Tom. Nevertheless I
would see it as Fedora adopting more or less the liberal and pragmatic
view I have had on this subject for a long time. Since most of the
self-described "public domain" code we encounter is not actually under
CC0 (most of it is legacy code, in rarer cases it's whole packages
like SQLite), CC0 is not directly relevant. However (modulo that "or
patent" language :) CC0 approximates nicely the way I think we should
analyze the more typical kinds of simple public domain dedications we
encounter in FOSS code.

  - RF

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

Re: [License-discuss] CPOL 1.02

[Richard Fontana]

On Wed, Apr 04, 2012 at 04:32:09PM -0700, Lawrence Rosen wrote:
> The CPOL 1.02 license was discussed on this list in 2009. [1, and see
> attached.) As far as I can tell from reading my old emails and reviewing the
> OSI license list, it was never approved by OSI. Richard Fontana said this 
> about
> it on 10/5/2009:
> 
>  
> 
> This license recently came to our attention at Red Hat. The CPOL fails to meet
> the Open Source Definition (and Free Software Definition) in numerous ways.
> I've already been in contact with people at codeproject.com about this.
> 
>  
> 
> Yet Black Duck reports that this is the 8th most popular open source license.

Heh. The CPOL was just being discussed in the legal track I'm in at
LFCollab today. I reiterated my view that it is not a free software or
open source license and that no one should use any code under it. :)

- RF





> [1]
> 
>  
> 
> Popularity isn't all that matters!
> 
>  
> 
> /Larry
> 
>  
> 
> [1] http://www.codeproject.com/info/cpol10.aspx
> 
> [2] http://osrc.blackducksoftware.com/data/licenses/
> 
>  
> 
>  
> 
> Lawrence Rosen
> 
> Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)
> 
> 3001 King Ranch Road, Ukiah, CA 95482
> 
> Cell: 707-478-8932
> 
>  
> 

> Date: Mon, 5 Oct 2009 12:44:06 -0700
> From: Joe Bell 
> To: license-discuss@opensource.org
> Subject: First Post / Question Regarding CPOL 1.02
> X-Mailer: Microsoft Office Outlook 12.0
> 
> Hi all:
> 
>  
> 
> This is my first post to this particular discussion group - please be gentle
> and refer me to a FAQ if I egregiously violated any list rules. 
> 
>  
> 
> My question is regarding the Code Project Open License (http://
> www.codeproject.com/info/cpol10.aspx) and whether or not anyone has done a
> “rigorous” analysis of it - I did notice that it isn’t an OSI-approved open
> source license, but the fact is that it does cover quite a variety of useful 
> C#
> and .NET projects on the Code Project website and I’d be interested to learn
> other’s opinions on any gotchas and/or loopholes in this license.
> 
>  
> 
> Best regards,
> 
> Joe
> 
>  
> 
> 
> This message is confidential to Prodea Systems, Inc unless otherwise indicated
> or apparent from its nature. This message is directed to the intended 
> recipient
> only, who may be readily determined by the sender of this message and its
> contents. If the reader of this message is not the intended recipient, or an
> employee or agent responsible for delivering this message to the intended
> recipient:(a)any dissemination or copying of this message is strictly
> prohibited; and(b)immediately notify the sender by return message and destroy
> any copies of this message in any form(electronic, paper or otherwise) that 
> you
> have.The delivery of this message and its information is neither intended to 
> be
> nor constitutes a disclosure or waiver of any trade secrets, intellectual
> property, attorney work product, or attorney-client communications. The
> authority of the individual sending this message to legally bind Prodea 
> Systems
> is neither apparent nor implied,and must be independently verified.
> 

> ___
> License-discuss mailing list
> License-discuss@opensource.org
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

Re: [License-discuss] Is the old style MIT license a Free Software license

[Richard Fontana]

On Tue, Mar 13, 2012 at 02:31:09PM -0500, Karl Fogel wrote:
> Johnny Solbu  writes:
> >Hi.
> >I tried maling FSFs licensing department, but the FSFs website says
> >something to the effect that if they have answered the question on
> >their webpage, the mail will be unanswered, and I have not received a
> >reply. So I'm asuming it is answered on their website. However I
> >cannot find the answer to this specific question, and Google is of no
> >help. So I'm trying this list instead.
> >
> >I am packaging an old game I recently discovered, which is still in
> >active development.
> >The game (netrek-client-cow) have MIT or an MIT-like license (at least
> >I think it's MIT), which have a "and without fee" clause. And I am
> >unsure whether that this clause is compatible with Free Software or
> >not. To someone like me, this looks like what we today call a no
> >commercial clause.
> >I have discovered that it most likely is what Fedora call MIT old
> >style. (http://fedoraproject.org/wiki/Licensing:MIT#Old_Style)
> >
> >So my question is, is this a Free Software license?
> 
> I believe the "without fee" here refers to payment to the original
> licensor, and does not require that further redistribution be without
> fee (though it certainly permits that).
> 
> It's slightly different from the text of the current MIT license at
> 
>   http://www.opensource.org/licenses/alphabetical
> 
> I don't know if OSI ever considered the old-style MIT language.  Does
> anyone here know?

OSI approved a sort of template legacy license that it called
"Historical Permission Notice and Disclaimer"
http://opensource.org/licenses/HPND 

which is at least similar to the license(s) being asked about here.

What I find curious is the statement that the license "has been
voluntarily deprecated by its author", as it is not clear that this
even refers to a single license. 

Fedora (thanks to Tom Callaway) attempts to catalogue all the versions
of the MIT/X11 license family that it encounters. I don't recall
whether we ever encountered a license in this family that we
considered non-FLOSS (I don't think so, though I think there may have
been one or two close cases).

- Richard





> 
> -Karl
> 
> >There is two license text files, one is possibly newer that the
> >other. At least one of the licence files seems to be from 1986, and
> >the other from 1989.
> >The license text in full reads:
> >== 1 ==
> >Permission to use, copy, modify, and distribute this
> >software and its documentation for any purpose and without
> >fee is hereby granted, provided that the above copyright
> >notice appear in all copies.
> >
> >== 2 ==
> >Permission to use, copy, modify, and distribute this software and its
> >documentation for any purpose and without fee is hereby granted, provided
> >that the above copyright notice appear in all copies and that both that
> >copyright notice and this permission notice appear in supporting
> >documentation.  No representations are made about the suitability of this
> >software for any purpose.  It is provided "as is" without express or
> >implied warranty.
> >



> ___
> License-discuss mailing list
> License-discuss@opensource.org
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

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

Re: [License-discuss] a GPLv3 compatible attribution for MIT/BSD?

[Richard Fontana]

On Wed, Feb 01, 2012 at 05:30:54PM -0800, Rick Moen wrote:
> In the last decade, the aforementioned group of Web 2.0 / SaaS 
> hucksters started referring to mandatory runtime advertising as
> 'attribution', too -- a rather propagandistic sleight of tongue, in my
> view -- an approach that reached the pinnacle of absurdity with SugarCRM
> Community Edition 5.x's perversion of GPLv3, using clause 7b to
> re-implement the same obnoxious name-and-graphical-logo on every page
> requirement widely rejected in the openly badgeware licences that they
> claimed were open source.  One of my analyses:
> http://linuxgazette.net/159/misc/lg/sugarcrm_and_badgeware_licensing_again.html
> 
> Quoting:
> 
>GPLv3 section 7 is _not_ about attribution provisions. It is about
>required legal notices (e.g., trademark) and other permitted
>supplementary terms. Clause 7b says that "Requiring preservation of
>specified reasonable legal notices or author attributions in that
>material or in the Appropriate Legal Notices displayed by works
>containing it" are permitted, but I very much doubt that FSF had in
>mind required, immutable runtime display of trademarked logos and
>advertising on every user interface screen of the program and all
>derivatives -- which has the obvious effect of severely impairing
>freedom of third-party commercial use. 

The only thing I would take issue with is characterizing what SugarCRM
did (at least if you're talking about the initial version that was
released under GPLv3, since I haven't followed it since then) as a
"perversion", because as a matter of historical record it was done
with the FSF's blessing, and through a negotiation with the FSF's
lawyers (which, at the time and for that purpose, was me).

I wrote some of my recollections about this on debian-legal recently,
on a thread that I believe Clark started.
http://lists.debian.org/debian-legal/2011/12/msg00038.html
http://lists.debian.org/debian-legal/2011/12/msg00045.html

I have since had significant misgivings about this relatively late
change to GPLv3, and I've seen how it's been abused. I've also come to
see, as I admit I did not quite see clearly in those days, what was so
fundamentally wrong at a deeper level with badgeware (beyond the mere
typical burdensomeness of the requirement itself). In some ways I see
the badgeware episode as the jumping of the shark moment of that
particular era of experimentation with open source business models.

A key thing which I've seen abused is an elimination of the intended
limited scope of the "Appropriate Legal Notices" requirement. While in
theory a GPLv3 licensee may be subject to this requirement under some
circumstances, the way one implements ALN is up to that licensee, and
cannot be mandated by the upstream licensor. Yes, "reasonable author
attributions", including in some cases graphical logos, may have to be
"preserved", but one could do so in a far more minimalist fashion than
the upstream licensor had done, for example.

The provision was certainly not intended to import the standard
badgeware practices being debated on license-discuss in those
days. Indeed, I was greatly influenced by those discussions when I
worked with the FSF on drafting those changes and articulating what
the limits of their reasonable use were supposed to be. 

> An FSF author involved with the GPLv3 draft speaks to FSF's intent
> (FWIW):  http://gplv3.fsf.org/additional-terms-dd2.html
> 
>   A GPL licensee may place an additional requirement on code for which
>   the licensee has or can give appropriate copyright permission, but only
>   if that requirement falls within the list given in subsection 7b.
>   Placement of any other kind of additional requirement continues to be a
>   violation of the license. Additional requirements that are in the 7b
>   list may not be removed, but if a user receives GPL'd code that purports
>   to include an additional requirement not in the 7b list, the user may
>   remove that requirement.

As it happens I wrote that document, although that was well before the
(for lack of a better term) quasi-badgeware modification was made to
GPLv3's later drafts.

- Richard


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

Re: [License-discuss] CDDL 1.1 and GPL 2 with CPE

[Richard Fontana]

On Wed, Feb 01, 2012 at 03:23:09PM -0500, Gervais, Mathieu wrote:
> Hi,
> 
> Is there any particular reason why CDDL1.1 and GPL2 _with classpath 
> exception_ are not approved by the OSI ?
> (i.e.  http://glassfish.java.net/public/CDDL+GPL_1_1.html )

I am not sure when CDDL 1.1 was introduced but I think it was
relatively recently.

I think the typical OSI modern tradition has been to wait for the
license steward to request OSI approval, a general issue which someone
raised on one of these OSI lists some time ago. (I believe exceptions
around late 2007 included GPLv3 and its siblings for the reason that
the FSF would never submit those licenses itself, along with the
presumed inherent importance of those licenses.)

So, I would assume it is up to Oracle to decide whether to submit CDDL
1.1 for OSI approval. (Is anyone from Oracle on this list?)

Some ASF discussion of CDDL 1.1 vs CDDL 1.0 here:
https://issues.apache.org/jira/browse/LEGAL-121

The Classpath Exception may be another matter. I don't see the value
of OSI approval of GPLv2+Classpath Exception (ignoring the question
whether there's really a canonical version of it) since OSI has in
modern times generally not bothered to approve GPL+permissive
exception permutations, to my recollection.

As for approving CDDL1.1+GPLv2 with Classpath Exception as though it
were a single license, I think that would be unprecedented. Sun never
asked for approval of CDDL 1.0 and GPLv2 + Classpath Exception as a
single license package, SFAIK. 

- Richard

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

Re: [License-discuss] GPL and non-GPL binaries in one distribution

[Richard Fontana]

On Thu, Jan 12, 2012 at 05:34:45PM -0700, Chad Perrin wrote:
> If the FSF's is the more restrictive interpretation, you then
> need to consider cases where the FSF has taken up the mantle of defender
> of works for which it arguably did not have a notable direct copyright
> interest, as in the Busybox mess 

You appear to be mixing up either SFLC or SFC with FSF.

- RF

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

Re: [License-discuss] Special clauses added to OSI-approved licenses: are they OK, and if not, what can/should we do about it?

[Richard Fontana]

Marc Laporte wrote:

> I occasionally notice projects which add clauses such as this one
> http://projects.opensource.org/pipermail/license-discuss/2011-November/25.html
> 
> Here are three more:
> 
> a) AskoziaPBX is BSD with an extra clause
> http://en.wikipedia.org/wiki/AskoziaPBX
> http://www.askozia.com/pbx-license/
> 
> 
> b) Roundcube intends to move to GPLv3+  with an exception:
> http://lists.roundcube.net/mail-archive/announce/2011-12/002.html
> 
> 
> c) sipXecs is AGPL and there are some additional clauses, including
> "By using the sipXecs solution you agree that SIPfoundry can use your
> name and logo to identify you as a user of the sipXecs solution"
> http://www.sipfoundry.org/licensing
> 
> 
> 
> 1- Do these examples above respect the Free Software and/or Open
> Source definitions?

For TCPDF - it might depend on the details, which I haven't
researched, but most likely not. Even if FOSS, this is, to me, an
illegitimate use of LGPLv3 with a noncustomary additional restriction,
even if it is not a violation of any upstream LGPL license. This
reminds me of iText, another PDF-generating library, recent versions
of which purport to be under AGPLv3 plus a similar restriction.

AskoziaPBX is clearly not FOSS, as it requires "prior written consent"
for commercial redistribution.

The intended license of Roundcube skins/plugins seems OK (GPL plus
additional permissions [or copyleft clarifications if you prefer]) but
could probably be drafted more clearly.

I couldn't access the sipfoundry.org site, but I'd consider the quoted
provision enough to make a license non-FOSS.

 - RF





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

Re: [License-discuss] Greetings, Earthlings! Need quotes for article

[Richard Fontana]

On Wed, Dec 21, 2011 at 04:50:53PM -0500, Karl Fogel wrote:
> Richard Fontana  writes:
> >Yes, but I'd have to dig the details up since the review of these
> >licenses took place in (I believe) 2008.  I've been meaning to do that
> >anyway, and to publish the rationale.  In at least one case (OCLC-2.0)
> >at least one issue involved restrictions on commercial use. 
> 
> I don't see those restrictions in OCLC-2.0, but maybe I'm missing
> something.  If you happen to remember the clause, please post here; no
> worries if you don't have time to dig it up though.

I don't have my records on this one at hand, but as someone else
noted, it says:

  The Program must be distributed without charge beyond the costs of
  physically transferring the files to the recipient.

and

  Distributions of Combined Works are subject to the terms of this
  license and must be made at no charge to the recipient beyond the
  costs of physically transferring the files to recipient.

The OSD may not be fully clear on this, but I take it as fundamental
that FOSS licenses should not place any restriction on prices charged
for distribution, other than with respect to source code that is
required to be provided when distributing binaries.

In addition, this provision:

  Any patent obtained by any party covering the Program or any part
  thereof must include a provision providing for the free, perpetual
  and unrestricted commercial and noncommercial use by any third
  party.

is probably best seen as absurd, meaningless, or fatally unclear.

Also, 

  If you learn of a third party claim or other restriction relating to
  a Program you have already distributed you shall promptly redo your
  Program to address the issue

A purported requirement to "redo" software you've already distributed
seems unreasonably burdensome for an open source license (however well
intended it might have been in this particular case).


- RF



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

Re: [License-discuss] Greetings, Earthlings! Need quotes for article

[Richard Fontana]

On Wed, Dec 21, 2011 at 04:28:51PM -0500, John Cowan wrote:
> >   Ricoh Source Code Public License
> >   http://www.opensource.org/licenses/RSCPL
> 
> This is a mildly edited version of MPL-1.0, plus a variant of the
> "obnoxious BSD advertising clause":
> 
> 5.1. Advertising Materials.
> 
> All advertising materials mentioning features or use of the Governed
> Code must display the following acknowledgement: "This product
> includes software developed by Ricoh Silicon Valley, Inc."
> 
> Now the 4-clause BSD has never gotten OSI approval, though it is listed
> as FSF-free.  But I don't see how it contravenes any of the OSD clauses.

Clearly a BSD-style advertising clause cannot (or should not)
contravene the OSD. 

I did find a (cursory) rationale for this one. I apparently thought
that the "Third Party Claims" provision (3.4.1), which is somewhat
different from the corresponding provision in MPL 1.1, was
sufficiently like that of the troublesome former version of the SGI
"Free Software License B" as to cross the line (the corresponding
provision in the Free B license having been called out by the FSF as
one of the reasons why it considered it nonfree). However, perhaps I
judged it too harshly; I'll have to take a closer look.

- RF
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Greetings, Earthlings! Need quotes for article

[Richard Fontana]

On Wed, Dec 21, 2011 at 03:50:51PM -0500, Karl Fogel wrote:
> Without making any assertions as to the open-sourceness or lack thereof
> of CPAL-1.0, I'm surprised to see it absent from this list -- whenever
> the subject of mis-approval comes up, that one's usually mentioned, for
> reasons discussed earlier in this thread.

My recollection is that CPAL was itself the result of earlier
criticism of badgeware licenses (typically MPL 1.1 with an added
clause, as I recall) by people on license-discuss, and was presumably
approved by the OSI because it was seen as sufficiently responsive to
those criticisms. I'd certainly consider it at the outer limit of
acceptability. 

> Richard, did you and Tom keep notes about specifically why you deemed
> each of the above to be non-FOSS?  I assume the reasons are not the same
> in every case.

Yes, but I'd have to dig the details up since the review of these
licenses took place in (I believe) 2008.  I've been meaning to do that
anyway, and to publish the rationale.  In at least one case (OCLC-2.0)
at least one issue involved restrictions on commercial use. 

- Richard

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

Re: [License-discuss] Greetings, Earthlings! Need quotes for article

[Richard Fontana]

On Tue, Dec 20, 2011 at 05:48:22PM -0500, John Cowan wrote:
> Richard Fontana scripsit:
> 
> > The OSI should have some sort of process for delisting
> > formerly-approved licenses for reasons of failing to actually meet the
> > Open Source Definition (or some future replacement of it). That is to
> > say, the OSI should be willing to admit that it made a mistake, much
> > as a court (while it might ordinarily apply the policy of stare
> > decisis) will in certain cases overrule its prior decisions. Clearly
> > for policy reasons such actions should be exceptional rather than
> > common, and perhaps should be limited to certain licenses that were
> > approved during a particular period in the OSI's existence (I would
> > guess 2000-2005?).
> 
> Fine in principle, but do you actually have examples of such licenses that
> contravene the OSD?  (About future revisions, of course, nothing can be said.)

Well, here's a list of OSI-approved licenses that Tom Callaway and I
judged non-FOSS when we examined them (though I haven't looked at
these in a few years). (This does not include the Artistic License 1.0
and certain of its OSI-approved derivatives, which Fedora treats as
non-FOSS based on FSF precedent.) :

Adaptive Public License http://opensource.org/licenses/apl1.0.php
Frameworx License http://opensource.org/licenses/frameworx.php
OCLC Public Research License 2.0 http://opensource.org/licenses/oclc2.php
Reciprocal Public License http://www.opensource.org/licenses/rpl.php
Ricoh Source Code Public License http://opensource.org/licenses/ricohpl.php
Sybase Open Watcom Public License 1.0 http://opensource.org/licenses/sybase.php

If a convincing explanation can be given for why these licenses do
meet the OSD, then the problem is the OSD.

 - RF


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

Re: [License-discuss] Reply to various recent postings on the crayon license issue

[Richard Fontana]

On Tue, Dec 20, 2011 at 12:45:34AM -0800, Bruce Perens wrote:
> On 12/19/2011 09:54 AM, Tom Callaway wrote:
> >nor are we the author of any of the licenses we track(1)), so
> >we're not the appropriate entity to submit what we find to the OSI
> >for approval.
> Can you tell me how many licenses are in Fedora? If it's 300, it's
> something of a self-created problem, but then you'd be in lots of
> company.

The numerosity itself is not a problem, in my opinion, since most of
the previously-unfamiliar licenses one encounters are benign variants
on well-known types. The challenge is in dealing with the cases that
are, in some explicit sense, right on the FOSS/non-FOSS edge
(generally by the license drafter's design), or else with poorly
drafted (though probably well-intended) legacy licenses (hello
TeXLive!).

- RF

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

Re: [License-discuss] Greetings, Earthlings! Need quotes for article

[Richard Fontana]

On Tue, Dec 20, 2011 at 01:46:18PM -0500, Karl Fogel wrote:
> Richard Fontana  writes:
> >That sums it up pretty well. The ~70-license OSI list will give anyone
> >new to open source a rather distorted view of FOSS licensing. For
> >example, and the part that bothers me the most, there is an
> >overrepresentation of mostly-obsolete licenses that I would describe
> >as monuments to the excesses of the open source bubble years, a few of
> >which even fail to meet any reasonable contemporary definition of
> >"open source". 
> 
> We're working on fixing those presentation problems; see
> 
>   http://projects.opensource.org/redmine/issues/4

I'm actually interested in seeing something more than mere
'deprecation', which might be appropriate for certain cases of
superseded or voluntarily-deprecated-by-steward licenses. 

The OSI should have some sort of process for delisting
formerly-approved licenses for reasons of failing to actually meet the
Open Source Definition (or some future replacement of it). That is to
say, the OSI should be willing to admit that it made a mistake, much
as a court (while it might ordinarily apply the policy of stare
decisis) will in certain cases overrule its prior decisions. Clearly
for policy reasons such actions should be exceptional rather than
common, and perhaps should be limited to certain licenses that were
approved during a particular period in the OSI's existence (I would
guess 2000-2005?).

I think this is important because the existence, even in a
'deprecated' category, of licenses that (I would argue) were
mistakenly approved as 'open source' does some damage to the
legitimacy of the OSI and the OSD, and to open source itself. This is
particularly so because, as I understand it, the 'deprecated' category
is supposed to included licenses that do clearly meet community
standards for what's open source.

Given that the few licenses in question are (I think) obsolete, what's
the harm in saying "sorry, we were wrong, this license is not an open
source license after all, and here's why"?

- RF



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

Re: [License-discuss] Greetings, Earthlings! Need quotes for article

[Richard Fontana]

On Mon, Dec 19, 2011 at 12:54:35PM -0500, Tom Callaway wrote:
> On 12/19/2011 12:27 PM, Robin 'Roblimo' Miller wrote:
> > If Fedora is tracking 300+ open source licenses, and the OSI has
> > approved ~70, what's up with that?
> 
> Simply put, many licenses were never submitted for OSI approval, some
> because they pre-date the OSI, some out of ignorance, and some simply
> out of disinterest. Arguably, the most common FOSS licenses are known
> and approved of by the OSI.

That sums it up pretty well. The ~70-license OSI list will give anyone
new to open source a rather distorted view of FOSS licensing. For
example, and the part that bothers me the most, there is an
overrepresentation of mostly-obsolete licenses that I would describe
as monuments to the excesses of the open source bubble years, a few of
which even fail to meet any reasonable contemporary definition of
"open source". 

So I think the ~70-license OSI list says more about the OSI and its
history, and perhaps the early history of commercialization of open
source ("open source" used deliberately there), than it does about
FOSS per se. I believe this also provides a clue to why OSI's mailing
lists are less active than they were some years ago, which Robin also
asked about.

> Fedora has not written its own software license (nor are we the author
> of any of the licenses we track(1)), [...]
>
> 1: While Fedora is not, Red Hat is, at least in one case that I can
> think of, the abominable Liberation Fonts License. I cannot speak at all
> as to why the OSI has not reviewed/approved it, although, I suspect it
> will not be offered up at any time for consideration in the near future
> by Red Hat.

While there is very little in life that is certain, we can be
reasonably certain that Red Hat will never submit that particular
license for OSI review. Moreover, as you can see from this 2005
article (though it contains at least one inaccuracy),
http://www.thinkdigit.com/forum/open-source/58511-red-hat-releases-free-replacements-windows-core-fonts.html
Red Hat is not really the license steward of that license.

- RF

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

Re: [License-discuss] Greetings, Earthlings! Need quotes for article

[Richard Fontana]

On Mon, Dec 19, 2011 at 11:57:04AM -0500, Tom Callaway wrote:
> On 12/19/2011 10:42 AM, Jeremy C. Reed wrote:
> > 69 is way too few. In my little research of just around 600 man pages I 
> > found over 100 different licenses -- mostly due to slight wording 
> > changes.
> 
> Fedora is tracking 300+ different FOSS licenses.

Does that include all 700+ variants of the MIT/X11 license as one
license? :-)

- RF





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